RentCast

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

## Failing checks
schema (65%):
  - param-schema coverage 0/10 endpoints (0%)
description (57%):
  - 2/7 endpoint descriptions carry real intent
planner (67%):
  - "How much is this property worth based on current market data?" → planner picked NOTHING
affordances (80%):
  - no escape-hatch tool — every uncovered filter needs a new endpoint (whack-a-mole)

## Fixes, in priority order
1. Add param schemas to the 10 schema-less endpoints (or retire them) — schema-less POSTs are dead weight in the menu.
2. Rewrite 5 endpoint description(s) to say what a USER would ask for ("crypto spot price by symbol — price of ETH, BTC…"), not what the URL is. Weak: rentcast.x402.paysponge.com/markets, avm/value, rentcast.x402.paysponge.com/properties…
3. The planner declined "How much is this property worth based on current market data?" against this service's own menu — the endpoint descriptions don't signal that capability.
4. 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 Pantessa rather than an MCP deficiency. Only change what this service actually controls.