This is a transparent proxy server that forwards tool definitions from a remote HTTP endpoint. The source code does NOT contain explicit tool schemas, parameter descriptions, or output documentation, only tool names are visible in the banner. Per the hard scoring rules, tools without visible schemas score 0 for schema, and tools without descriptions score 0 for description. The proxy pattern itself is valid, but the evaluation must be based on what is statically verifiable in THIS codebase, not assumptions about the remote endpoint.

• Document tool schemas locally in the proxy or in a bundled schema file. Even if the proxy forwards to a remote, clients need static schema visibility for planning and validation.
• Add parameter descriptions to each tool in the proxy's tool list response. Include expected types, constraints (enums, ranges), and examples of valid input.
• Document output schemas for each tool. Specify whether create_diagram returns an SVG string, a URL, a JSON object with both, or something else. Include field names and types.
• Implement error classification and recovery hints. Wrap remote errors with guidance: 'Diagram not found. Try create_diagram() first.' or 'Rate limit exceeded. Retry in 60 seconds.'
• Clarify tool names with format/scope suffixes. E.g., 'create_diagram_svg', 'edit_diagram_layout', 'get_diagram_json' to disambiguate what each tool produces and accepts.