Skip to main content
Glama
Sign In

Agent Embassy

by pro.aemb
OverviewDiscussionsAdmin

Attest Work

attest_work
Idempotent

Notarize work done anywhere: submit evidence; we verify it and mint a signed receipt. evidence_urls + evidence_hash optional. Document's existence: attest_document. 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 — $222.00, USDC on Base or Arbitrum One. Paid URL: https://aemb.pro/v1/attest.

Input Schema

NameRequiredDescriptionDefault
evidence_hashNoSHA256 of work artifact
evidence_urlsNoURLs proving the work
idempotency_keyYesIdempotency key: 8-128 printable ASCII characters (no spaces), client-generated, one per logical request — a UUID v4 is recommended. 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.
work_descriptionYesWhat was done

Output Schema

NameRequiredDescriptionDefault
howYesHow to pay: POST the tool inputs as JSON to paid_url with an x402 v2 PAYMENT-SIGNATURE header
toolYesTool name, e.g. check_url_custom
assetYesSettlement asset
priceYesExact price, e.g. "$0.25"
networksYesEVM CAIP-2 network ids accepted
paid_urlYesx402-paid HTTPS URL to POST the tool inputs to
facilitatorYesx402 facilitator
payment_requiredYesAlways true: this MCP tool is a payment pointer; the tool itself is monetized via x402.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / idempotency_key / description
      Previous value: -"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."New value: +"Idempotency key: 8-128 printable ASCII characters (no spaces), client-generated, one per logical request — a UUID v4 is recommended. 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."
  2. Changed1 schema field changed
    • changedOutput schema / properties / price / description
      Previous value: -"Exact price, e.g. \"$0.05\""New value: +"Exact price, e.g. \"$0.25\""
  3. Added

TDQS

A4.3/5.0
Behavior5/5

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

The annotations say nothing about payment, yet the description discloses the price ($222.00 USDC), the accepted chains, the x402 v2 PAYMENT-SIGNATURE header requirement, and the exact paid endpoint. That is exactly the kind of auth/cost context the description is supposed to carry beyond structured fields.

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?

Purpose and the sibling disambiguation are front-loaded and the payment facts are compressed into two short sentences. The choppy, telegraphic fragments and the bare reference to 'paid_url' before it is defined slightly interrupt the flow.

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?

With an output schema present, the description needn't explain the receipt format, and it covers payment mechanics, endpoint, and the sibling distinction. What's missing is post-call behavior on verification failure, which matters for a paid mutation.

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%, including a very detailed idempotency_key description, so the schema does the heavy lifting. The description's only added parameter meaning is flagging evidence_urls and evidence_hash as optional, which is already implied by the required array in the schema.

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 outcome ('Notarize work done anywhere... we verify it and mint a signed receipt') and explicitly disambiguates from the sibling 'attest_document' by naming that tool's job (document existence). An agent can pick between the two without opening either schema.

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

Usage Guidelines4/5

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

It gives clear routing guidance against attest_document and notes that evidence_urls and evidence_hash are optional, which shapes how to call it. It falls short of a 5 because it never states prerequisites, exclusions, or what to do if verification fails.

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

All Agent Embassy toolsInspect
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