This server exposes a single tool 'dynamic' that is a generic wrapper for HTTP requests. While the implementation uses fastmcp correctly, the tool definition itself violates fundamental MCP patterns. The tool name 'dynamic' is vague and does not start with an action verb. The input schema uses a catch-all 'dynamic_parameters' object with no type information, property definitions, or per-parameter descriptions. The tool description mentions that parameters 'can include' path_params, query_params, and body_params but provides no structured schema for these. LLMs cannot infer what this tool actually does from the name alone, and cannot validate inputs because there are no constraints. This is a proxy pattern that trades discoverability and type safety for configuration flexibility, a poor tradeoff for agent use. The tool is essentially a pass-through that forces agents to reason about HTTP semantics rather than domain operations.

• Refactor tool registration to create individual tools per config.yaml entry, each with a verb_noun name (e.g., 'fetch_user_by_id', 'search_projects', 'create_issue'). This enables proper tool discovery and makes agent selection deterministic.
• For each tool, build a proper input schema with 'properties' field listing all accepted parameters (path_params, query_params, body_params as separate fields with types). Example: { 'type': 'object', 'properties': { 'user_id': { 'type': 'string', 'description': 'The user ID to look up' }, 'include_metadata': { 'type': 'boolean', 'description': 'Whether to include extra fields' } }, 'required': ['user_id'] }
• Write per-tool descriptions that state: (1) What API endpoint does this call? (2) What is the typical response? (3) When should the agent call this? Example: 'Fetch a user by ID from the API. Returns user object with id, name, email, and created_at. Call this after search_users() to get full details.'
• Add per-parameter descriptions explaining format, constraints, and examples. Example: 'user_id (string, required): The system user ID, typically in format U-XXXXX'
• Implement proper error handling: catch httpx.HTTPStatusError and return structured error objects with: status code, error message, hint for next step. Example: { 'error': 'not_found', 'message': 'User U-12345 not found', 'hint': 'Try search_users() with a partial name' }
• Document the output schema for each tool. If the API returns JSON, describe the top-level fields and their types. If pagination is supported, describe limit/offset behavior.