Loading ToolBench

Reading the current corpus…

agent-mandate-mcp MCP server · C · ToolBench

← Browse

agent-mandate-mcp

github.com/API-Disk-Integrations/agent-mandate-mcp

Verification-only MCP server for evaluating actions against signed Agent Mandates.

2025-06-18+STDIO1 tools

68/100

Definition Quality85

Protocol Readiness50

Supportability50

Spec posture

Inferred effective spec 2025-06-18+·current baseline 2026-07-28

Static source inference · medium confidence · evidence: structured output

No deprecated protocol patterns detected

Summary

Single tool 'verify_action' has a well-structured schema with comprehensive parameter definitions, clear descriptions, and proper type constraints. The tool name is action-oriented (verify_*). Description is detailed (200+ chars) and explains the mandate envelope requirement, which is critical domain knowledge. Input schema includes nested objects with minLength/minimum constraints. Output schema is documented. Tool annotations (readOnlyHint, destructiveHint, idempotentHint, openWorldHint) are present and correct. Error handling returns structured responses with isError flag and actionable messages. However, the schema is complex with mutually exclusive 'action' vs 'actions' parameters, this could be clearer in parameter descriptions. The tool is verification-only (no mutation), which is appropriate for the domain.

Tools (1)

verify_actionread onlyauthsource verified85/100

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.

Issues (4)

MEDIUMconstrained-input ↗

Mutually exclusive parameters (action vs actions) lack explicit documentation in parameter descriptions. LLMs may pass both or neither, causing ambiguous failures.

verify_action

MEDIUMtool-description ↗

Parameter 'at' (ISO 8601 datetime) lacks format specification in schema. Description says 'ISO 8601 datetime with offset' but schema has no format constraint, allowing invalid dates.

verify_action

MEDIUMrecovery-guide ↗

Error responses omit the invalid mandate/action details. When verification fails, the LLM receives only 'Agent Mandate error 400/invalid_signature' with no hint about which field caused rejection or how to recover.

verify_action

HIGHtool ↗

Output schema (verifyActionOutput) is referenced but not shown in source. Cannot verify that response structure includes decision (allow/deny/requires_approval), reasoning, or next steps.

verify_action

Recommendations

Add explicit constraint in parameter descriptions: 'Pass exactly one of action (single) or actions (array of 1-500). Passing both or neither will fail.'
Add 'format': 'date-time' to the 'at' parameter schema and clarify in description: 'ISO 8601 format with timezone offset, e.g. 2024-12-15T14:30:00+00:00'
Enhance error responses to include the rejected field and constraint: 'Invalid mandate: signature does not match claims. Verify the envelope was not tampered with.' or 'Action amount_minor (50000) exceeds approval limit (25000), requires_approval decision.'
Document the output schema (verifyActionOutput) in the source or inline. Ensure response includes: decision (enum: allow|deny|requires_approval), reason (string), and any required next steps.
Add a 'dry_run' or 'explain' parameter to help agents understand why a decision was made without consuming metered API units on repeated calls.

Score history

Overall score trend

First recorded score · v2 rubric

68/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-23	C	68	2025-06-18+	v2