This server exposes a single MCP tool, verify_action, that checks a proposed action (or batch of actions) against a signed Agent Mandate envelope and returns a verification decision without executing anything.
Verify a single action or up to 500 actions in one call against a signed mandate envelope.
Return one of three literal decisions: allow, deny, or requires_approval.
Report violations, matched grant info, digest, mandate ID, principal, remaining spend, and evaluation metadata.
Validate action fields such as agent, action, resource, amountMinor, currency, approvalToken, priorCount, priorSpendMinor, and at.
Operate read-only: it does not issue, revoke, or mutate mandates, execute actions, change accounts, or call billing.
Require an AGENT_MANDATE_API_KEY and send at most one HTTPS request to https://agentmandate-api.com/v1/verify per tool call.
Enforce safety limits: 1 MiB request/response limits, 30-second timeout, no auto-retries, and provider errors reduced to safe status/code values.
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., "@agent-mandate-mcp Verify if this payment action is allowed under the mandate."
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.
Check a signed authorization envelope before trusting an agent's claimed authority.
Agent Mandate's MCP tool accepts the complete { mandate, signature } envelope
returned by POST /v1/mandates. Raw claims are not a signed envelope.
The walkthrough: create an envelope, verify an action through MCP, then change one signed field and verify again. You see the real verification result for each request, including the one that gets refused.
Requirements: Node.js 20 or newer, and an Agent Mandate API key.
Getting a key: the free tier includes 500 verified actions per month and needs no card. Issuing mandates is free and never consumes the allowance; one unit is one action verified. Paid plans start at $299/month for 10,000 verified actions. This walkthrough consumes at most two of your free units.
Running this in production? When a signed mandate is and is not worth it, with the published pricing. Short version: if the approval gate is one you control, a policy check inside your own service is simpler and cheaper. The signature earns its price when somebody other than you has to be able to verify the decision.
Just exploring? POST /v1/demo/verify takes raw claims, needs no key at all, and
is shown at the end. It does not replace the signed-envelope walkthrough, because it
does not check a signature.
git clone https://github.com/API-Disk-Integrations/agent-mandate-mcp.git
cd agent-mandate-mcp
git checkout v0.1.1
npm ci
AGENT_MANDATE_API_KEY=your_key node examples/verify-mandate.mjsThe example runner comes from this repository, but it installs
@api-disk-integrations/agent-mandate-mcp@0.1.1 from npm into a throwaway prefix
and runs that, so it exercises the published artifact rather than your working tree.
Omit AGENT_MANDATE_API_KEY and it prompts without echoing.
=== 1. Create a mandate ===
POST /v1/mandates -> 200
envelope keys: mandate, signature, requestId
signature: v1:b63eacaa7… (67 chars)
=== 3. Verify the action against the signed envelope ===
action: payments.transfer 30000 USD, approval required above 25000
decision: requires_approval
violation: Actions above 25000 minor units need a human approval token.
digest: c90fd0bc104dce63…
=== 4. Tamper with one signed field, keep the signature ===
raising approvalRequiredAboveMinor 25000 -> 999999, which would turn this into an allow
rejected: Agent Mandate error 400/invalid_request.
The tampered mandate did not buy an allow. The signature is doing its job.That is a real run against production, not illustrative output. The grant allows up to
100,000 minor units but requires approval above 25,000, and the action asks for 30,000,
so requires_approval is the correct answer. A deny or requires_approval is a
correct result, not a failure.
Verification reports a result; your application remains responsible for enforcing it.
Related MCP server: agenticrail-mcp
npx --yes @api-disk-integrations/agent-mandate-mcp@0.1.1A generic stdio client configuration:
{
"mcpServers": {
"agent-mandate": {
"command": "npx",
"args": ["--yes", "@api-disk-integrations/agent-mandate-mcp@0.1.1"],
"env": {
"AGENT_MANDATE_API_KEY": "${AGENT_MANDATE_API_KEY}"
}
}
}
}${AGENT_MANDATE_API_KEY} denotes the host's secret reference; use your client's
documented secret facility if its syntax differs. The package uses stdio and reads
exactly that environment variable. It has no remote /mcp endpoint.
Pin the version. 0.1.0 is still on the registry and has a first-use defect: its
input schema accepted any object for mandate, so a call built from the keyless
demo's shape returned HTTP 400.
If you would rather verify a checksummed artifact, every release also attaches a tarball and its SHA-256:
curl -fsSLO https://github.com/API-Disk-Integrations/agent-mandate-mcp/releases/download/v0.1.1/api-disk-integrations-agent-mandate-mcp-0.1.1.tgz
shasum -a 256 api-disk-integrations-agent-mandate-mcp-0.1.1.tgz # compare with the release page
npm install -g ./api-disk-integrations-agent-mandate-mcp-0.1.1.tgzEndpoint | Key | Takes |
| none |
|
| yes |
|
The envelope is the entire response body of POST /v1/mandates:
{mandate, signature, requestId}. Pass it through unchanged.
"mandate.mandate" must be the claims object means bare claims were passed where the
envelope belongs. Run POST /v1/mandates first and pass its whole response.
Step 1 — create a mandate. Issuing is free and does not consume your allowance.
curl -X POST https://agentmandate-api.com/v1/mandates \
-H "authorization: Bearer $AGENT_MANDATE_API_KEY" \
-H 'content-type: application/json' \
-d '{
"principal": "user_8814",
"agent": "agent_procurement_v3",
"expiresAt": "2026-12-31T23:59:59Z",
"currency": "USD",
"totalSpendCapMinor": 500000,
"grants": [{
"action": "payments.transfer",
"resources": ["vendor.acme"],
"maxAmountMinor": 100000,
"approvalRequiredAboveMinor": 25000
}]
}'Answers 200 with {"mandate": {…}, "signature": "…", "requestId": "…"}.
That whole body is the envelope.
Step 2 — verify an action against it. Call verify_action with the envelope as
mandate:
{
"mandate": { "mandate": { "…": "…" }, "signature": "…" },
"action": {
"agent": "agent_procurement_v3",
"action": "payments.transfer",
"resource": "vendor.acme",
"amountMinor": 30000,
"currency": "USD"
}
}curl -X POST https://agentmandate-api.com/v1/demo/verify \
-H 'content-type: application/json' \
-d '{"mandate":{"principal":"user_8814","agent":"a1","expiresAt":"2026-12-31T23:59:59Z","currency":"USD","totalSpendCapMinor":500000,"grants":[{"action":"payments.transfer","resources":["vendor.acme"],"maxAmountMinor":100000,"approvalRequiredAboveMinor":25000}]},"action":{"agent":"a1","action":"payments.transfer","resource":"vendor.acme","amountMinor":30000,"currency":"USD"}}'This route takes bare claims, not the envelope, and does not check a signature.
It does not issue or revoke mandates, execute an action, change an account, or call billing. It makes at most one API request per tool call and never retries automatically.
npm: @api-disk-integrations/agent-mandate-mcp
Official MCP Registry: io.github.API-Disk-Integrations/agent-mandate
source: API-Disk-Integrations/agent-mandate-mcp
There is exactly one tool, verify_action. Supply either one action or an
actions array, never both. A batch contains 1–500 actions. Monetary amounts
are non-negative integer minor units and require currency.
Example input:
{
"mandate": {
"mandate": {"id": "mnd_example"},
"signature": "caller-supplied-signature"
},
"action": {
"agent": "procurement-agent",
"action": "payments.transfer",
"resource": "vendor.acme",
"amountMinor": 2500,
"currency": "USD",
"at": "2026-09-05T20:00:00Z"
}
}Representative successful structured output:
{
"count": 1,
"receipts": [
{
"decision": "deny",
"mandateId": "mnd_example",
"violations": [{"code": "action_not_granted", "detail": "No matching grant"}]
}
]
}Treat all three decisions literally. In particular, neither allow nor
requires_approval executes the proposed action.
If AGENT_MANDATE_API_KEY is absent, the tool returns an MCP error before
making a request.
A provider error is reduced to its numeric HTTP status and an allowlisted code. Provider-controlled message and request-ID text is never returned to the model.
One tool call produces at most one HTTPS request to the fixed
https://agentmandate-api.com/v1/verify endpoint. There is no automatic
retry; Fetch uses explicit redirect: error, and redirect responses are
rejected without a follow-up request.
The serialized UTF-8 request and decoded response body each have a hard
1 MiB (1,048,576-byte) limit. The request is measured before Fetch. The
response is counted while streaming before JSON parsing, regardless of a
missing, misleading, or chunked Content-Length representation.
The request timeout defaults to 30 seconds. A batch is also limited to 500 actions. Provider account rate and monthly usage limits still apply; consult the current product pricing and documentation before production use.
The server is read-only with respect to mandate, account, and billing state, but an API verification consumes the caller's metered allowance.
Node.js 20 or newer is required. This release is tested for MCP protocol
revision 2026-07-28 and retains the SDK's listed 2025 compatibility
revisions.
The source link is not evidence that the npm package or Registry listing is available. Those two releases require their own public readback. A clone, install, download, tool call, or listing is not evidence of customer activation or revenue.
Verification only: evaluate supplied action facts against a signed mandate. The mandate argument is the envelope returned by POST /v1/mandates, which carries the claims under mandate alongside its signature — pass that response through unchanged. A bare claims object is what the keyless POST /v1/demo/verify route accepts, and it is rejected here. This tool does not execute the action or mutate any account.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | ||
| actions | No | ||
| mandate | Yes |
| Name | Required | Description |
|---|---|---|
| count | Yes | |
| receipts | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this non-mutating behavior and adds useful nuances: the mandate must be passed as the full envelope, not a bare claims object, which would be rejected. This goes beyond the annotations without contradicting them.
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?
Three tight sentences: the first states the core purpose, the second details the required mandate format, and the third rules out execution/mutation. Every sentence earns its place, and the most important information is front-loaded.
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 output schema covers return values and annotations cover safety, the description handles the key trap: correctly passing the mandate envelope. The only notable gap is the lack of orientation around the optional `action` and `actions` parameters, which could leave an agent unsure which to supply. Still, the core usage is well covered.
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 does a good job on the `mandate` parameter, explaining it is the envelope from POST /v1/mandates with claims under `mandate` beside `signature` and should be passed unchanged. However, it gives no guidance on the `action` vs `actions` parameters—whether they are alternatives, when each should be used, or what their fields mean—leaving that to inference from the schema.
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 opens with 'Verification only: evaluate supplied action facts against a signed mandate,' which states a specific verb, resource, and scope. It also explicitly distinguishes itself from executing or mutating, making the purpose unmistakable even without sibling tools.
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?
It clearly establishes this tool is for verification only and should not be used to execute actions ('This tool does not execute the action or mutate any account'). It also explains which input form is accepted ('mandate envelope returned by POST /v1/mandates') and which is rejected ('bare claims object'), providing practical usage context. It does not name alternatives, but there are no siblings, and the context is otherwise clear.
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.1.1verify_action3 fields changedInput schema / properties / mandate / propertiesAdded value: +{
+ "mandate": {
+ "additionalProperties": {},
+ "propertyNames": {
+ "type": "string"
+ },
+ "type": "object"
+ },
+ "signature": {
+ "minLength": 1,
+ "type": "string"
+ }
+}Input schema / properties / mandate / propertyNamesRemoved value: -{
- "type": "string"
-}Input schema / properties / mandate / requiredAdded value: +[
+ "mandate",
+ "signature"
+]v0.1.0verify_actionScored across 1 tool
Only one tool exists, so there is no possibility of confusing it with another tool in the server. Its scope is explicitly verification-only, which is clearly stated.
verify_action is a clear verb_noun name that matches the tool's single responsibility. With only one tool, there is no naming inconsistency or mixed convention.
One tool is thin by typical MCP standards, but the server explicitly scopes itself to verification-only functionality, so the count is reasonable. It is slightly under a typical multi-tool surface but not inappropriate.
Within its declared verification-only purpose, the tool has no obvious dead ends. However, the server assumes mandate envelopes are created externally, so there are no tools for managing or inspecting mandates, which is a notable but acceptable narrowing.
Deterministic allow/require_approval/deny verdicts for agent actions, before they happen.
Deterministic authorization for one proposed AI agent action, returned with a signed receipt.
Supervised API-write gateway for AI agents with policy, human approval and execution receipts.
Runtime permission, approval, and audit layer for AI agent tool execution.
