ChatGPT

You are upgrading the MCP service "ChatGPT" so an AI router can reliably discover, choose, and call its tools. Yeetful's Reason Router just graded it 19/100 (F). I'll point you at the service's codebase; audit it against the findings below and implement the fixes.

## Failing checks
schema (0%):
  - NO planner-eligible endpoints — the router cannot construct a single call
  - param-schema coverage 0/9 endpoints (0%)
description (40%):
  - no plannable endpoints to describe
planner (0%):
  - no plannable endpoints — nothing for the planner to pick
affordances (80%):
  - no escape-hatch tool — every uncovered filter needs a new endpoint (whack-a-mole)

## Fixes, in priority order
1. Publish machine-readable parameter schemas (name/type/required per param) — without them every call is unconstructable and the service stays listed-only.
2. Add param schemas to the 9 schema-less endpoints (or retire them) — schema-less POSTs are dead weight in the menu.
3. Consider ONE guarded general-query tool exposing the backend's native query language (see snapshot-free graphql_query) so long-tail intents need no new endpoints.

## The conventions to build to (what the router needs)
- **Param schemas on every tool/endpoint**: name, type, required-vs-optional, and a description per param. A router refuses to construct calls it cannot validate — schema-less endpoints are invisible.
- **Descriptions that carry user intent**: write what a USER would ask ('crypto spot price by symbol — price of ETH, BTC…'), never what the URL is. Include 2–3 example queries.
- **One guarded escape hatch instead of endless params**: if the backend has a native query language (GraphQL/SQL), expose ONE read-only general-query tool with strict guardrails (single read-only operation, allowlisted root fields, depth + page-size caps, response truncation) and a compact schema card in the tool description (root fields + useful filters + one example). Long-tail intents then need no new endpoints.
- **Declare user-identity params**: any param that should be the CALLER's own address (their votes, follows, balances, orders) must say so in its description ('the user's own wallet address') so routers can inject identity server-side instead of guessing.
- **Server-side joins for the headline intent**: if answering the #1 user question takes two chained calls (e.g. resolve follows → filter proposals), add one param that does the join server-side.
- **Build, don't execute**: anything signable returns an UNSIGNED payload (typed data / tx template) for the user's own wallet. Never hold keys, never sign, never submit on the user's behalf.
- **Free tiers still need rate limiting**: no payment gate means no natural throttle.

Start by reading the tool/endpoint definitions and their input schemas, then apply the fixes smallest-first. After each change, restate which failing check it clears.

Audit before you build: if a fix describes a capability the service ALREADY provides (e.g. an escape hatch or identity param that exists but the grader missed), do NOT duplicate it — say so, skip it, and note it back as a likely router-side scoring gap on Yeetful rather than an MCP deficiency. Only change what this service actually controls.