Skip to main content
Glama

agentpad_buy

ONE tool to buy an AgentPad token (default APBUILD) on its bonding curve: checks your agent pass, and returns the ordered unsigned calls you need (ERC-8004 identity if missing -> AgentPad pass if missing -> buy) plus an EIP-5792 wallet_sendCalls batch. ~$0.01 gas on Base. No profit promised.

Input Schema

NameRequiredDescriptionDefault
ethYesETH to spend, e.g. "0.01"
tokenNoAPBUILD (default), APAD, or a 0x token address
walletYesyour agent wallet (the one that will sign)
agentIdNoERC-8004 agentId you already own (skips the identity mint)
referrerNo
slippagePctNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that it checks the agent pass, returns unsigned calls rather than signing, produces an EIP-5792 wallet_sendCalls batch, and estimates about $0.01 gas on Base; but it omits permissions/auth needs, failure modes, slippage behavior, and whether it executes anything itself.

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?

The purpose is front-loaded and the ordered-call sequence is compactly expressed with arrows. The first sentence is dense but earns its place, and the short gas/disclaimer sentences are useful context.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a six-parameter transaction-building tool with no annotations and no output schema, the description does explain the return shape and prerequisite ordering. It still leaves important gaps around referrer/slippagePct semantics and failure/error behavior, so it is adequate rather than complete.

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 moderate at 67%, with wallet, eth, token, and agentId documented in the schema. The description mostly restates the default APBUILD and prerequisite flow, while referrer and slippagePct remain unexplained in both schema and description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Starts with a concrete verb and resource: buy an AgentPad token on its bonding curve, defaulting to APBUILD, and says it returns ordered unsigned calls plus an EIP-5792 batch. The orchestration behavior is clear, but it does not explicitly distinguish itself from siblings like build_buy_tx, onboard_and_buy, or quote_buy.

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

Usage Guidelines3/5

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

It implies when to use it (buying a token, including handling missing ERC-8004 identity or AgentPad pass) and gives a prerequisite sequence. However, it provides no explicit when-not guidance and does not compare against the many related buy/onboarding/build tools in the sibling list.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources