agent-embassy

Trust Assurance

trust_assurance

Idempotent

Action gate: endpoint, action, amount, permissions probed unpaid — ALLOW, RESTRICT, ASK_HUMAN, or QUARANTINE. Verdict: trust_report. Terms: trust_preflight. POST the tool inputs as JSON to paid_url with an x402 v2 PAYMENT-SIGNATURE header. See https://docs.cdp.coinbase.com/x402 Paid tool — $0.25, USDC on Base or Arbitrum One. Paid URL: https://aemb.pro/v1/assurance/check.

Input Schema

Name	Required	Description
`action`	Yes	The action the agent intends to take, e.g. 'transfer' (required, max 200 chars)
`context`	No	Optional free-text context for the assessment (truncated to 2000 chars)
`amount_usdc`	Yes	Amount at stake, as a positive decimal string, e.g. '0.25'
`idempotency_key`	Yes	Idempotency key: UUID v4, client-generated, one per logical request. Replaying the same key on this tool returns the original receipt — the action is not re-run, and the first request's receipt wins even if you resend different inputs. Published example keys are rejected. Keys are scoped per tool and per payer account: a key never returns another wallet's receipt.
`provider_endpoint`	Yes	HTTPS URL of the provider to assess (max 2000 chars; no credentials in URL)
`permissions_requested`	Yes	Permissions the action needs, e.g. ['spend']. Non-empty array, max 50 entries; each entry truncated to 200 chars

Output Schema

Name	Required	Description
`how`	Yes	How to pay: POST the tool inputs as JSON to paid_url with an x402 v2 PAYMENT-SIGNATURE header
`tool`	Yes	Tool name, e.g. check_url_custom
`asset`	Yes	Settlement asset
`price`	Yes	Exact price, e.g. "$0.25"
`networks`	Yes	EVM CAIP-2 network ids accepted
`paid_url`	Yes	x402-paid HTTPS URL to POST the tool inputs to
`facilitator`	Yes	x402 facilitator
`payment_required`	Yes	Always true: this MCP tool is a payment pointer; the tool itself is monetized via x402.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026
- changedOutput schema / properties / price / description
```
Previous value: -"Exact price, e.g. \"$0.05\""New value: +"Exact price, e.g. \"$0.25\""
```
AddedOct 17, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations cover safety, idempotency and open-world reach, and the description adds real context beyond them: it is a paid call ($0.25 USDC on Base or Arbitrum One) requiring an x402 v2 PAYMENT-SIGNATURE header against a named paid URL. That payment/auth mechanics detail is exactly what annotations cannot express; it stops short of covering failure modes or payment-expiry behavior.

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

Conciseness4/5

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

Front-loaded with the purpose and the possible verdicts, then transport details, then price and URL — a sensible priority order with no filler. The shorthand style ("Verdict: trust_report. Terms: trust_preflight.") is terse to the point of ambiguity but every sentence carries information.

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

Completeness4/5

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

For a paid, open-world gate the essentials are present: what is probed, the four outcomes, that a receipt/verdict comes back (output schema covers its shape), payment protocol, price, chain and endpoint. Missing only operational details such as what happens on payment failure or expiry.

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?

Schema coverage is 100%, so the schema already documents all six parameters, including the idempotency-replay semantics. The description only echoes endpoint, action, amount and permissions and says nothing about idempotency_key or context, so it does not exceed the baseline.

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

Purpose4/5

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

"Action gate" with the enumerated outputs (ALLOW, RESTRICT, ASK_HUMAN, QUARANTINE) states a specific verb and scope, and it explicitly separates roles from siblings: trust_report produces the verdict artifact, trust_preflight covers terms. The telegraphic phrasing requires a second read, but an agent can distinguish it from siblings without opening a schema.

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

Usage Guidelines3/5

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

It implies usage (pre-action risk gating) and points to trust_preflight for terms, but never states when an agent should call this instead of trust_report or trust_preflight, nor any preconditions. The routing hints are present but the when/when-not decision rule is left to inference.

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

All agent-embassy tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.