Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@ReproGate plan an action for sending a test email and issue a capability token"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
ReproGate is an action-contract layer for MCP tool execution. It binds a policy decision or human approval to the exact tool, schema, arguments, authority, policy, and observed workspace state, then makes that binding available to an execution receipt.
The goal is narrower than “another MCP gateway”: make a tool action independently inspectable and make approval invalid as soon as the proposed action changes.
This repository currently contains the action-contract kernel and a real, plan-only MCP server. It can:
discover tools through a small stable façade;
build deterministic, digest-bound action envelopes from an operator-controlled catalog;
return explainable allow, approval_required, or deny decisions;
issue and validate one-use capability tokens bound to an exact envelope;
create tamper-evident, hash-chained decision records.
It intentionally cannot execute downstream tools yet. Phase 1 is not a sandbox, live security proxy, or production authorization boundary.
Related MCP server: mcp-permission-server
Requirements: Node.js 22.13 or newer. CI tests the maintained Node.js 22 and 24 release lines on Linux, macOS, and Windows.
npm install
npm run check
npm run demoRun the MCP server over stdio:
npm run build
node dist/src/cli.js serveThe Phase 1 server exposes exactly three tools:
catalog.search
action.plan
policy.explain
The included catalog is a deterministic demo fixture. A downstream MCP client/proxy and external configuration arrive in Phase 2.
An approval is valid for one exact action, not for a server or tool name in general:
tool identity + schema + arguments + policy + authority + workspace + expiry
│
▼
canonical action digest
│
one-use approval capability
│
▼
execution receipt (next)Arguments are hashed and not stored raw in decision evidence. Tool schemas and effects come from an operator-controlled catalog, not from model-provided metadata. Workspace identity is reserved for gateway-observed values; the agent cannot label its own context as observed.
MCP gateways, policy engines, audit proxies, replay tools, and provenance systems already exist. ReproGate is designed to integrate with those systems, not rebuild all of them. Its differentiator is the portable contract spanning pre-execution authority and post-execution verification.
See idea validation, the phased roadmap, and the threat model.
Read CONTRIBUTING.md before opening a pull request. Security vulnerabilities should be reported privately according to SECURITY.md, never in a public issue.
Apache-2.0.
Create a digest-bound action envelope and evaluate deterministic policy; this Phase 1 tool never executes the action
| Name | Required | Description | Default |
|---|---|---|---|
| toolRef | Yes | ||
| arguments | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses a critical safety trait—'never executes the action'—which prevents misuse. However, it omits other behaviors such as side effects, prerequisites, or what happens on policy failure. The single disclosed trait is valuable but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose and key limitation. It avoids filler but uses jargon ('digest-bound action envelope') that may reduce clarity; still, it is appropriately compact for the information it delivers.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the absence of annotations and output schema, the description must stand alone. It does not define key terms (digest, action envelope, deterministic policy), explain inputs, describe return values, or provide usage context. Many operational details are missing, making it insufficient for a complex planning tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no explanation of the two parameters (toolRef and arguments). It does not clarify their roles or formats. With zero schema documentation and zero description compensation, agents are left to guess parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it creates a digest-bound action envelope and evaluates deterministic policy, explicitly noting it never executes the action. This verb+resource phrasing distinguishes it from siblings like catalog.search (search) and policy.explain (explanation), making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives. It implies a planning/evaluation phase via 'Phase 1' and 'never executes,' but does not mention sibling tools or conditions for selection. An agent would have to infer when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the trusted downstream tool catalog without exposing every schema
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description bears the full burden of behavioral disclosure. It reveals that the tool does not expose every schema, which is a useful limitation, but it does not mention whether the operation is read-only, returns partial results, handles pagination, or has any side effects. The behavioral transparency is minimal for a tool with no annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the verb and resource. The phrase 'without exposing every schema' is not redundant and serves as a useful caveat. There is no filler or unnecessary context, though the sentence could arguably be more explicit about query semantics.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool, the description is not complete. It gives no information about what the search results will contain, what fields are returned, or how the parameters behave. The absence of an output schema and lack of parameter descriptions mean an agent has to guess at basic invocation details. The 'without exposing every schema' hint partially addresses output, but not sufficiently.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention either 'query' or 'limit' at all. The description says nothing about what values should be provided, how the query is interpreted, or how limit affects results. With no parameter documentation in either the schema or description, this is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb ('Search') and resource ('the trusted downstream tool catalog'), and the qualifier 'without exposing every schema' distinguishes it from generic catalog queries. It is not a tautology and clearly separates the search intent from the sibling tools, which are about planning and policy explanation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus action.plan or policy.explain. It does not name alternatives, mention exclusions, or specify context such as 'when you need to find a downstream tool.' The usage is only implied by the tool's name and generic search phrasing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain the deterministic decision for a previously planned action
| Name | Required | Description | Default |
|---|---|---|---|
| actionId | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. 'Explain' strongly implies a read-only operation and 'deterministic' adds useful context, but the description does not mention prerequisites, error conditions, or whether any state is affected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence with no filler. It front-loads the key verb and object and omits redundant detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, this description is largely sufficient: it states the input's purpose and the operation being performed. It could add explicit mention of the return value or the need for the action to already exist, but those are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It meaningfully clarifies that actionId refers to a previously planned action, giving the lone parameter context beyond the bare schema entry.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Explain') and a clear resource ('deterministic decision for a previously planned action'). It distinguishes itself from siblings like action.plan by focusing on explaining an already-planned action rather than creating or searching for actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'previously planned action' clearly signals that this tool is appropriate after planning has occurred, not for creating plans or searching. It provides clear contextual guidance, though it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.0.0action.plancatalog.searchpolicy.explainScored across 3 tools
Each tool targets a distinct action: creating an action envelope with policy evaluation, searching the tool catalog, and explaining previous decisions. There is no overlap or ambiguity in their purposes.
All tool names follow the same domain.verb lowercase pattern (action.plan, catalog.search, policy.explain). The naming is uniform, predictable, and clearly groups tools by their domain.
Three tools is within the ideal range, and each tool serves a necessary and distinct function in the planning-and-policy workflow. The small set feels intentionally scoped rather than sparse.
The toolset covers the core workflow: discover actionable capabilities, plan an action with deterministic policy evaluation, and explain the resulting decision. As a Phase 1 non-executing gate, no obvious missing operations are present.
Deterministic authorization for one proposed AI agent action, returned with a signed receipt.
Tamper-evident proof creation and verification for AI agents via MCP, A2A, and REST.
Identity, authorization, audit trails, and revocable permissions for AI agents accessing MCP tools.
Give AI agents identity, permissions, and reusable proof through one MCP.