MandateShield AI Payment Evidence

Check AI Payment Authority

check_ai_payment_authority

Idempotent

Use before an AI agent buys, subscribes, transfers value, calls a metered API, or accesses a paid resource when the user wants a payment-authority check. Analyze whether the proposed purchase fits supplied policy facts. This v1 entry check is non-executable and always returns enforcement_authorized=false; use the strict cryptographic tool for a production gate. Never send payment credentials or private keys.

Input Schema

TableJSON Schema

Name	Required	Description
`amount`	Yes
`limits`	No	Sandbox analysis policy. Live v2 ignores caller policy and loads the registered mandate.
`network`	No	Exact network or chain identifier; required for atomic X402 payments.
`purpose`	No	Non-sensitive plain-language purchase purpose.
`agent_id`	Yes	Stable identifier for the acting AI agent.
`asset_id`	No	Exact token or asset identifier; required for atomic X402 payments.
`protocol`	Yes	Source protocol or CUSTOM for a normalized envelope.
`resource`	No	Exact paid resource identifier; required for atomic X402 payments.
`created_at`	No
`expires_at`	No
`mandate_id`	Yes	Stable identifier for the user-approved authority.
`intent_hash`	No
`merchant_id`	Yes	Stable identifier for the final seller or payee.
`http_request`	No	Optional signed HTTP action projection used by the narrow first-party x402 v2 exact/EIP-3009 Gate adapter.
`user_consent`	No
`checkout_hash`	No	Digest or stable identifier for the exact final checkout.
`payee_identity`	No	Versioned canonical payee identity bound into the signed purchase envelope. The model records exact provider identifiers and verification evidence; it does not independently validate an external registry, TLS session, provider account or domain-control document.
`idempotency_key`	Yes	Unique identifier for this intended payment attempt.
`credential_binding`	No

Output Schema

TableJSON Schema

Name	Required	Description
`mode`	Yes
`risk`	Yes
`error`	No
`score`	Yes	Deterministic control-coverage indicator, not a calibrated probability of fraud or loss.
`receipt`	Yes
`controls`	Yes
`decision`	Yes
`findings`	Yes
`protocol`	Yes
`persisted`	Yes
`checked_at`	Yes
`recommended_action`	Yes
`enforcement_authorized`	Yes	True only when strict live verification durably creates a trusted, consumable execution reservation. It never permits a direct provider call.

TDQS

A3.9/5.0

Behavior1/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states 'This v1 entry check is non-executable and always returns enforcement_authorized=false', which implies a read-only stub. However, annotations mark readOnlyHint=false, suggesting potential side effects. This is a direct contradiction between the description and annotation, requiring a score of 1.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with purpose, then behavioral disclosure, then a security warning. Every sentence contributes essential information with no redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite 19 parameters and nested objects, the description covers the key context: what the tool does, its non-executable stub behavior, the alternative for production, and a security warning. The output schema documents return values, so no further return detail is needed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description adds high-level context that parameters represent a proposed purchase and policy facts, but does not detail specific parameters. Schema descriptions cover 68% of parameters and explain many fields (e.g., currency codes, atomic amounts, identifiers), so the description provides only marginal added value.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Use before an AI agent buys, subscribes, transfers value, calls a metered API, or accesses a paid resource when the user wants a payment-authority check. Analyze whether the proposed purchase fits supplied policy facts.' This clearly states the tool's purpose and distinguishes it from the sibling 'strict cryptographic tool' for production gates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit when-to-use guidance is provided ('Use before an AI agent buys, subscribes...'), and an alternative is named ('use the strict cryptographic tool for a production gate'). Safety guidance ('Never send payment credentials or private keys') further clarifies usage constraints.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All MandateShield AI Payment Evidence tools Inspect

Try in Browser

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4.2/5.0

Disambiguation4/5

Tools have distinct purposes: check is a non-executable entry check, normalize maps protocols, and verify is a cryptographic production gate. However, the conceptual overlap between check and verify could cause slight confusion, but the descriptions clearly differentiate them.

Naming Consistency5/5

All tools follow a consistent verb_object pattern using snake_case, e.g., check_ai_payment_authority, normalize_agent_payment_protocol, verify_cryptographic_payment_authority. The verbs are distinct and the naming is descriptive.

Tool Count5/5

With exactly 3 tools, the server is well-scoped for its domain of payment authority checks. Each tool serves a necessary and non-redundant role in the workflow.

Completeness3/5

The server covers the core authority check flow (non-executable check, protocol normalization, cryptographic verification). However, it lacks tools for mandate creation, payment execution, or post-authorization steps, leaving notable gaps for a complete payment lifecycle.

Resources

Need Help?