Quote and build unsigned buy/sell transactions for $AI on its HyperEVM bonding curve. No keys held.
Scored across 5 tools
Each tool has a clearly distinct purpose: read-only quotes (ai_quote_buy, ai_quote_sell), transaction builders (ai_build_buy_tx, ai_build_sell_tx), and a market snapshot (ai_market). The descriptions explicitly cross-reference each other to guide correct selection and prevent confusion.
All names use snake_case with an ai_ prefix, and the buy/sell pairs are parallel across quote and build tools. However, ai_market is a noun rather than a verb_noun pattern, which is a minor deviation from an otherwise consistent convention.
Five tools is well-scoped for a token trading interface on a single contract. Each tool (quote buy, quote sell, build buy, build sell, market) serves a distinct necessary function without redundancy or bloat.
The core buy/sell lifecycle is well covered, including quotes, slippage handling, and approve-then-sell sequencing. Minor gaps exist: no explicit tool to read a user's token balance or allowance, and no HYPE wrapping/unwrapping operation, though agents can likely work around these.
Build an unsigned buy transaction against the AiCurve contract. Returns calldata only; the caller signs and sends it. Includes an estimated gas limit when from is given. The minimum $AI out is the live quote minus slippage_bps, so a price move past that tolerance makes the tx revert instead of filling worse. Use ai_quote_buy to preview without building; use ai_build_sell_tx to sell.
| Name | Required | Description | Default |
|---|---|---|---|
| from | No | 0x sender address; when given the tx includes a gas estimate | |
| hype | Yes | HYPE amount to spend, decimal string, max 10000 | |
| slippage_bps | No | Slippage tolerance in basis points, 0-5000, default 200 |
| Name | Required | Description |
|---|---|---|
| tx | Yes | |
| quote | Yes | |
| disclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, and the description adds valuable behavioral context beyond that: it returns calldata only, includes a gas estimate conditionally on 'from', and enforces a minimum output via slippage that causes reverts on adverse price moves. This gives the agent a strong mental model of execution behavior without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and every sentence earns its place. It front-loads the primary purpose and output, then adds conditional gas-estimate behavior, slippage protection semantics, and sibling routing in a tight, well-ordered format.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has an output schema, so return values are already covered. The description supplies the remaining context an agent needs: when to use it, what it returns, how gas estimation works, how slippage affects reverts, and which sibling tools to use instead. Nothing important is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all parameters. The description adds meaningful semantics by explaining that 'from' triggers a gas estimate, that 'hype' is the spend amount, and that 'slippage_bps' determines the minimum acceptable output and revert behavior. This goes beyond simply restating the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Build'), a clear resource ('unsigned buy transaction against the AiCurve contract'), and the core output ('Returns calldata only'). It also differentiates itself from siblings by naming ai_quote_buy and ai_build_sell_tx, so an agent can distinguish this from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool versus alternatives: 'Use ai_quote_buy to preview without building; use ai_build_sell_tx to sell.' It also clarifies that the caller signs and sends the returned calldata, making the tool's role in a larger workflow clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build the unsigned transaction(s) to sell $AI: an approve first if allowance is insufficient, then the sell. Returns calldata only; the caller signs and sends, in order. When an approve is included, send the sell after the approve is mined and estimate its gas then. The minimum HYPE out is the net quote minus slippage_bps. Use ai_quote_sell to preview without building; use ai_build_buy_tx to buy.
| Name | Required | Description | Default |
|---|---|---|---|
| ai | Yes | $AI amount to sell, decimal string, max 1000000000 | |
| from | Yes | 0x seller address, required to check allowance and estimate gas | |
| slippage_bps | No | Slippage tolerance in basis points, 0-5000, default 200 |
| Name | Required | Description |
|---|---|---|
| quote | Yes | |
| steps | Yes | |
| disclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint=true and destructiveHint=false, and the description builds on this by explaining the tool returns calldata only (caller signs and sends), that an approve may be included and must be mined before the sell, and that minimum HYPE out is net quote minus slippage. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, no filler, with the core purpose front-loaded. Every sentence earns its place: purpose, behavioral contract, and routing to alternatives.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a transaction-building tool with an output schema, the description covers all critical operational details: approve-first logic, sequencing, gas estimation timing, minimum out calculation, and pointer to the quote preview tool. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds meaning to slippage_bps by explaining how it determines the minimum HYPE out, which goes beyond the schema's 'slippage tolerance' definition. The ai and from parameters are not further elaborated, but the schema already fully documents them.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Build the unsigned transaction(s) to sell $AI'. It also differentiates from siblings by explicitly naming ai_quote_sell (preview) and ai_build_buy_tx (buy), leaving no ambiguity about what this tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-to-use guidance ('to sell $AI'), when-not-to-use (use ai_quote_sell to preview, ai_build_buy_tx to buy), and precise sequencing requirements: send approve first, wait for it to be mined, then estimate gas for the sell. This is the gold standard for usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read-only snapshot of the $AI/HYPE AiCurve: price, sold, retired, circulating, reserve, supply, sell fee (read live from chain), contracts, chain id, rpc, and the fee/no-guarantee disclosure. Takes no amount; for a price on a specific amount use ai_quote_buy (the recommended first call) or ai_quote_sell.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| rpc | Yes | |
| sold | Yes | |
| supply | Yes | |
| chainId | Yes | |
| retired | No | |
| contracts | Yes | |
| priceHype | Yes | |
| disclosure | Yes | |
| sellFeeBps | Yes | |
| circulating | No | |
| reserveHype | No | |
| priceHypeWei | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the bar is lower. The description adds real value beyond them: data is 'read live from chain', no argument is required, and the response includes a fee/no-guarantee disclosure. It doesn't cover rate limits or freshness/staleness semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Front-loaded with purpose and constraints, no filler. The long enumeration of fields leans on the output schema, but each item aids scanning and the routing sentence is well placed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-argument read tool with an output schema and full annotation coverage, this is nearly complete. The only minor gap is not clarifying its relationship to the tx-building siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Zero parameters, which is the baseline-4 case. The description reinforces this explicitly ('Takes no amount'), so an agent won't go looking for parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Read-only snapshot of the $AI/HYPE AiCurve') and enumerates exactly what the snapshot contains. It also differentiates itself from ai_quote_buy/ai_quote_sell by noting those are for a price on a specific amount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context: no amount is taken, and points to ai_quote_buy (flagged as 'the recommended first call') or ai_quote_sell when a price for a specific amount is needed. It does not address ai_build_buy_tx/ai_build_sell_tx, leaving the sibling routing partly incomplete.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recommended first call for a new agent: quote how much $AI a given amount of HYPE buys right now, before slippage. Read-only, no wallet needed, no key, no transaction. To buy it for real, call ai_build_buy_tx next with the same hype amount.
| Name | Required | Description | Default |
|---|---|---|---|
| hype | Yes | HYPE amount as a decimal string, e.g. "1.5" (max 10000) |
| Name | Required | Description |
|---|---|---|
| tokensOut | Yes | |
| disclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new context beyond the annotations: no wallet, no key, no transaction, and the pre-slippage nature of the quote.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with the recommended-first-call guidance and the quote semantics, with the follow-up action last. No filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need no explanation. For a one-parameter read-only quote tool, the description covers purpose, precondition (no wallet/key), caveat (pre-slippage) and next step, leaving nothing an agent needs missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a single fully documented `hype` parameter (format and max), so the schema carries the load. The description only echoes the parameter by reference ("same hype amount") and adds no format or semantics beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (quote) and resource ($AI bought per HYPE), including the pre-slippage qualifier that pins down what the number means. It is clearly distinguishable from ai_quote_sell and ai_build_buy_tx.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly positions itself as the recommended first call for a new agent and names the follow-up action, ai_build_buy_tx with the same hype amount. Both when-to-use and the alternative are spelled out rather than inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Quote how much HYPE a given amount of $AI returns right now, net of the on-chain sell fee. Use it to preview a sell; it returns no transaction. To get the calldata, call ai_build_sell_tx with the same ai amount.
| Name | Required | Description | Default |
|---|---|---|---|
| ai | Yes | $AI amount as a decimal string, e.g. "1000" (max 1000000000) |
| Name | Required | Description |
|---|---|---|
| hypeOut | Yes | |
| disclosure | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive; the description adds the key behavioral facts that the quote is 'net of the on-chain sell fee', reflects the current market ('right now'), and returns no transaction. This goes beyond the structured hints and prevents confusion with the transaction builder.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first states the core behavior and fee treatment, the second gives usage and the sibling alternative. The most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one well-documented parameter, a rich output schema, and annotations covering safety, the description covers selection, invocation, and the distinction from the tx builder. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema fully documents the single `ai` parameter, including type and maximum, so the description does not need to repeat it. It adds the useful cross-reference that the same `ai` amount is used for `ai_build_sell_tx`, but otherwise relies on the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific operation ('Quote how much HYPE ... returns right now') and a specific resource (a sell of $AI). It explicitly contrasts with ai_build_sell_tx by stating it 'returns no transaction', so an agent can distinguish it from the tx-building sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says 'Use it to preview a sell' and directs the agent to 'call ai_build_sell_tx with the same ai amount' when calldata is needed. This gives both a positive use case and an alternative, with no ambiguity about when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ai_build_buy_tx1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "disclosure": {
+ "type": "string"
+ },
+ "quote": {
+ "properties": {
+ "minTokensOut": {
+ "type": "string"
+ },
+ "slippageBps": {
+ "type": "integer"
+ },
+ "tokensOut": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tokensOut",
+ "minTokensOut",
+ "slippageBps"
+ ],
+ "type": "object"
+ },
+ "tx": {
+ "properties": {
+ "chainId": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "from": {
+ "type": "string"
+ },
+ "gas": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "chainId",
+ "to",
+ "value",
+ "data"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "tx",
+ "quote",
+ "disclosure"
+ ],
+ "type": "object"
+}ai_build_sell_tx1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "disclosure": {
+ "type": "string"
+ },
+ "quote": {
+ "properties": {
+ "hypeOut": {
+ "type": "string"
+ },
+ "minHypeOut": {
+ "type": "string"
+ },
+ "slippageBps": {
+ "type": "integer"
+ }
+ },
+ "required": [
+ "hypeOut",
+ "minHypeOut",
+ "slippageBps"
+ ],
+ "type": "object"
+ },
+ "steps": {
+ "items": {
+ "properties": {
+ "note": {
+ "type": "string"
+ },
+ "step": {
+ "enum": [
+ "approve",
+ "sell"
+ ],
+ "type": "string"
+ },
+ "tx": {
+ "properties": {
+ "chainId": {
+ "type": "string"
+ },
+ "data": {
+ "type": "string"
+ },
+ "from": {
+ "type": "string"
+ },
+ "gas": {
+ "type": "string"
+ },
+ "to": {
+ "type": "string"
+ },
+ "value": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "chainId",
+ "to",
+ "value",
+ "data"
+ ],
+ "type": "object"
+ }
+ },
+ "required": [
+ "step",
+ "tx"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "steps",
+ "quote",
+ "disclosure"
+ ],
+ "type": "object"
+}ai_market1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "chainId": {
+ "type": "integer"
+ },
+ "circulating": {
+ "type": "string"
+ },
+ "contracts": {
+ "properties": {
+ "curve": {
+ "type": "string"
+ },
+ "token": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "token",
+ "curve"
+ ],
+ "type": "object"
+ },
+ "disclosure": {
+ "type": "string"
+ },
+ "priceHype": {
+ "type": "string"
+ },
+ "priceHypeWei": {
+ "type": "string"
+ },
+ "reserveHype": {
+ "type": "string"
+ },
+ "retired": {
+ "type": "string"
+ },
+ "rpc": {
+ "type": "string"
+ },
+ "sellFeeBps": {
+ "type": "integer"
+ },
+ "sold": {
+ "type": "string"
+ },
+ "supply": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "chainId",
+ "rpc",
+ "contracts",
+ "priceHype",
+ "sold",
+ "supply",
+ "sellFeeBps",
+ "disclosure"
+ ],
+ "type": "object"
+}ai_quote_buy1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "disclosure": {
+ "type": "string"
+ },
+ "tokensOut": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tokensOut",
+ "disclosure"
+ ],
+ "type": "object"
+}ai_quote_sell1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "properties": {
+ "disclosure": {
+ "type": "string"
+ },
+ "hypeOut": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "hypeOut",
+ "disclosure"
+ ],
+ "type": "object"
+}ai_build_buy_txai_build_sell_txai_marketai_quote_buyai_quote_sellLaunch, buy, stake and claim on bonding-curve token markets across five chains, with your own key.
Non-custodial DeFi for AI agents: swaps, concentrated liquidity (V3/V4) zaps + ranges, 5 EVM chains
Prepare pump.fun token launches from your AI agent. You review and sign each one in your own wallet.
Non-custodial cross-chain OTC for AI agents: sealed RFQ, negotiation, HTLC atomic swaps.
Add one secure layer between your agents and this server.