Adaptora's MCP tools suffer from critical definition gaps. Tool schemas are present but descriptions are severely underdeveloped (most under 100 chars, some vague). The 'dynamic_endpoint_tools' tool is inferred rather than explicitly registered, capping its score at 50. Parameter descriptions are sparse or missing entirely. 'run_action' accepts free-form natural language with no constraints, validation guidance, or error recovery hints. No tool declares what it modifies or its side effects. Error handling is absent, no guidance on retryability, user-fixable vs fatal errors, or recovery paths. Security concerns: credentials are mentioned as 'returned' by setup_new_tool but no explicit secret injection pattern is documented.

• Add explicit output schemas to all tools. Document what fields are returned, their types, and which IDs/references downstream tools need. Example: setup_new_tool should return {auth_type: string, required_fields: [string], tool_name: string}.
• Expand run_action description to explain what 'actions' are valid. Provide examples or link to a discovery tool. Add error guidance: 'If action fails, call list_known_tools to verify the tool is connected, then retry with a simpler action.'
• Add state-modification declarations to tool descriptions. E.g., setup_new_tool: 'Creates a new tool definition (irreversible). Returns auth requirements; call with credentials to complete setup.' run_action: 'Executes an action against a connected tool (may modify external state). Idempotent if the underlying API is idempotent.'
• Document dynamic_endpoint_tools explicitly in the server registration. Include a static schema template showing how endpoint parameters map to tool inputs. Currently inferred; make it explicit.
• Add parameter descriptions to all tools. E.g., setup_new_tool.tool: 'Name of the API tool (e.g., "stripe", "slack"). Case-insensitive.' setup_new_tool.source_url: 'Optional direct URL to OpenAPI spec (must be valid JSON/YAML) or documentation page. If omitted, web search is performed.'