Agent Embassy

Ping

ping

Idempotent

Use ping when you define the test: give a URL plus your expectations — HTTP status (default 200), a required body substring, and/or an exact value at one JSON path — and get a per-condition pass/fail verdict from one fetch in a signed receipt. prove_it instead fixes the test at HTTP 200 and seals the transcript for others. For change alerts over time: watch. 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.05, USDC on Base or Arbitrum One. Paid URL: https://aemb.pro/v1/check/ping.

Input Schema

TableJSON Schema

Name	Required	Description
`url`	Yes	HTTPS URL to check (max 2000 chars; no credentials in URL). Fetched once; up to 3 redirects followed, 10s timeout, 1MB body cap
`expect_status`	No	Expected HTTP status code; truncated to an integer. Defaults to 200 when omitted
`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.
`expect_json_path`	No	Dot-separated path into the JSON body, e.g. 'data.price' (max 500 chars). Only evaluated when set
`expect_json_equals`	No	Expected value at expect_json_path; compared by canonical JSON equality. Defaults to null when omitted
`expect_body_contains`	No	Substring that must appear in the response body (max 5000 chars). Skipped when empty or omitted

Output Schema

TableJSON 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. ping
`asset`	Yes	Settlement asset
`price`	Yes	Exact price, e.g. "$0.05"
`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 15, 2026
- changedOutput schema / properties / price / description
```
Previous value: -"Exact price, e.g. \"$0.15\""New value: +"Exact price, e.g. \"$0.05\""
```
Changed1 schema field changedOct 15, 2026
- changedOutput schema / properties / tool / description
```
Previous value: -"Tool name, e.g. verified_check"New value: +"Tool name, e.g. ping"
```
AddedOct 4, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Adds meaningful context beyond the annotations: a single fetch producing a 'signed receipt,' plus payment mechanics ($0.05, USDC on Base or Arbitrum One) and the exact auth header (x402 v2). Annotations cover readOnly/idempotent/destructive but not billing or the signed-receipt behavior. The definition doesn't restate the redirect/timeout/body-cap limits here, but those live in the schema.

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?

Dense but front-loaded: routing (prove_it/watch) comes early, invocation and payment details follow. Four tightly-worded sentence groups with no filler. Slightly heavy on doc/payment links, but each element earns its place for an agent that must transact.

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?

Covers purpose, alternatives, invocation protocol, payment, and endpoint — the essentials for a paid, network-facing check tool. An output schema exists, so return-value structure needn't be explained. It could note rate limits or x402 negotiation fallback, but the definition is sufficient to call the tool correctly.

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

Parameters4/5

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

Schema coverage is 100%, so the schema documents each parameter thoroughly (including idempotency-key replay semantics and default status 200). The description reinforces the condition set (status default 200, required body substring, exact JSON-path value) without adding much beyond the schema, so it earns a solid but not top score.

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 states a specific verb and resource ('give a URL plus your expectations... get a per-condition pass/fail verdict from one fetch in a signed receipt') and explicitly distinguishes itself from siblings: 'prove_it instead fixes the test at HTTP 200 and seals the transcript for others.' This lets an agent route between ping, prove_it, and watch without opening schemas.

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?

Explicitly distinguishes when to use ping vs prove_it (ping when you define the test, prove_it when 200 is fixed and the transcript is sealed for others) and vs watch (for change alerts over time). It also gives the invocation path (POST JSON to paid_url with x402 v2 PAYMENT-SIGNATURE header).

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.

Resources

Need Help?