Skip to main content
Glama

Real Real Genuine

by io.github.richardjhobbs

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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
tokenIdYesThe token ID of the drop to purchase
buyerWalletYesYour wallet address on Base
selected_sizeNoFor 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.
selected_colorNoFor 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.

TDQS

A4/5.0
Behavior3/5

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

With no annotations, the description provides the critical context that this tool returns payment instructions (payTo and amount) and that a manual USDC transfer is required before calling confirm_agent_purchase. However, it does not disclose whether calling the tool has side effects (e.g., reserving inventory, expiring instructions) or any auth/rate-limit constraints, leaving a transparency gap.

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

Conciseness5/5

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

The description is three focused sentences: a purpose tag, a use condition, and a concise next-step workflow. Every sentence adds value, and the most critical information is front-loaded.

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 purchase initiation tool with no annotations and no output schema, the description covers the essential steps: getting instructions, paying USDC to payTo on Base mainnet, and confirming with a transaction hash. It still does not specify the response structure or any expiration/holding behavior, but the workflow is sufficiently complete for invocation.

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?

The input schema already covers all parameters with detailed descriptions (100% coverage), so the description adds no new parameter-level detail. It does clarify the overall purchase flow but not the meaning of tokenId/buyerWallet beyond the schema, so the baseline score of 3 applies.

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 opens with '[BUY, Agent Step 1]' and states 'Get payment instructions for a direct USDC transfer purchase,' clearly identifying the action and resource. It distinguishes from siblings by noting it is for agents that cannot sign EIP-712 permits, and references confirm_agent_purchase as the follow-up.

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 explicitly says 'Use this if you are an AI agent that cannot sign EIP-712 permits,' giving a clear condition. The follow-up instructions ('send exactly the specified USDC amount to payTo... then call confirm_agent_purchase') explain the workflow. However, it does not explicitly name an alternative tool (e.g., initiate_purchase) for permit-capable agents, so the when-not is implied rather than stated.

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 toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.9/5.0
Disambiguation4/5

Most tools have distinct purposes with clear category tags. Minor potential confusion between get_current_brief vs list_briefs and get_brand vs get_brand_mcp_endpoint, but descriptions clarify intent.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern using lowercase with underscores, e.g., check_agent_standing, list_drops, submit_design. No mixing of conventions.

Tool Count3/5

32 tools is on the high side, but the server covers a wide domain including browsing, purchasing, design submission, concierge, and marketing. Each tool serves a specific function, though some consolidation could be possible.

Completeness4/5

The tool surface covers the full lifecycle of browsing, purchasing, design creation, commissions, and concierge services. Minor gaps like refund handling are absent, but the core workflows are well-supported.

Resources