MCP Intelligence exposes 3 tools with visible schemas and descriptions in src/index-mcp-server.ts. However, there are significant gaps in definition quality. Tool descriptions are generic and lack actionable context (e.g., 'Process a natural language query and route to appropriate MCP server' does not explain when to use this vs other tools, what prerequisites exist, or what the output structure is). Parameters like 'context' in the query tool have type 'object' with no internal schema definition, LLMs cannot reason about what fields are expected. The 'explain' tool accepts a 'result' parameter typed as 'object' with no schema, making it impossible for LLMs to know what structure to pass. Error handling is not visible, no indication of retryable vs fatal failures. Output schemas are not documented anywhere in the visible code. Tool names follow verb_noun convention (query, get_suggestions, explain), which is positive, but the query and explain tools are vague and could be split into more specific, composable actions. The 'context' parameter in 'query' has a description of only 'Optional context for the query', well below the 20-char minimum threshold for meaningful guidance.

• Expand 'query' description to 150-250 chars: 'Route a natural language query to the most appropriate MCP server. Use this when the user asks a question and you need to delegate to domain-specific tools. Returns routing decision and confidence score. Requires a clear, well-formed query string.'
• For 'context' parameter in query tool, replace generic 'object' with explicit schema: properties like {conversation_history: array of objects, user_intent: string, domain_hint: string} with descriptions for each field.
• Add min/max constraints to 'limit' in get_suggestions: 'Maximum number of suggestions to return (1-50, default 5). Values outside this range will be clamped.'
• Document output schema for all three tools. For 'query': 'Returns {routing_decision: string, confidence: number (0-1), target_server: string, reasoning: string}'. For 'get_suggestions': 'Returns {suggestions: array of {text: string, score: number}, total_available: number}'. For 'explain': 'Returns {explanation: string, related_concepts: array of strings, confidence: number}'.
• Rename 'explain' to a more specific action like 'summarize_result' or 'interpret_query_result' to avoid ambiguity with explain-type tools in other servers.
• Add error handling examples to descriptions. E.g., 'query tool: returns error code 400 if query is empty or malformed. 404 if no suitable server found (retryable with clarified query).'
• Replace generic 'result' parameter in explain tool with a specific schema: {query: string, original_result: object, result_format: string (enum: json|text|structured)} so LLMs know what to pass.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry