Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
This Azure AI Search MCP server has significant definition quality gaps. All 4 tools have basic descriptions but lack depth, parameter validation guidance, and output schema documentation. Schemas are present but sparse, parameters lack type information for some fields and descriptions are minimal. No error handling guidance. Tool naming follows verb-first convention (search_, format_) but lacks clarity on distinctions. The parameter 'format_type' appears in multiple tools with identical values but no enum constraints. No documentation of what each tool returns or how results chain between them. The server is in STDIO transport only, which is a hard cap on protocol readiness.
Tools (4)
format_documentsread only50/100
Format search results in a specific structured format
Tool names contain 'and' (search_and_summarize, search_and_analyze), signals multiple responsibilities and violates single-concern principle. Each combination should be a separate, composable tool.
Parameter 'format_type' appears in search_documents and format_documents with identical semantics ('structured', 'summary', 'analysis') but no enum constraint. LLMs will guess at valid values.
No output schema documented for any tool. LLMs cannot plan downstream calls or extract required fields (e.g., document IDs, scores, relevance metrics).
Parameter descriptions are generic and lack format/constraint guidance. 'Number of top results to return (default: 5)' does not specify range (1-100? 1-1000?). 'The search query' does not explain length limits or special characters.
Recommendations
Split search_and_summarize and search_and_analyze into separate tools: rename to search_documents (returns raw results), add summary_search_results (takes search output), add analyze_search_results (takes search output). This follows single-concern principle and allows composition.
Document output schema for each tool. Example for search_documents: {"type": "object", "properties": {"results": {"type": "array", "items": {"type": "object", "properties": {"id": {"type": "string"}, "title": {"type": "string"}, "content": {"type": "string"}, "relevance_score": {"type": "number"}}}}, "total_count": {"type": "integer"}, "next_cursor": {"type": "string"}}}
Add parameter constraints: top_k must have minimum 1, maximum 100; query must be non-empty string with max 500 chars. Include in description: 'Number of results to return (1-100, default: 5). Large values slow searches.'
Add error recovery guidance to each tool description: 'If no results found, try: (1) broader query terms, (2) different format_type, or (3) search_available_indexes() to discover searchable content.'
Add pagination parameters to search tools: page (int, default 1) and limit (int, 1-100, default 20). Return total_count and next_cursor in output for context-aware pagination.
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
No error handling guidance. Tools return READ_ONLY risk but no documentation of failure modes (no results, API timeout, invalid query syntax) or recovery steps.
Tool descriptions do not clarify WHEN to call each. 'Search documents' vs 'Search and summarize', when should the LLM choose summary over the search tool + separate LLM summarization? No guidance on intent matching.
No mention of pagination support. Baseline pattern requires page/offset, limit, and result count. Large search results will exceed context windows without pagination.
Parameter 'documents' in format_documents is typed as 'string' but semantically should be structured (array of document objects). No guidance on expected format (JSON? CSV? Raw text?).
format_documents
Clarify tool intent in descriptions. 'search_documents: Returns raw document matches with relevance scores. Use when you need to review source material or pass results to format_documents. For a quick answer summary, use search_and_summarize instead.' (reverse for summary variant).
Change format_documents 'documents' parameter to accept structured input: {"type": "object", "properties": {"documents": {"type": "array", "items": {"type": "object"}, "description": "Array of document objects, each with 'id', 'title', 'content' fields. Typically the 'results' array from search_documents."}}}
Add tool annotations to schema: include 'readOnlyHint: true' and 'idempotentHint: true' for search tools (no side effects). Document in description that results are deterministic.
Add example error scenarios to server documentation: 'Empty search query → error with guidance to provide keywords', 'API timeout → LLM should retry with smaller top_k', 'Invalid format_type → list valid options in error message.'