Foundry MCP exposes 5 tools with clear naming (verb_noun pattern: foundry_query, foundry_conventions, foundry_memory, foundry_threads, foundry_signal). Descriptions are present and contextual (50-100 chars each), explaining WHEN to use each tool. However, input schemas are severely incomplete: most tools lack explicit type definitions, parameter descriptions are minimal or absent, and output schemas are undocumented. foundry_threads accepts empty input {} with no schema detail. foundry_signal's 'kind' enum is defined but lacks descriptions for each enum value. No error handling guidance, no pagination support, no output field documentation. Tools appear read-only except foundry_signal (WRITE), but this distinction is not reflected in tool annotations or descriptions.

• Add explicit JSON Schema type definitions to all parameters. foundry_query.detail should declare enum: ['summary', 'full'] with descriptions for each. foundry_conventions.domain and foundry_memory.query should declare type: 'string' with minLength/maxLength constraints.
• Document output schemas for each tool. E.g., foundry_query returns {matches: [{title, snippet, tokens}], total, nextCursor}. foundry_signal returns {signalId, acknowledged, timestamp}. This enables LLM to chain calls.
• Add per-enum-value descriptions to foundry_signal.kind. E.g., 'missing_context: Use when you find a gap in documentation or conventions that should be recorded for future reference.'
• Add error handling guidance to tool descriptions. E.g., 'If no matches found, returns empty array. If query is malformed, returns error with suggestion to refine search terms.'
• Implement tool annotations (readOnlyHint, destructiveHint) to mark foundry_query, foundry_conventions, foundry_memory, foundry_threads as read-only and foundry_signal as write-capable. This helps LLMs reason about side effects.