Skip to content

types-epic E batch 9: Zod MCP schemas for registry discovery 1 (17 tools) #8073

Description

@JSONbored

Part of #7863 (types-epic E). One of 12 remaining tool batches — see #7863 for batch 1 (the pilot conversion: search_subnets, list_subnets, get_subnet, get_network_health, get_subnet_stake_quote, get_economics) and the wire-compatibility constraint this batch must preserve.

Scope

Convert these 17 MCP tools' inputSchema/outputSchema hand-written JSON Schema 2020-12 literals in src/mcp-server.ts's MCP_TOOLS registry to Zod-defined schemas, following the exact process #7863 established for batch 1:

  1. For each tool below, define its input/output shape as a Zod schema. Where a tool mirrors a REST route already covered by schemas-src/routes/ (from types-epic B: generate OpenAPI 3.1 from the Zod layer; invert the schemas/ flow for covered routes #7860 and its batches), reuse that module's schema — share, never redeclare.
  2. Replace inputSchema: {…literal…} with inputSchema: z.toJSONSchema(<tool>Input, { target: "draft-2020-12" }), computed once at module load. Same for TOOL_OUTPUT_SCHEMAS.
  3. Handler signatures become async handler(args: z.infer<typeof <tool>Input>, ctx: McpCtx). This does not change WHERE validation happens (SEP-1303 tool-error semantics unchanged), only where schemas are DEFINED. If a converted schema surfaces that the current runtime accepts something the declared schema forbade (or vice-versa), that's a finding: align them per the tool's documented contract and record it in the PR body.
  4. Hard wire-compatibility constraint: the emitted JSON Schema after conversion must be SEMANTICALLY equivalent per tool — same required sets, same types, same enum values, same additionalProperties posture. Cosmetic differences (key order, $schema presence, description strings) are acceptable; anything that changes what a client-side validator accepts is a regression. Run the equivalence-diff script from types-epic E: MCP tool input/output schemas via Zod — delete the hand-written JSON Schema literals #7863's batch 1 against every tool in this batch; every DIFF must get a bucket-(a/b/c) resolution, included in the PR body.
  5. Zero JSON Schema object literals remain for these tools (grep-verified in review).
  6. Do NOT hand-bump MCP_SERVER_VERSION or server.json's version — sync-mcp-version handles that post-merge. This adds no new tools, so no server-card regen is needed.

Tools in this batch (17)

  • list_subnet_apis
  • get_api_schema
  • get_fixture
  • get_provider_detail
  • list_providers
  • list_surfaces
  • list_candidates
  • list_endpoints
  • list_evidence
  • list_rpc_endpoints
  • list_source_snapshots
  • list_profile_completeness
  • list_rpc_pools
  • get_subnet_endpoints
  • list_subnet_endpoints
  • list_subnet_surfaces
  • list_subnet_health

Acceptance criteria

  1. tests/mcp-server.test.ts passes UNCHANGED (its Ajv validation of outputSchemas is the independent referee — do not edit its assertions to make the PR pass; if an assertion fails, the schema conversion is wrong).
  2. Full CI green; the equivalence-diff script reports PASS or resolved-DIFF for every tool in this batch, output included in the PR body.
  3. Zero JSON Schema object literals remain for these tools (grep-verified in review).

Non-goals

Metadata

Metadata

Assignees

Labels

maintainer-onlyOwner-only work — yields no Gittensor points.

Projects

Status
Done

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions