Agent & Protocol · Toolkit

MCP Server Playground

SIMULATEDVerified Jul 2, 2026

MCP isn't magic — it's a disciplined contract. Pick a system, watch its server manifest, then send a tool call and read the exact JSON-RPC that crosses the wire, both directions.

Same instrument · three industries — pick a use-case to reconfigure the run

Card disputes system of record (finserv). Exec annotations

Server manifest · Disputes API

Most demos stop at tools. Resources (read-only context) and prompts (reusable templates) are part of the same contract.

Call get_dispute

dispute_id · string · required

Inject malformed args

MCP vs bespoke — the crossover

Systems to expose8

Agent consumers6

Bespoke integrations

systems × consumers

MCP endpoints

systems + consumers

Bespoke integration grows as N×M; a shared protocol grows as N+M. The crossover is early — here MCP is 3.4× fewer connections.

What the wire teaches

Every tool call is the same envelope: a named tool, typed arguments, structured content back, typed errors on failure. That uniformity is the whole value — one contract, many systems, many consumers.

Steering-committee takeaway: Deciding MCP vs bespoke isn't religious — it's how many systems and how many consumers. The crossover is earlier than teams expect.

How this is built

Manifests are authored per mock system (tools with typed args, resources, prompts). The composer builds a real JSON-RPC 2.0 `tools/call` frame; arguments are validated against the tool's schema, and failures return a −32602 error frame — the same path a real server takes.

Stack: Next.js (static) + shared design system; deterministic, client-side. No live server — the round trip is constructed, not fetched, and labeled SIMULATED.

Limitations: a real MCP server adds capability negotiation, auth, streaming, and pagination; this shows the core request/response contract, not the full lifecycle.