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:
- Your token, relayed verbatim. The client sends the same Matcher JWT you’d use against the API directly (issued by your Access Manager). The server forwards it to the Matcher API on every tool call and never logs, stores, or echoes it.
- Fail-closed. A tool call arriving without a bearer token is rejected before any request reaches Matcher. There is no anonymous or default-tenant fallback.
- Tenant follows the token. No tool accepts a tenant parameter; Matcher resolves your tenant entirely from the relayed JWT, so the MCP surface can never cross tenant boundaries.
- No session state. Each request builds a fresh in-memory server, so the relay can be scaled and restarted freely.
mcp_whoami tool after connecting — it reports only whether 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 escape hatch over the full Matcher API. See Matcher MCP tools for the catalog.

