MCP

For the agent, not for your backend. Needs an MCP-capable client and your customer-specific delta endpoint; policy registration happens through it, so nothing here requires the Orchestrator API first.

The MCP is the agent-facing surface for helping an agent author a policy: the guardrail a user’s intent is built on. It grounds that policy in real categories and evidence attributes from the product taxonomy, then validates and registers it with the orchestrator.

Connecting

The MCP is served over streamable HTTP at the /mcp path of your customer-specific delta endpoint:

https://<your-host>/mcp

It is stateless. Point any MCP client at that URL.

Tools

Three tools, as of Orchestrator v0.10.0:

Tool	Parameters	Returns
get_policy_language_reference	none	the policy language reference, as text
search_taxonomy	query: string, optional	product categories and the attributes a policy can name in its evidence — see the three call modes below
validate_policy	source: string, required	The policy is valid. Policy ID: <id> — a base58 SHA-256 digest

get_policy_language_reference cannot fail. The other two report failure as a tool-result error rather than a protocol error.

Both have an outage path. search_taxonomy returns The internal taxonomy service is currently unavailable. Retry later.; validate_policy returns The internal validation service is currently unavailable. Retry later. on any orchestrator response that is not a 400, so an outage does not read as a rejected draft. That sentence is the first line — a second line, Error details: <error>, carries the underlying failure.

validate_policy also has a rejection path: a 400 returns The policy is invalid. Error: <detail>, where <detail> is the 400 message verbatim. A compile error in the policy source renders as Policy compilation failed: error at <line>:<column>: <what is wrong>, so a rejected draft comes back with the position of the fault; a 400 that is not the compiler’s carries its own message and no position.

Each attribute in a search_taxonomy result carries its policy language type, not its taxonomy type, plus its allowed values where those are defined. An attribute with no policy-language mapping is reported as having none.

search_taxonomy has three call modes, chosen by what query holds:

query	Behaviour
omitted, null, or empty	Lists the root categories.
an exact category path, as returned by an earlier call	Lists that category’s children, or — for a product leaf — its attributes.
any other text	Runs a semantic search and returns at most three categories, best match first.

The middle mode requires an exact path. A path that does not resolve falls through to the semantic search rather than erroring, so a typo returns plausible-looking results instead of a complaint.

The policy language reference is also exposed as an MCP resource at doc://policy-language-reference. Reading that resource returns one text/markdown body with the same bytes as get_policy_language_reference, so clients that surface resources can attach it directly without a tool call.

Authoring loop

1. Read the policy language reference with get_policy_language_reference.
2. For each product type the policy covers, call search_taxonomy with a description to find its taxonomy category and evidence attributes; if a search finds nothing, browse instead — no query lists the root categories, then follow category paths down.
3. Draft the policy.
4. Call validate_policy on the draft; fix and repeat until it succeeds. On success the policy is compiled and registered, and you get back its policy ID.
5. The user then signs an intent referencing that policy ID and submits it — see the Orchestrator API.

Validating a policy also registers it

validate_policy calls POST /policies, which compiles, validates and stores in one step. A policy ID coming back means the policy is registered and ready for an intent to reference — there is no separate registration call, and no way to compile a policy without storing it.

Re-submitting is harmless. A policy is content-addressed by the SHA-256 hash of its compiled bytecode, so the same policy always yields the same ID; because the bytecode ignores formatting and comments, reformatting a policy does not create a second one. That rule is the POST /policies description in the Orchestrator API reference; it is repeated here because it is what makes the fix-and-retry loop above safe to run.

Reading what it produced

The MCP emits policies in the delta policy language, and you do not have to take them on trust: reading a policy covers the shape and the evaluation rules, and value encoding covers the tagged JSON an intent’s attrs must carry — which the API schema does not describe.