Single tool with critical definition gaps. list_rules has a valid name (verb_noun pattern) but lacks a meaningful description (only 34 chars, below 50-char minimum for context). Input schema is empty object with no parameters documented. No output schema is visible in the code, the tool returns content array but structure is undocumented. Error handling exists at the server level but provides no recovery guidance to the LLM. The tool is dynamically fetched from a backend API, making static schema validation impossible from the MCP server code alone.

• Expand tool description to 100-150 characters. Example: 'Retrieve your personalized coding rules from Inky. Returns a list of rule names, descriptions, and enforcement levels. Call this first to discover available rules before applying them to code review.'
• Define explicit input schema in the MCP server, not delegated to backend. If the tool truly accepts no parameters, document this: { type: 'object', properties: {}, required: [] }. If backend supports parameters, expose them here with descriptions.
• Document output schema in tool description or as a separate schema field. Example: 'Returns { content: [{ type: string, text: string }] } where type is 'text' and text contains the rule definition.'
• Add actionable error messages. Replace 'Failed to list tools' with 'Failed to list tools: check that API_KEY environment variable is set and the Inky backend is reachable at {API_BASE_URL}.'
• Consider registering tools statically in the MCP server instead of delegating to backend. This enables schema validation, better error messages, and clearer LLM tool selection. If dynamic registration is required, cache and validate schemas locally.