Model Context Protocol server for Azure Cosmos DB integration
This HTTP-based Cosmos DB MCP server has three read-only tools with schemas present but significant gaps in descriptions, parameter documentation, and output schema clarity. Tool naming follows verb_noun conventions (query_documents, read_document, get_container_statistics), which is good. However, descriptions are minimal (12-35 chars for tools; 'Get statistics about the container' is vague), and parameter descriptions are sparse or missing context. The `parameters` field in query_documents is poorly explained (what format? what do these objects contain?), and no output schemas are documented. Error handling guidance is absent. Resource support is present but underdeveloped. This server would benefit from substantial documentation improvements before production use.
Get statistics about the container
Execute a SQL query against Cosmos DB documents
Read a specific document by ID
Tool descriptions are under 40 characters and lack context for LLM selection. 'Execute a SQL query against Cosmos DB documents' is generic; 'Get statistics about the container' is vague. Descriptions should explain WHAT, WHEN, and any dependencies (e.g., 'Query documents using Cosmos DB SQL syntax. Use this to fetch filtered results; for single documents by ID, call read_document instead.').
The 'parameters' field in query_documents (type: array, items: object) has no structure documentation. What properties do these parameter objects have? Is it {name, value}? {key, type, value}? The description 'Optional query parameters' is insufficient. LLMs cannot infer the structure and will pass invalid payloads.
No output schemas documented. read_document returns 'a document', but what fields? Is it the raw CosmosDB JSON? Does it include _id, _ts, _etag? Pagination not mentioned for query_documents. Without documented return structures, LLMs cannot plan downstream calls (e.g., extracting document_id for a follow-up read).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 44 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 13 | - | v1 |
query_documents lacks result limits and pagination guidance. Large result sets will blow context windows. The description should state 'Returns up to [N] documents; use OFFSET/LIMIT in the SQL query for pagination.' No mention of cross-partition query cost or RU impact.
No error handling guidance. If a query is invalid SQL, partition key is wrong, or resource not found, what does the agent see? No descriptions mentioning retryability, user-fixable errors, or recovery paths. Bare exceptions block agent recovery.
Parameter 'cross_partition' (boolean) defaults to true, which may incur significant RU costs in Cosmos DB. The description does not warn about performance/cost implications. Defaults should not cause unintended side effects.
Resources are declared (cosmosdb://database, cosmosdb://container, cosmosdb://documents) but descriptions are generic ('Information about the connected Cosmos DB database'). The read_resource handler for cosmosdb://documents returns 'SELECT TOP 10 *', cap is hardcoded with no explanation. Should document why top 10, when to use each resource.