--- title: "KYE Protocol™ — KYE™ MCP Server | Authority checks, schemas, evidence packs for MCP agents" description: "The KYE™ MCP Server exposes KYE Protocol™ schemas, dictionaries, authority checks, Decision Maps™ and evidence packs to MCP-compatible agents, IDEs and…" url: https://kyeprotocol.com/mcp/ lang: en source: "KYE Protocol" --- > The KYE™ MCP Server exposes KYE Protocol™ schemas, dictionaries, authority checks, Decision Maps™ and evidence packs to MCP-compatible agents, IDEs and… KYE™ MCP Server # Expose KYE™ to MCP agents — safely. KYE™ MCP Server™ exposes the protocol to Claude, GPT. And any MCP-compatible agent. Signed tool calls. Scoped evidence. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Read the docs](https://kyeprotocol.com/docs/) When v1.1 ships, the KYE™ MCP Server exposes KYE Protocol™ schemas, dictionaries, authority checks, Decision Maps™. And evidence packs through a controlled [Model Context Protocol](https://modelcontextprotocol.io/) interface — read-only resources, decision tools that round-trip through the gateway, gated admin tools. Auth, idempotency, audit binding all enforced. Plain Q&A ## Plain Q&A Short questions. Short answers. - **What is MCP?** A way to plug tools into an agent. - **What does the KYE™ MCP server do?** It signs the tool calls. - **Does it sign the replies too?** Yes. Every reply. - **Does it work with Claude?** Yes. And GPT. And any MCP agent. - **Do I need keys?** Yes. You keep them. - **Where does the proof go?** To your audit log. Not to us. - **Can I see the source?** Yes. The server is open. - **Can I run it on my box?** Yes. Or on the edge. Plain take ## Plain take Plug KYE™ into Claude, GPT, or any MCP agent. Signed tools. Scoped proof. - One server. Many agents. - Each tool call is signed. - Each reply has an evidence pack. - You set the scope. We enforce it. The boundary ## MCP is for integration. Production enforcement stays in the gateway. ### KYE™ MCP Server Integration surface for agents, IDEs, AI assistants, and developer tools. Read-only by default; decision and admin tools require explicit gating. ### KYE™ Runtime Gateway™ The enforcement surface. Production decisions for agent actions, payment authorisations, and capability invocations land here — never on MCP alone. An MCP tool call should not bypass the runtime gateway for any production-affecting action. The MCP server's decision tools call _through_ the gateway, log the call as an audit event. And return the gateway's signed response. Treat MCP as a typed, controlled query and proposal layer. Read-only tools ## 10 tools, no side effects. Read-only tools never mutate state, never publish events, never affect production. They are safe to enable for any MCP client. - `kye.resolve_entity` — resolve an entity URN to its canonical record - `kye.get_entity_state` — current six-dimensional state vector - `kye.get_authority_grant` — lookup a grant by id - `kye.get_delegation_chain` — walk the chain from actor to root principal - `kye.get_capability_manifest` — manifest for a named capability - `kye.get_decision_map` — signed Decision Map™ for a decision id - `kye.get_evidence_pack` — signed evidence pack by id - `kye.verify_evidence_pack` — verify a pack offline using the published JWKS - `kye.list_reason_codes` — full reason-code dictionary - `kye.explain_decision` — human-readable rendering of a Decision Map™ Decision tools ## 5 tools, gated to the runtime gateway. Decision tools propose an action and ask the runtime gateway for a verdict. They never decide locally. the gateway decides, signs. And audits. - `kye.decide_authority` — ask "may this actor exercise this authority right now?" - `kye.decide_capability_invocation` — ask "may this capability be invoked with these parameters?" - `kye.check_payment_authority` — ask "is this delegated payment authority valid for this transaction?" - `kye.check_agent_purchase` — ask "may this agent buy this basket from this merchant on this instrument?" - `kye.check_scope` — ask "does this action fit inside the named scope?" Every decision tool returns the standard decision codes (allow / allow\_with\_constraints / require\_approval / require\_step\_up / require\_human\_review / require\_recovery / quarantine / deny) plus a Decision Map™ reference. The MCP client cannot bypass the gateway. Admin / write tools · gated by default ## 8 tools that mutate state — all gated. **Admin tools are off by default.** When enabled, every call MUST present tenant authentication, MUST pass policy checks, MUST carry an idempotency key, MUST emit an audit event. And MAY require step-up approval depending on the policy binding. Treat MCP write paths as a high-risk surface. - `kye.create_entity` — create a new entity record - `kye.create_delegation` — create a delegation between actor and principal - `kye.grant_authority` — grant scoped authority to a delegation - `kye.revoke_authority` — revoke an authority grant - `kye.quarantine_entity` — quarantine an entity (state mutation) - `kye.rotate_credential` — rotate signing credentials for an entity - `kye.create_capability_manifest` — register a new capability manifest - `kye.create_webhook_endpoint` — register a new subscriber endpoint **Hard requirements per call:** tenant auth (mTLS or OAuth2 client-credentials) · per-tool capability check via the runtime gateway · idempotency key in the request · reason code in the request · full audit event emitted before response · step-up approval per policy binding. MCP resources ## Schemas, dictionaries, profiles, decisions, evidence. MCP resources are URI-addressable, read-only data exposed to the client. The KYE™ MCP Server exposes a uniform `kye://` URI scheme. - `kye://schemas/core` · `kye://schemas/entity` · `kye://schemas/authority-grant` · `kye://schemas/capability-manifest` - `kye://dictionaries/reason-codes` · `kye://dictionaries/decision-codes` · `kye://dictionaries/event-types` - `kye://profiles/payment-authority` · `kye://profiles/agent-purchasing` · `kye://profiles/{profile-id}` - `kye://decision-maps/{id}` · `kye://evidence-packs/{id}` - `kye://entities/{id}` · `kye://capabilities/{id}` · `kye://delegations/{id}` MCP prompts ## Reusable prompt templates clients can discover. What it is. Why it matters. What to do next. - `review_authority_chain` — structured review of a delegation chain for attenuation correctness - `explain_decision_map` — render a Decision Map™ in natural language for a non-technical audience - `draft_authority_grant` — help an operator draft a scoped authority-grant request - `model_agent_purchasing_flow` — sketch an agent-purchasing flow against the kye-payments-card profile - `generate_open_banking_authority_map` — map a TPP → agent → ASPSP Authority Graph™ - `assess_kye_readiness` — readiness review against the 12-question Authority Finality™ assessment - `prepare_evidence_pack_summary` — one-page summary of an evidence pack for a regulator-facing brief Security ## MCP tool-use is a high-risk surface. MCP server deployments have introduced real-world risks: malicious tool execution, credential theft, prompt-injection-driven privilege escalation. And supply-chain compromise via untrusted server packages. The KYE™ MCP Server assumes the worst by default. - **Tenant-scoped auth** — every connection requires mTLS or OAuth2 client-credentials. No anonymous access. - **Per-tool allowlisting** — tools are off by default. Operators explicitly enable read-only / decision / admin sets per tenant. - **Policy-bound writes** — admin tools route through the runtime gateway's policy decision point. the MCP server cannot decide locally. - **Idempotency required** — admin tools require an idempotency key. replays return the original response. - **Audit-bound** — every MCP call (resource fetch, tool invocation, prompt expansion) emits an audit event with the actor entity id, the tool name, the request hash, and the response hash. - **Signed responses** — decision tool responses carry the gateway's signature so the MCP client can verify the answer didn't come from the MCP server itself. - **Rate-limited** — per-tenant, per-tool budgets. Burst protection on admin tools. - **Supply-chain** — reference server distributed via signed releases. SBOM published. reproducible builds. Start ## When v1.1 ships, run the reference server in 5 minutes. The flow below describes the v1.1 install path. **Today**, integrate against the KYE™ Reference Gateway™ directly via [the SDKs](https://kyeprotocol.com/developers/). the same authority + decision + evidence semantics apply. 1. Install — `npm i @kye/mcp-server` _(v1.1)_ 2. Configure tenant auth, gateway URL, and the tool allowlist (read-only / decision / admin sets). 3. Start the server — `npx @kye/mcp-server --config kye-mcp.json` 4. Connect from an MCP client (Claude Desktop, Cursor, internal AI platform). Discover resources, tools, and prompts. 5. Verify with the included conformance suite — `npx @kye/mcp-server conformance` [Today: KYE™ Reference Gateway™ SDKs →](https://kyeprotocol.com/developers/) [v1.1 roadmap](https://kyeprotocol.com/roadmap/) [Signal Bus](https://kyeprotocol.com/protocol/#signals) Talk to the program Adjacent reading ## Where to go next. What it is. Why it matters. What to do next. [Build →](https://kyeprotocol.com/build/) [Connectors](https://kyeprotocol.com/connectors/) [Developers](https://kyeprotocol.com/developers/) [Protocol](https://kyeprotocol.com/protocol/) [Glossary](https://kyeprotocol.com/glossary/) ## Ready to see your AI agents flagged? Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks. [Apply for pilot →](https://kyeprotocol.com/pilot-apply/) [Try the sandbox →](https://kyeprotocol.com/sandbox/demos/) Canonical KYE™ surfaces referenced on this page: [Authority Graph™](https://kyeprotocol.com/authority-lifecycle/) · [Evidence Pack™](https://kyeprotocol.com/evidence-pack/) · [KYE Protocol™](https://kyeprotocol.com/).