This server acts as a STDIO proxy to a remote YaniFend MCP server. The source code shows tool definitions are NOT directly visible in index.ts, they are loaded dynamically from a fallback JSON file (tools-fallback.json) that is NOT included in the provided source. The code contains a ListToolsRequestSchema handler that proxies to the remote server (see 'return await withRemote(client => client.listTools())'), meaning tool schemas, descriptions, and parameters are defined remotely and not inspectable in this codebase. Per HARD SCORING RULES, when tool definitions are inferred/proxied rather than explicitly defined in the source, per-tool scores are capped at 50. Additionally, the fallback catalog is embedded as a JSON file whose contents are not shown, making it impossible to verify naming conventions, parameter schemas, or description quality. The 9 tools listed in the prompt (create_personage, list_questions, etc.) appear in the embedded tool catalog ONLY as fallback metadata when the remote server is unreachable, they are NOT the primary definitions. Descriptions provided in the prompt are generic and do not appear in the code listing provided. Without access to tools-fallback.json or the remote server schema, tool quality cannot be assessed from the source.

• Publish the tools-fallback.json file in the repository so tool definitions can be audited. Currently it is built but hidden.
• If this server is meant to proxy a remote server, document explicitly in the README that tool quality depends on the remote YaniFend MCP server schema. Users should understand they are not using local tool definitions.
• Consider embedding full parameter schemas and descriptions in the fallback catalog, with explicit type information (string, number, boolean, enum), minimum/maximum for numeric fields, and required/optional markers.
• Add parameter descriptions to the fallback tool definitions. For example, create_personage should document: What is a 'personage'? What parameters does it accept? What is returned? Currently, agents using the fallback catalog have no schema to work with.
• For each tool that performs a WRITE operation, ensure the description explicitly states that it modifies state. E.g., 'create_personage creates a new personage (cannot be undone)' instead of just 'Create a new personage'.
• Implement local validation and error guidance in the proxy layer. When a remote tool call fails, return actionable error messages that guide the LLM on how to recover (e.g., 'Email already registered. Try list_personages to find existing personages.').
• Document the shape of responses from each tool in their descriptions. E.g., 'Returns {id, name, created_at, questionary_count}' so agents know what fields to expect and can chain downstream tools.