Loading ToolBench
Model Context Protocol server for Postcept, outcome verification for AI agents. Lets an agent verify its own high-risk actions (refunds, cancellations, ticket resolutions) against the system of record and receive a signed completion receipt.
Postcept MCP demonstrates solid tool design with clear, domain-specific naming (verify_* pattern), comprehensive parameter descriptions, and well-structured schemas using Zod. All 6 tools have explicit descriptions (194 - 280 chars, within baseline 34 - 392 range) and typed input schemas. Tool annotations (readOnlyHint, destructiveHint, openWorldHint) are present. However, output schemas are not documented in the source, responses are formatted via helper functions (formatVerification, formatVcr) but the structure is not visible in the code provided. Error handling delegates to PostceptApiError but lacks actionable recovery guidance. Parameter descriptions are strong but could benefit from explicit constraint documentation (e.g., 'amount_cents must be non-negative integer').
Fetch a past verification (and its signed receipt) by id, e.g. to re-read the result or the receipt after the original call.
Re-run a past verification against the live system of record (continuous reconciliation). Use this to catch a completion that has since regressed (e.g. a refund that was later reversed) or recovered. Returns the refreshed classification and receipt.
The organization's Verified Completion Rate: the fraction of claimed completions that were verified, and a breakdown by outcome (verified, incomplete, duplicated, mismatched, policy_failed).
Verify that a subscription the agent claims to have cancelled is actually cancelled in the system of record (default Stripe). Returns the classification and a signed receipt.
Verify that a refund the agent claims to have issued actually completed in the system of record (default Stripe). Checks the refund exists, the amount and currency match, the customer matches, and that it was not duplicated. Returns the classification (verified / incomplete / duplicated / mismatched / policy_failed) and a signed receipt.
Output schemas not documented in source code. Helper functions (formatVerification, formatVcr) format responses, but the structure is not visible. LLMs cannot plan downstream operations without knowing what fields to expect.
Error handling returns raw PostceptApiError messages without actionable recovery guidance. 'Postcept request failed (HTTP 400): ...' tells the agent nothing about whether to retry, ask the user, or escalate.
Parameter constraints (e.g., amount_cents must be non-negative, currency must be ISO 4217) are enforced via Zod but not explicitly stated in descriptions. LLMs cannot read JSON Schema, they rely on description text.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 66 | 2026-07-28+ | v2 |
Verify that a support ticket the agent claims to have resolved is in the expected state in the support system of record (Zendesk, Gorgias, Intercom, Front, or ServiceNow). Returns the classification and a signed receipt.
verify_ticket accepts 'connector' enum that includes payment systems (stripe, shopify, hubspot, netsuite) alongside support systems (zendesk, gorgias, intercom, front, servicenow). This is confusing, the tool is for support tickets, not payments.
No pagination or result limits documented for verified_completion_rate. If the breakdown includes thousands of verification records, response could be very large.