Static source inference · medium confidence · evidence: Streamable HTTP
Current-spec patterns detected
Summary
The server defines 12 tools with consistent naming conventions (verb-noun structure: search, fetch, get, list, index, prepare, reveal). However, critical gaps emerge in parameter descriptions, output schema documentation, and error handling guidance. Most tools have acceptable descriptions (60-150 chars), meeting the 10-1024 char baseline, but parameter-level documentation is sparse. Input schemas are visible in the provided metadata but lack detail on field constraints, enums, and validation rules. Output schemas are not documented, LLMs cannot understand what fields to expect or how to chain tools. The server lacks error classification, recovery guidance, and examples of how malformed inputs should be handled. Tools are READ_ONLY or WRITE (risk classification present), but no permission scopes are declared. Parameter descriptions mention 'session_id' for tracking but provide no guidance on what constitutes a valid session_id or how it affects behavior.
Tools (12)
fetch_contentread onlysource verified65/100
Fetch detailed content from a specific indexed file by path
Output schemas are completely undocumented. LLMs cannot determine what fields each tool returns or how to chain results to downstream tools. For example, search() returns results but field names (id vs doc_id vs hit_id), array structures, and metadata are not specified.
Parameter descriptions lack detail on constraints and formats. 'file_path' appears in 7 tools but has no guidance on absolute vs relative paths, symlink handling, or validation. 'session_id' is described as 'Optional session ID for retrieval budget tracking' but provides no documentation on format, lifetime, or error cases when invalid.
Document output schema for every tool. Use JSON Schema format specifying field names, types, and descriptions. Example for search(): {"type": "object", "properties": {"results": {"type": "array", "items": {"type": "object", "properties": {"doc_id": {"type": "string"}, "content": {"type": "string"}, "modality": {"type": "string"}, "score": {"type": "number"}}}}, "total_count": {"type": "integer"}}}
Add min/max constraints to numeric parameters. Example: context_chunks parameter should specify min=1, max=50 in the parameter description: 'Number of adjacent chunks to return on each side (integer, 1-50, default 3)'.
Expand parameter descriptions with validation rules and examples. Example for file_path: 'Absolute path to the file (e.g., /home/user/documents/report.pdf; must be within indexed directories; symlinks are dereferenced)'. For session_id: 'Optional alphanumeric session ID (max 64 chars) for retrieval budget tracking; if provided, tool will enforce quotas; omit for unlimited access'.
Add error handling guidance to tool descriptions. Example: 'If the file is not found, returns error code NOT_FOUND with message listing nearby indexed files. Retry after calling index_content() if the file was recently added.' Apply to all fetch/read tools.
Implement tool annotations (readOnlyHint, destructiveHint, idempotentHint) in the protocol layer. Mark search, fetch_content, get_neighbors, list_sources, get_codebase_context, get_codebase_index, get_module_detail, get_file_content with readOnlyHint=true. Mark index_content with destructiveHint=false, idempotentHint=true. Expose via the MCP tool definition.
Score history
Overall score trend
First recorded score · v2 rubric
61/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-23
C
61
2026-07-28+
v2
read onlysource verified67/100
List all indexed sources, watched folders, and index statistics
No error handling guidance. Tools provide no documentation of failure modes, retryability, or recovery steps. For example, if fetch_content fails because the file does not exist, should the LLM try a different path, call search first, or give up? No guidance is provided.
No tool annotations present. Tools are marked READ_ONLY or WRITE in the evaluation metadata but the server does not expose tool annotations (readOnlyHint, destructiveHint, idempotentHint) in the protocol layer. LLMs cannot infer semantic safety properties.
Pagination and result limits are not documented. search(), list_sources(), search_code_chunks(), and get_neighbors() can return variable-size result sets but lack documentation of limit/offset parameters, max result counts, or next_cursor/pagination tokens. This violates the baseline that list tools accept page/offset and limit with result count.
Modality filter parameter in search() uses enum ['text', 'image', 'video', 'audio', 'all'] but tool description does not explain what each modality returns, whether they can be combined, or what happens if a modality is not indexed.
Tool naming could be more precise. 'prepare_file_for_tool' is vague, it does not convey that files may be downloaded from cloud storage. Consider 'download_and_prepare_file' or 'fetch_file_from_storage'. Similarly, 'reveal_file' is OS-specific jargon (Finder/Explorer); consider 'open_file_in_explorer'.
Parameter 'context_chunks' in get_neighbors() lacks guidance on valid range. Is 1 valid? What is the max? Unbounded parameters can cause LLMs to pass absurd values (e.g. context_chunks=999999) causing timeouts or memory exhaustion.
No permission scopes declared. Tools mark themselves READ_ONLY or WRITE but do not declare what permissions (read:files, write:index, etc.) they require. This prevents least-privilege configuration and audit trails.
Add pagination support to result-returning tools. Modify search(), list_sources(), search_code_chunks() to accept optional limit (default 20, max 100) and offset (default 0) parameters. Return total_count in output so LLMs can paginate. Document expected behavior: 'Returns at most 20 results per page; use offset parameter to fetch subsequent pages.'
Rename imprecise tools: 'prepare_file_for_tool' → 'download_file_from_storage' (clarifies that cloud download happens); 'reveal_file' → 'open_file_in_explorer' (OS-agnostic name conveying intent).
Declare permission scopes for each tool. Add scope declarations to tool descriptions. Example: search (scope: read:content), index_content (scope: write:index), fetch_content (scope: read:content). Use consistent scope names across all tools.
Document parameter dependencies. Example for index_content: 'If path is omitted, defaults to all configured watched folders. Modality defaults to "all" if omitted. To index only images in a specific folder, pass both path and modality="image".' Prevent LLMs from passing conflicting parameters.
Add examples of valid parameter values and error cases to descriptions. Example: modality parameter in search: 'One of: text, image, video, audio, all. If a modality is not indexed, search returns empty results (not an error). Example: modality="image" searches only images indexed during the most recent index_content() call.'
Create a chaining example in list_sources() output: 'Returns all sources with their file paths. Use file_path from results in fetch_content() or get_module_detail() for detailed inspection.' This helps LLMs chain tools correctly.