MCP
How an agent finds out what a server can do, without being told in advance.
The problem it solves
A REST API is only useful to an agent that already knows its exact shape — which endpoints exist, what parameters they take, what they return. That knowledge has to come from somewhere: documentation a human read, or a hard-coded integration someone wrote. Model Context Protocol (MCP) puts that knowledge in the server itself. A client connects, calls tools/list, and gets back every tool's name, description and JSON Schema for its inputs and outputs — machine-readable, at runtime, no prior integration required.
MCP vs REST vs x402
These solve different problems and compose rather than compete. A REST API is called directly once its shape is known. MCP standardizes discovering that shape at runtime. x402 standardizes paying for a call. A single resource can be reachable over plain HTTP, described via MCP's tools/list, and priced via an x402 402 response — all three at once, which is exactly how Agent Bazaar's own MCP server works: its tools are just /discovery under a different transport.
Transport: Streamable HTTP
MCP's Streamable HTTP transport is one JSON-RPC 2.0 request in, one JSON-RPC 2.0 response out — a server that only offers read-only, stateless tools (like search) doesn't need a persistent connection or session handshake at all. Agent Bazaar's server works exactly this way.
curl -X POST https://bazaar.saylorinnovations.com/mcp \
-H "content-type: application/json" \
-d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'On Agent Bazaar
Full tool list and connection details: /mcp. Every resource on this marketplace is reachable the same way an agent would reach any tool — search, inspect the schema, then call it.