This server has fundamental definition quality gaps that prevent confident LLM use. While the tool names follow verb_noun patterns (list_folders, send_message, mark_read), the source code provided does NOT contain actual tool definitions, schemas, or parameter documentation. The tools are referenced in 'packages/mcp-server/src/tool-registry.ts' but the actual schema definitions, input parameters, output structures, and detailed descriptions are not visible in the provided code samples. Only tool names and brief descriptions are listed in the prompt itself, not extracted from verified source code. The brief descriptions given (10-30 chars typically) fall well below the 50-200 char A-grade baseline. No evidence of structured output schemas, pagination support, field chaining (needed for multi-step operations), or error recovery guidance.
NO VISIBLE INPUT SCHEMAS: The source code provided does not include the actual tool definition file (tool-registry.ts contents). Cannot verify JSON Schema with types, descriptions, constraints, or enums for any of the 8 tools.
DESCRIPTIONS ARE TOO BRIEF: Tool descriptions in the prompt are 20-35 characters (e.g., 'List all folders/labels for the user's mailbox' = 44 chars). Baseline for A-grade is 50-200 chars. These descriptions lack WHEN to use, prerequisites, state-change warnings, and dependency hints. LLMs cannot confidently select tools based on single-clause descriptions.
URGENT: Provide the full tool-registry.ts source file showing actual JSON Schema definitions for all 8 tools. Include input schema (type, properties, required array) and output schema for each tool.
Expand each tool description to 80-150 characters. Answer: What does it do? When should the LLM use it vs. a similar tool? What are the prerequisites? Example: 'List all folders/labels in the user's mailbox. Call this first to discover folder names before listing messages. Returns folder IDs and display names. Pagination: offset and limit supported.'
For list_messages and list_folders, add visible pagination parameters: offset (default 0), limit (default 20, max 100), and document returned fields including total_count, next_offset, or has_more.
Document ALL parameters for each tool with type, description, constraints, and defaults. Example for send_message: 'recipient_email (string, required): Email address to send to. Must be a valid email format.' 'subject (string, required): Email subject line. Max 255 characters.' 'body (string, required): Email body. Supports markdown. Max 50,000 characters.'
Document output schemas showing all returned fields and their types. Example for read_message: Returns { message_id: string, sender: string, recipient: string, subject: string, body: string, html_body?: string, timestamp: ISO8601, attachments: [ { filename: string, size_bytes: number, mime_type: string } ], folder_id: string }.
Add idempotentHint=true to mark_read and mark_unread (safe to retry). Add destructiveHint=true and require confirmation for send_message (cannot undo).
NO VISIBLE PARAMETER DOCUMENTATION: Cannot see parameter names, types, descriptions, constraints, enums, or defaults for any tool. Without visible parameter docs, schema score must be 0. Baseline: 100% of A+ tools have all parameters described.
NO DOCUMENTED OUTPUT SCHEMAS: Cannot verify what fields tools return, whether they include chaining IDs (e.g., folder_id for downstream list_messages calls), pagination structure, or count/cursor fields. Baseline: 100% of A+ tools document return types.
MISSING ERROR HANDLING GUIDANCE: No evidence of recovery-guide patterns. When search_messages fails or message not found, LLM has no guidance on what to do next (retry, suggest alternatives, or abort). Critical for agent reliability.
NO PAGINATION VISIBLE for list_messages and list_folders: These likely return arrays but without seeing schema, cannot verify page/offset/limit, total count, or next_cursor. Returning hundreds of messages/folders will blow context windows. Baseline: tools returning lists must support pagination.
SECURITY: No visible evidence of secret injection pattern (OAuth tokens, API keys) in code. If credentials are passed as tool parameters, they leak into agent traces and logs. No visible permission-gate or audit-trail patterns either.
send_messagemark_readmark_unreadarchive_message
For send_message, add error recovery guidance: 'If recipient not found, return error: "Recipient email invalid. Try search_users() if you only have a partial name, or ask the user for clarification."'
Add a read_only_hint=true annotation to list_folders, list_messages, search_messages, and read_message so LLMs know these are safe from a permissions perspective.
Verify secret injection: if authentication tokens or keys are required, inject them server-side via environment variables or configuration, never as tool parameters. Document the required scopes (e.g., read:email, write:email) for each tool.
For search_messages, document the search syntax (e.g., full-text search, filters by sender/date/subject) and return matching message IDs + metadata so the LLM can call read_message on results.
Add audit logging: log all write operations (send_message, mark_read, mark_unread, archive_message) with user ID, timestamp, parameters, and outcome for compliance and debugging.
Test tool composition: Ensure list_messages returns folder_id, so agent can call read_message with those IDs. Ensure search_messages returns message_id for downstream read_message calls. Verify no 'broken chains' that force unnecessary lookup calls.