Static source inference · medium confidence · detected: Logging
Deprecated protocol patterns detected
Summary
MCP Context Server exhibits solid definition quality with consistent naming patterns and generally good parameter schemas. All 16 tools follow verb_noun naming conventions and include input schemas with typed parameters and descriptions. However, several critical gaps reduce the score: (1) Tool descriptions lack the depth needed for LLM optimization, most are 40-80 characters when best practice is 50-200 chars; (2) Output schemas are entirely undocumented, no indication of what fields these tools return; (3) Error handling guidance is absent, tools provide no recovery instructions; (4) Parameter descriptions are minimal, often single clauses without format/constraint details; (5) No documentation of idempotency, atomicity, or state mutation semantics for write operations. The server demonstrates competent foundational structure but lacks the production-grade polish required for enterprise agent deployments.
Output schemas completely undocumented. No indication of what fields tools return (response structure, field types, nested objects). LLMs cannot plan downstream tool chains or extract data reliably without knowing return types.
Tool descriptions are too short (40-80 chars vs 50-200 char baseline). Examples: 'Store context entries in the database with multimodal content support' (61 chars), 'Search context using regex patterns' (36 chars). Insufficient for LLM tool selection, missing WHEN/WHY guidance and differentiation from similar tools.
store_contextstore_context_batchsearch_context
Recommendations
Document output schemas for all tools. For each tool, specify returned object structure (e.g., store_context returns {context_id: string, created_at: string, thread_id: string}), array element types (e.g., search_context returns {results: [{id, content, score, source}], total_count: int, page: int}), and any pagination fields (next_cursor, has_more).
Expand tool descriptions to 100-200 characters minimum. Example revision: 'store_context' → 'Store a single context entry in a thread. Each entry is indexed for keyword and semantic search. Use store_context_batch for bulk inserts. Metadata is optional and searchable.' Similar expansion needed for all 16 tools.
Add constraint details to all parameters. Revise 'limit' descriptions to: 'Maximum number of results to return (default: 20, range: 1-100)'. Revise 'pattern' in grep_context to: 'Python regex pattern (re module syntax). Must be valid regex or tool returns error with pattern hint.'
Document atomicity and error handling for batch operations. Example for store_context_batch: 'Stores all entries in a single transaction. Returns success or failure per entry. If any entry fails validation, that entry is skipped; others succeed. Returns {successful: [...], failed: [{entry, reason}]}.'
Add idempotency guidance for write operations. Document whether store_context with duplicate IDs updates or errors, whether update_context is idempotent on repeated calls, whether delete_context_batch fails or succeeds on already-deleted IDs.
Clarify thread_id vs context_id semantics in descriptions. Document: 'thread_id: identifies a conversation or session (reused across multiple calls). context_id: identifies a single stored entry (unique within thread).'
Spec posture evidence
Inferred effective spec: <=2025-11-25.
Relies on Logging (deprecated) - log to stderr or use OpenTelemetry
Score history
Overall score trend
↑ 70 points across a rubric change (v1 → v2)
70/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-22
B
70
<=2025-11-25
v2
2026-03-09
F
0
-
v1
70/100
List all thread identifiers
navigate_contextread onlysource verified68/100
Navigate context using an index tree with optional per-node summaries
No error handling guidance. Tools provide no recovery instructions when failures occur (e.g., thread not found, invalid regex, concurrent update conflict). LLMs cannot self-correct or plan fallback actions.
Batch operations lack documented atomicity semantics. store_context_batch, update_context_batch, and delete_context_batch do not specify: all-or-nothing semantics, partial success handling, per-item error reporting, or rollback behavior. Agents cannot determine if a single failed item aborts the entire batch or continues.
Destructive operations (delete_context, delete_context_batch) lack confirmation/dry-run pattern. No indication of whether deletes are immediate or reversible, no guidance on safeguards. Agents may trigger unintended data loss.
Parameter descriptions lack constraint details. Examples: 'limit' params have no stated range or default; 'pattern' param in grep_context has no indication of regex flavor/syntax requirements; 'metadata' object in store_context provides no schema for nested fields. LLMs cannot construct valid inputs without trial-and-error.
Thread/context ID parameter handling not explicit. No documentation on accepted formats (UUIDs, alphanumeric strings, etc.), case sensitivity, or validation rules. Unclear whether 'thread_id' and 'context_id' are interchangeable or distinct concepts.
No pagination/result limit guidance. search_* tools accept 'limit' param but no documentation of default limit, maximum allowed limit, or whether exceeding max silently caps or errors. Large result sets could overwhelm context windows.
navigate_context's 'expand_node_id' parameter lacks clear documentation. No explanation of tree structure, node naming convention, or what constitutes a valid node ID. Unclear when to call vs read_context_range.
Search tool proliferation without clear differentiation. Six search variants (keyword, semantic, FTS, hybrid, regex, by-id) risk LLM confusion. Tool descriptions do not explain: when to use semantic_search vs hybrid_search, when grep_context is preferred, or how result ranking differs.
Replace separate search tools with a single search_context with a 'method' enum parameter (keyword|semantic|fts|regex). Include guidance in description: 'method=semantic for topic-based search, method=fts for phrase matching, method=keyword for simple lookups, method=regex for pattern matching.'
Add error recovery guidance. Example for grep_context: 'If query returns 'Invalid regex', call with escaped pattern. If thread_id not found, call list_threads() to see available threads.'
Document navigate_context tree structure. Clarify: 'context_id must point to a root node. expand_node_id is an optional node ID within that tree. Returns tree with optional summaries per node (if enabled). Call read_context_range if you only need flat list.'
Add permission/scope declarations to destructive tools (delete_context, delete_context_batch). Example: 'Requires write:context scope. Deletes are permanent and cannot be undone. Use with caution.'
Specify pagination behavior in search tools. Example: 'Returns up to limit results. To fetch next page, store next_cursor from response and pass as offset parameter (if supported). If no next_cursor, all results retrieved.'
Document metadata schema for store_context. Provide example: 'metadata is optional JSON object (e.g., {"source": "pdf", "page": 5, "confidence": 0.95}). Keys are arbitrary; values must be serializable. Stored as-is; not indexed unless explicitly configured.'