Single tool 'index_directory' has a complete input schema with proper type and description, meeting baseline requirements. However, the tool description is verbose (180+ chars) and focuses on implementation details (tokio tasks, SqliteStore) rather than user intent. No output schema is documented, preventing LLMs from understanding what structured data is returned. Parameter descriptions are minimal. Error handling and recovery guidance are absent. The tool exhibits good naming (verb_noun pattern) but lacks the clarity and LLM-optimization expected of production-grade tools.

• Add an output schema documenting the structure returned by index_directory (e.g., { type: 'object', properties: { task_id, status, indexed_count, errors, completion_time }, required: ['task_id', 'status'] }). This enables LLMs to plan downstream calls.
• Rewrite the tool description to focus on user intent: 'Recursively indexes a directory and returns a task handle for progress tracking. Use this to build searchable file catalogs. Returns a task_id for polling status.' Remove internal implementation details (tokio, SqliteStore).
• Add parameter constraints to 'path': specify absolute vs relative, max depth, symlink behavior, and permission requirements. Example: 'Absolute or relative filesystem path. Max depth: 10 levels. Symlinks followed. Requires read permission.'
• Document error scenarios and recovery: 'If path is ambiguous (e.g., symlink loop), the tool returns InputRequired with available alternatives. If indexing times out after 5 minutes, retry with a shallower path or smaller directory.'
• Add tool annotations (readOnlyHint: true, idempotentHint: true) to signal to LLMs that repeated calls are safe and do not modify state.

Inferred effective spec: 2026-07-28+.

• Current-spec patterns present: stateless request handling, Multi Round-Trip Requests, structured tool output, Streamable HTTP