Four tools with basic descriptions and minimal parameter documentation. All tools have input schemas with type definitions, but descriptions are terse (10-60 chars, well below the 194-char baseline). Parameter descriptions exist but lack actionable constraints, format guidance, or dependency hints. No output schemas documented. Error handling is absent, no recovery guidance, categorization, or actionable error messages. Security concerns: send_email accepts free-form recipient and body with no injection scanning visible in the tool definition itself (gateway claims to handle it, but tool definition does not document this). No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Composition is reasonable (four distinct tools), but descriptions do not explain WHEN to use each tool or what to expect in return.

• Expand each tool description to 150-250 chars. Include: what it does, when to use it (vs. similar tools), what it returns, and any prerequisites. E.g., 'Read a company file through the security gateway. Use for internal documents (handbook, policies). Returns file content as plain text. Requires analyst role or higher.'
• Document output schemas for all tools. E.g., read_file returns {content: string, size_bytes: int, last_modified: string}. This enables LLMs to plan downstream calls and extract the right fields.
• Add parameter constraints to descriptions. E.g., 'path: File path (must start with /company/, max 255 chars, no ../ traversal)' and 'sql: Read-only SELECT query only (no INSERT, UPDATE, DELETE, DROP)'.
• Add error handling guidance. E.g., 'If file not found, returns error 404 with available files in /company/. If permission denied, returns error 403, contact admin to grant analyst role.'
• Add tool annotations (readOnlyHint, destructiveHint, idempotentHint) to the FastMCP tool registration. Mark read_file, fetch_url, query_db as readOnly=true. Mark send_email as destructive=true, idempotent=false.