ToolRecall exposes 6 tools via STDIO with minimal schema documentation. Tool definitions are inferred from Dockerfile/Makefile comments rather than explicit registration code. Input schemas are present but sparse: most parameters lack detailed descriptions (e.g., 'File path to read' is generic). No output schemas are documented. Descriptions are brief (10-30 chars) and lack context on when/why to use each tool. No error handling guidance, no parameter constraints (enums, ranges), and no security annotations. The 'ping' tool is deprecated in MCP 2026-07-28 spec. Overall, definitions are skeletal and would not guide an LLM reliably.

• Add explicit MCP tool registration code (visible in source) with full JSON Schema for each tool. Include input type definitions, descriptions for every parameter, and documented output schemas.
• Expand tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and WHAT it returns. E.g., 'Read a file from ToolRecall's L1 cache. Use this for repeated reads of the same file to avoid disk I/O. Returns file content as string.'
• Add parameter constraints: cached_terminal should document allowed commands or patterns; cached_read/cached_write should specify path restrictions (no traversal); cache_refresh_file should explain TTL behavior.
• Document output schemas for all tools. E.g., cached_read returns {content: string, size: int, cached: bool, cache_age_ms: int}; cache_status returns {entries: int, size_bytes: int, hit_rate: float}.
• Remove or replace the deprecated 'ping' tool. Use stateless health checks via _meta.logLevel or a dedicated health endpoint outside MCP.