Real Real Genuine

initiate_agent_purchase

[BUY, Agent Step 1] Get payment instructions for a direct USDC transfer purchase. Use this if you are an AI agent that cannot sign EIP-712 permits.

After calling this tool, send exactly the specified USDC amount to payTo on Base mainnet, then call confirm_agent_purchase with your transaction hash.

PHYSICAL PRODUCTS: the amount includes shipping. Pass the delivery address; if you omit shipping_rate_handle the tool returns the live shipping options (in USDC) for that address instead of payment instructions. Call again with the handle you chose. Pass the same address and handle to confirm_agent_purchase, the server re-quotes them at settlement.

Input Schema

TableJSON Schema

Name	Required	Description
`tokenId`	Yes	The token ID of the drop to purchase
`buyerWallet`	Yes	Your wallet address on Base
`selected_size`	No	For sized products (e.g. sneakers, garments), the size you want to buy (e.g. "10.5", "M"). Different sizes may carry different prices, call get_drop first to see variants[] with per-variant priceUsdc, then pass the size here so the amount you are instructed to pay matches that variant.
`shipping_city`	No	City (required for physical products)
`shipping_name`	No	Recipient name (physical products)
`selected_color`	No	For products with a colour axis (e.g. a filtered showerhead in five finishes), the colourway you want to buy. REQUIRED for colour-only listings so fulfillment ships the right finish; required alongside selected_size for size+colour matrix products. Inspect variants[] from get_drop_details to see available colours.
`shipping_phone`	No	Phone number for the carrier
`shipping_state`	No	State / province code (required for US, CA, AU)
`shipping_country`	No	ISO 3166-1 alpha-2 country code, e.g. "GB" (required for physical products)
`shipping_postal_code`	No	Postal / ZIP code (required for physical products)
`shipping_rate_handle`	No	Handle of the shipping option you chose from a previous call. Omit to list the options for the address.
`shipping_address_line1`	No	Street address line 1 (required for physical products)
`shipping_address_line2`	No	Street address line 2

Schema Changelog

Changes observed during successful MCP inspections.

Changed9 schema fields changedSep 20, 2026

addedInput schema / properties / shipping_address_line1

Added value: +{
+  "description": "Street address line 1 (required for physical products)",
+  "type": "string"
+}

addedInput schema / properties / shipping_address_line2

Added value: +{
+  "description": "Street address line 2",
+  "type": "string"
+}

addedInput schema / properties / shipping_city

Added value: +{
+  "description": "City (required for physical products)",
+  "type": "string"
+}

addedInput schema / properties / shipping_country

Added value: +{
+  "description": "ISO 3166-1 alpha-2 country code, e.g. \"GB\" (required for physical products)",
+  "type": "string"
+}

addedInput schema / properties / shipping_name

Added value: +{
+  "description": "Recipient name (physical products)",
+  "type": "string"
+}

addedInput schema / properties / shipping_phone

Added value: +{
+  "description": "Phone number for the carrier",
+  "type": "string"
+}

addedInput schema / properties / shipping_postal_code

Added value: +{
+  "description": "Postal / ZIP code (required for physical products)",
+  "type": "string"
+}

addedInput schema / properties / shipping_rate_handle

Added value: +{
+  "description": "Handle of the shipping option you chose from a previous call. Omit to list the options for the address.",
+  "type": "string"
+}

addedInput schema / properties / shipping_state

Added value: +{
+  "description": "State / province code (required for US, CA, AU)",
+  "type": "string"
+}

Changed1 schema field changedJun 2, 2026

changedInput schema / properties / selected_size / description

Previous value: -"For sized products (e.g. sneakers, garments), the size you want to buy (e.g. \"10.5\", \"M\"). Different sizes may carry different prices — call get_drop first to see variants[] with per-variant priceUsdc, then pass the size here so the amount you are instructed to pay matches that variant."New value: +"For sized products (e.g. sneakers, garments), the size you want to buy (e.g. \"10.5\", \"M\"). Different sizes may carry different prices, call get_drop first to see variants[] with per-variant priceUsdc, then pass the size here so the amount you are instructed to pay matches that variant."

Changed2 schema fields changedMay 4, 2026

addedInput schema / properties / selected_color

Added value: +{
+  "description": "For products with a colour axis (e.g. a filtered showerhead in five finishes), the colourway you want to buy. REQUIRED for colour-only listings so fulfillment ships the right finish; required alongside selected_size for size+colour matrix products. Inspect variants[] from get_drop_details to see available colours.",
+  "type": "string"
+}

changedInput schema / properties / selected_size / description

Previous value: -"For sized products (e.g. sneakers, garments), the size you want to buy (e.g. \"10.5\", \"M\"). Different sizes may carry different prices — call get_drop first to see variants[] with per-size priceUsdc, then pass the size here so the amount you are instructed to pay matches that size."New value: +"For sized products (e.g. sneakers, garments), the size you want to buy (e.g. \"10.5\", \"M\"). Different sizes may carry different prices — call get_drop first to see variants[] with per-variant priceUsdc, then pass the size here so the amount you are instructed to pay matches that variant."

Changed1 schema field changedApr 23, 2026

addedInput schema / properties / selected_size

Added value: +{
+  "description": "For sized products (e.g. sneakers, garments), the size you want to buy (e.g. \"10.5\", \"M\"). Different sizes may carry different prices — call get_drop first to see variants[] with per-size priceUsdc, then pass the size here so the amount you are instructed to pay matches that size.",
+  "type": "string"
+}

First observedMar 22, 2026

TDQS

A4.1/5.0

Behavior4/5

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

No annotations are present, so the description carries the full disclosure burden, and it delivers: the two-step settlement flow, the payTo/USDC amount target, the exact branching when shipping_rate_handle is omitted (returns live shipping options vs payment instructions), and the re-quote-at-settlement behavior. This is genuine behavioral disclosure beyond the function name.

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?

Three focused paragraphs with the purpose and use-condition front-loaded before the workflow and the shipping edge case. Each block earns its place; there is minor redundancy with the schema's variant-mapping notes, but nothing wasted.

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?

Complete for a 13-param tool with no output schema and no annotations: it explains the return value (payment instructions with payTo and exact USDC amount), the required follow-up tool (confirm_agent_purchase), and the shipping re-quote nuance. Parameters are covered by the 100%-coverage schema, and behavior is covered by the description.

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 13 parameters, placing this at baseline 3. The description adds workflow context (omit shipping_rate_handle to list options, re-quote at settlement, size/color matching variants) rather than new syntax, which is useful but not a semantic leap over 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?

States a specific verb+resource ('Get payment instructions for a direct USDC transfer purchase') and sharpens scope with the [BUY, Agent Step 1] tag and the explicit EIP-712 exclusion, which separates it from the sibling initiate_purchase. An agent knows exactly what this does and how it differs from the signing-based alternative.

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?

Gives an explicit when-to-use condition ('if you are an AI agent that cannot sign EIP-712 permits') and a clear post-call workflow (send USDC to payTo, then call confirm_agent_purchase with the tx hash). It stops just short of naming the signing-capable alternative (initiate_purchase) outright, so the exclusion is implied rather than fully spelled out.

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

All Real Real Genuine 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?