How it connects
The server speaks Streamable HTTP. It runs as its own service alongside the Matcher API and exposes a single MCP endpoint (
POST /mcp) plus a plain liveness probe (GET /healthz). There is no stdio transport: every client connects to it as a remote server over the network.
Point any Streamable-HTTP MCP client at the endpoint your platform team provides and send your Matcher bearer token on the connection. For example, with Claude Code:
http://localhost:4019/mcp:
Authorization: Bearer <matcher-jwt> header.
Auth posture
The server is a stateless credential relay that adds no identity of its own:
- Bearer token for API calls. Tools that dispatch Matcher API requests fail closed without a bearer token. They forward the client-supplied credential without logging, storing, or echoing it.
- Local utilities.
mcp_ping,matcher_list_operations, andmatcher_describe_operationrun locally and need no token.mcp_whoamidoes not call Matcher. It still needs a bearer credential, because it reports that a credential arrived. Without a credential, it returns a tool error. - Tenant follows the token for API calls. No API-dispatching tool accepts a tenant parameter. Matcher resolves the tenant from the relayed JWT.
- No session state. Each request builds a fresh in-memory server, so you can scale and restart the relay freely.
mcp_whoami with a bearer credential after you connect. It reports only that the credential arrived, never its value.
What you can do with it
The server exposes curated tool families for configuration, reconciliation runs, exceptions and disputes, ingestion, and reporting. It also exposes a generic bridge for operations with JSON request bodies. See Matcher MCP tools for the catalog.

