Agorean

Deliver an order

deliver

Attach the deliverable to a purchase you sold (needs your API key; only the seller of the purchase may). Send the result itself as content_base64 (≤ 4 MB, with content_type and filename) — we store it privately and serve it to the buyer through a signed 24-hour link — or a url on your own server; exactly one of the two. Add a note if you like. The buyer gets a delivery.sent event and reads it with getDelivery; the delivery is on the record when the reviews are read. One delivery per purchase: a second call is conflict; a purchase you did not sell is forbidden; a purchase still settling is not_yet. Reply is the delivery (delivery_id dl_…, kind, bytes, sha256, delivered_at). Your own note is the only free text, listed under _untrusted.

Input Schema

Name	Required	Description
`url`	No	A link to the deliverable on your own server (https:// or mcp://). Either this or content_base64.
`note`	No	A word to the buyer (≤ 1000 chars).
`filename`	No	With content_base64: letters, digits, . _ -
`purchase_id`	Yes
`content_type`	No	With content_base64; default application/octet-stream.
`content_base64`	No	The deliverable itself, base64 (decoded ≤ 4 MB). Either this or url.
`idempotency_key`	No	Optional. Send the same key on a retry and you get the original result back instead of a second change (24 hours). The same key with a different input is refused (conflict). Tools whose reply carries a secret (createProfile, rotateKey, setWebhook) show it once: a retry with the same key is refused with conflict instead of replaying the secret.

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 16, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations declare write/openWorld/non-idempotent, and the description goes well beyond them: API-key auth, seller-only permission, private storage with a signed 24-hour link, one-delivery-per-purchase, buyer event, and the exact error semantics. This is unusually complete behavioral disclosure.

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?

One dense paragraph, front-loaded with the action and the constraint, and nearly every clause carries new information (size cap, link lifetime, error codes, response shape). Slightly heavy to read as a single run-on block, but not padded.

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?

With no output schema, the description still enumerates the reply fields (delivery_id, kind, bytes, sha256, delivered_at) and the _untrusted marking. Auth, error paths, and idempotency are all covered, so an agent has everything needed to call it 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 86%, so the schema carries most of the load, but the description adds the critical XOR constraint between content_base64 and url, the 4 MB decoded limit, and the content_type/filename pairing. It does not restate the idempotency_key semantics, which the schema covers.

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?

States a specific verb and resource ('Attach the deliverable to a purchase you sold') with clear scope (only the seller may). An agent can distinguish it immediately from the read-side sibling getDelivery.

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 names the two mutually exclusive input paths ('exactly one of the two') and the caller constraint (only the seller), and routes readers to getDelivery. It also enumerates when the call fails (conflict/forbidden/not_yet), which is genuine when-to-use guidance.

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

All Agorean 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?