Context
Modern MCP SDK pattern (post v1.0): register tools with both an `inputSchema` AND an `outputSchema`, and return responses with both `content[]` (text for fallback rendering) AND `structuredContent` (typed object that modern clients can render richly).
Our current implementation only uses `content[]` with JSON-as-text. Newer clients (Claude Desktop recent builds, Cursor, Windsurf) could surface structured fields natively if we adopted the pattern.
What changes
- Define Zod output schemas for each tool response shape (`{status, data, metadata}` envelope)
- Add `outputSchema` to each `server.registerTool()` config
- Add `structuredContent: envelope` to tool responses, alongside existing `content: [{type: 'text', text: ...}]`
Why P1, not P0
- Backward-compatible (text-only clients still work fine)
- Not blocking — current setup is production-verified
- Client ecosystem is still catching up on `structuredContent` rendering
- Value increases over time as more clients adopt modern display
Effort
Half an hour once v0.2.0 work is done. Not worth a standalone version bump, fold into v0.3.0 or next meaningful update.
Context
Modern MCP SDK pattern (post v1.0): register tools with both an `inputSchema` AND an `outputSchema`, and return responses with both `content[]` (text for fallback rendering) AND `structuredContent` (typed object that modern clients can render richly).
Our current implementation only uses `content[]` with JSON-as-text. Newer clients (Claude Desktop recent builds, Cursor, Windsurf) could surface structured fields natively if we adopted the pattern.
What changes
Why P1, not P0
Effort
Half an hour once v0.2.0 work is done. Not worth a standalone version bump, fold into v0.3.0 or next meaningful update.