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 — it adds no identity of its own:
- Bearer token for API calls. Tools that dispatch Matcher API requests fail closed without a bearer token and 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, but it requires a bearer credential to report that one was relayed; without it, 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 the relay can be scaled and restarted freely.
mcp_whoami with a bearer credential after connecting — it reports only that the credential arrived, never its value.
What you can do with it
The server exposes curated tool families covering configuration, reconciliation runs, exceptions and disputes, ingestion, and reporting, plus a generic bridge for operations with JSON request bodies. See Matcher MCP tools for the catalog.

