Atlas-MCP demonstrates solid foundational quality with consistent naming patterns, readable descriptions, and explicit schemas across all six tools. All tools follow verb_noun naming conventions (build_context, semantic_search, hybrid_search, query, search, search). Descriptions are present and reasonably detailed (ranging 56-112 chars), explaining what each tool does and when to use it. Input schemas are visible with typed parameters and descriptions. However, there are notable gaps: (1) output schemas are not documented, LLMs cannot know what fields to expect from search results, database queries, or vector operations; (2) no pagination guidance despite tools accepting top_k parameters that could return large result sets; (3) missing error guidance, no indication of retryability, user-fixable vs fatal errors, or recovery paths; (4) no security annotations (readOnlyHint present in manifest but not mapped to tool definitions); (5) parameter constraints are mentioned in descriptions but not enforced as enum/pattern in schemas (e.g., top_k 'max 20' stated in description but not in schema type definition). The codebase shows production-grade infrastructure (circuit breakers, rate limiting, audit logging, OpenTelemetry tracing) but tool definitions themselves lack the completeness expected for A-grade quality. Strengths: all tools are READ_ONLY with clear risk classification, parameters are well-named with type suffixes (customer_id, collection name), descriptions avoid example values. Weaknesses: output structure undocumented, error handling opaque, result limits mentioned but not schema-enforced.

• Document output schemas for all six tools. Include example response shapes showing field names, types, and sample values. E.g., 'semantic_search returns {results: [{id: string, text: string, score: float}], total: int}'.
• Add schema-level constraints: (1) top_k parameters should have maximum: 20 in schema, (2) enum values (e.g., for sort_by if it exists) should be declared as enum, not described. This moves validation from prose to machine-checkable format.
• Add error handling guidance to each tool description. E.g., 'If the collection does not exist, returns 400. Verify collection name with list_collections() first.' (or similar for each tool's failure modes).
• For postgres.query, add server-side SQL validation: reject any non-SELECT statement, strip comments, validate against a whitelist of tables/columns. Or offer a template-based tool instead (e.g., query_active_customers(date_from, date_to) rather than raw SQL).
• Clarify pagination for tools returning lists. Add to descriptions: 'Results are sorted by relevance score (highest first). If more results exist, call again with offset or next_cursor parameter (if supported).' Then implement and document offset/next_cursor in schemas.
• For elasticsearch.search, simplify the query parameter by offering pre-built filters (search_term, date_range, status_filter) instead of raw DSL. Alternatively, provide examples of valid DSL queries in the description or a companion resource.
• Add per-parameter examples and constraints: (1) customer_id format (UUID, integer, email?), (2) collection name validation rules, (3) embedding dimensions or format expectations for vector.search.

Inferred effective spec: 2026-07-28+.

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