Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@AgentPay Pharos What's my wallet balance?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A drop-in MCP skill that gives AI agents a real on-chain wallet on Pharos — check balances, read live prices, move tokens, pay only when conditions are met, screen for scams, and buy x402 pay-per-use APIs, all from natural language.
agentpay-pharos is a Model Context Protocol server. Point any MCP-compatible client (Claude Desktop, Cursor, …) at it and your agent gains 20 payment & safety tools backed by a live wallet on the Pharos network — no glue code required.
Full wallet control — balances, transfers, wrap/unwrap, gas estimates, and history for PHRS / WPHRS, USDC, USDT, WETH.
Conditional & batch payments — "pay 5 USDC only if WETH > $2000", or fan out a payroll run in one call.
Built-in safety net — GoPlus-powered screening of wallets, tokens, and contracts; safe_transfer refuses flagged recipients. No API key needed.
x402 native — agents autonomously pay for metered HTTP APIs over the x402 protocol.
Testnet → mainnet — develop on Atlantic, ship to Pacific by flipping one env var.
Related MCP server: waiaas
Payments & wallet
Tool | What it does |
| All token balances (PHRS, USDC, USDT, WETH, WPHRS) in one call |
| Snapshot of holdings + recent activity |
| Transfer a stablecoin or any supported token |
| Like |
| Multi-recipient payout with a per-token summary |
| Send only if a price condition holds |
| Combine several price/threshold conditions |
| Wrap/unwrap native PHRS ↔ WPHRS |
| Preview gas cost before sending |
| Recent transactions for the wallet |
Prices & network
Tool | What it does |
| Live price for a supported token |
| Pharos network status / metrics |
Safety (GoPlus)
Tool | What it does |
| Risk-screen an address |
| Detect honeypots / risky tokens |
| Screen a contract before interacting |
x402 & payment requests
Tool | What it does |
| Pay for and fetch an x402-gated HTTP resource |
| Generate a payment request others can fulfill |
| Confirm an expected payment landed |
npm install -g pharos-paygateFrom source:
git clone https://github.com/mo726278282/agentpay-pharos.git
cd agentpay-pharos && npm install && npm run buildcp .env.example .envPRIVATE_KEY=your_wallet_private_key_here # dedicated, low-value key
NETWORK=testnet # "testnet" (Atlantic) or "mainnet" (Pacific)
CHAIN_ID=688689
RPC_URL=https://atlantic.dplabs-internal.com
MAINNET_RPC_URL=https://rpc.pharos.xyz
FACILITATOR_URL=https://x402.org/facilitatorRegister with your MCP client (Claude Desktop claude_desktop_config.json):
{
"mcpServers": {
"agentpay-pharos": {
"command": "pharos-paygate",
"env": { "PRIVATE_KEY": "your_wallet_private_key_here", "NETWORK": "testnet" }
}
}
}"What's in my wallet right now?"
"Send 25 USDC to 0xabc…, but only if it isn't a flagged address."
"Pay 5 USDC to 0xdef… if WETH is above $2,000."
"Is token 0x123… safe to receive?"
"Buy access to this x402 API and fetch the data."
Screening is powered by GoPlus — malicious addresses, honeypot tokens, risky contracts — no API key required. safe_transfer refuses high-risk recipients outright. Treat these as guardrails, not guarantees.
Network | Env | Chain ID |
Atlantic (testnet) |
| 688689 |
Pacific (mainnet) |
| 1672 |
npm run dev # run from source with tsx
npm run build # compile to dist/
npm run inspector # debug tools in the MCP InspectorThis software signs and broadcasts real blockchain transactions with the key you provide. Use a dedicated wallet, start on testnet, and never commit your .env. Nothing here is financial advice — you are responsible for every transaction your agent makes.
MIT
Send tokens to multiple recipients in one call and get a per-recipient result summary
| Name | Required | Description | Default |
|---|---|---|---|
| recipients | Yes | List of recipients with address, amount, and token | |
| memo | No | Optional memo recorded in the response | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden of behavioral disclosure. It reveals that the tool provides a per-recipient result summary, going beyond the input schema. However, it does not mention any side effects, auth requirements, or rate limits.
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 a single clear sentence, front-loading the core action and outcome. No filler words or redundancy.
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?
Given no output schema, the description appropriately hints at the response format (per-recipient summary). The input schema is well-defined. However, for a batch operation, additional context about error handling or partial failures would improve completeness.
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 the schema already describes all parameters in detail. The description adds no extra semantic information about parameters beyond 'multiple recipients', which is already evident from the array type. The mention of result summary pertains to output, not input 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?
The description clearly states the tool sends tokens to multiple recipients in one call and returns per-recipient result summaries. This distinguishes it from sibling tools like send_usdc or send_token which handle single transfers.
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 implies efficiency ('in one call') but does not explicitly state when to prefer batch_send over individual sends or other multi-recipient tools like multi_condition_payment. No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a smart contract for verification status, proxy patterns, and known risk items using the GoPlus Security API
| Name | Required | Description | Default |
|---|---|---|---|
| contract_address | Yes | Smart contract address to analyze | |
| chain_id | No | Chain ID for the lookup (defaults to the chosen network, "688689" for testnet) | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It notes use of an external API but does not disclose mutability (likely read-only), rate limits, or error conditions. The agent cannot infer side effects or safety profile from the description alone.
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?
Single sentence, direct, front-loaded with the main purpose. No wasted words.
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?
No output schema is provided, and the description does not explain what the analysis returns. For a tool that checks contract safety, an agent needs to know the kind of result (e.g., boolean, risk score, list of issues) to interpret and use it effectively. Incomplete given the complexity.
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%, and the description does not add new meaning beyond what is in the attribute descriptions. Baseline 3 is appropriate since schema already handles parameter documentation.
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 clearly states the verb 'Analyze' and resource 'smart contract', specifying three analysis aspects (verification status, proxy patterns, known risk items) and the external API (GoPlus Security). This distinguishes it well from siblings like check_wallet_safety and check_token_safety.
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?
No guidance on when to use this tool vs alternatives like check_wallet_safety or check_token_safety. Description does not mention prerequisites, network selection criteria, or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze a token contract for honeypots, taxes, mint risk, and ownership risks using the GoPlus Security API
| Name | Required | Description | Default |
|---|---|---|---|
| token_address | Yes | Token contract address to analyze | |
| chain_id | No | Chain ID for the lookup (defaults to the chosen network, "688689" for testnet) | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions using an external API (GoPlus Security), which hints at potential latency or rate limits, but does not disclose other behavioral traits like side effects, auth requirements, or async behavior. The description is adequate but not detailed.
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 a single sentence that conveys the tool's purpose without redundancy. There is no wasted information, and it is front-loaded with the key action and resource.
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?
Given the lack of an output schema, the description mentions the specific risks analyzed, which provides useful context for what the agent can expect. However, it does not explain the return format or error handling. For a tool with three parameters, it is fairly complete.
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?
All three parameters are documented in the schema with descriptions (network, chain_id, token_address). The description does not add meaning beyond what the schema already provides, such as default values or format requirements. With 100% schema coverage, a baseline of 3 is appropriate.
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 clearly states the tool analyzes token contracts for specific risks (honeypots, taxes, mint risk, ownership risks) using the GoPlus Security API. The verb 'Analyze' and the resource 'token contract' are unambiguous, and it distinguishes itself from siblings like check_wallet_safety and check_contract_safety.
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?
No explicit when-to-use or when-not-to-use guidance is provided. The description only states what the tool does, leaving the agent to infer context from sibling names. There are no alternatives mentioned or exclusions, making the guidance implied at best.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen a wallet address for malicious activity, blacklists, and sanctions using the GoPlus Security API
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet address to screen for malicious activity | |
| chain_id | No | Chain ID for the lookup (defaults to the chosen network, "688689" for testnet) | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It mentions using an external API but does not disclose read-only nature, rate limits, or failure modes. For a security screening tool, more behavioral context (e.g., whether it triggers alerts or is query-only) is needed.
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?
Single sentence that is front-loaded with action and purpose. It is concise, but could be slightly more structured with separate lines for key details. However, it avoids unnecessary words.
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?
Given no output schema and no annotations, the description is insufficient. It does not mention what the response contains (e.g., risk factors, blacklist status) or that it uses an external API. A complete description for a tool with 3 parameters should provide more context on behavior and output.
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 parameters are described in the schema. The description adds no extra semantics beyond what the schema already provides, e.g., it does not explain default behavior for network or chain_id. Baseline 3 is appropriate.
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?
Description clearly states the tool screens wallet addresses for malicious activity, blacklists, and sanctions using GoPlus Security API. It uses specific verb 'Screen' and resource 'wallet address', effectively distinguishing it from sibling tools like check_token_safety or check_contract_safety.
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 implies use for wallet security checks but does not explicitly state when to use this tool over alternatives like check_token_safety or check_contract_safety. No guidance on prerequisites or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a payment only if a token price condition is met, e.g. send 5 USDC if WETH price > 2000
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient wallet address | |
| amount | Yes | Amount to send in human readable units, e.g. "5.00" | |
| token | Yes | Token to send if the condition is met | |
| condition_token | Yes | Token whose USD price drives the condition | |
| condition_operator | Yes | Comparison operator: gt, lt, gte, or lte | |
| condition_value | Yes | USD price threshold to compare against, e.g. "2000" | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries full burden. It lacks details on what happens when the condition is not met, return values, error states, or security implications. The example illustrates normal operation but hides failure modes.
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?
A single sentence with an example conveys the core functionality without any fluff. Every word is necessary.
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 tool with no output schema and no annotations, the description omits critical context: what happens if the condition is false, any side effects, and expected outcomes. It is not complete enough for safe autonomous use.
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 has 100% parameter descriptions, giving a baseline of 3. The description adds value with a concrete example that ties parameters together, enhancing understanding of how to form the condition.
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 clearly states the tool sends a payment only if a token price condition is met, with a concrete example. This distinguishes it from unconditional payments like send_token and multi-condition payments like multi_condition_payment.
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 implies conditional use but does not explicitly state when to use this tool versus alternatives (e.g., send_token for unconditional, multi_condition_payment for multiple conditions). No when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a structured payment request payable to this wallet, with an expiry and a human readable payment URI
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount requested in human readable units, e.g. "5.00" | |
| token | Yes | Token the payment should be made in | |
| memo | No | Optional memo describing what the payment is for | |
| expires_in_minutes | No | Minutes until the request expires (default 60) | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Mentions expiry and URI but lacks details on side effects (e.g., does it modify state?), permissions required, or cost. Behavioral disclosure is minimal.
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?
Single sentence, concise and no redundancy. However, could benefit from structured bullet points to improve scanability for an AI agent.
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 5 parameters, no output schema, and no annotations, description covers purpose but lacks behavioral context (e.g., return value, error conditions). Adequate but incomplete for a complex mutation tool.
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 descriptions for all 5 parameters. Description adds context like 'payable to this wallet' and 'expiry' but does not significantly enhance meaning beyond schema. Baseline 3 is appropriate.
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?
Description clearly states verb 'generate', resource 'payment request payable to this wallet', and specific features (expiry, human-readable URI). This distinguishes it from siblings like send_usdc (direct token send) and verify_payment_received (checking status).
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?
Description implies creation of a request but does not explicitly state when to use vs alternatives (e.g., direct sends, conditional payments). No guidance on prerequisites or limitations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate the gas cost of a token transfer in PHRS and USD
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient wallet address | |
| token | Yes | Token being transferred (PHRS for a native transfer) | |
| amount | Yes | Human readable amount, e.g. "5.00" | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It doesn't disclose whether the tool simulates a transaction, requires authentication, or is read-only. Behavioral traits beyond estimation are absent.
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?
Single sentence with no extraneous information. Every word serves the purpose. Front-loaded with key action and outputs.
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?
Lacks output schema or description of return format (e.g., gas units, token amounts). Adequate for a simple estimation, but could be more complete given no annotations.
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 descriptions for all parameters. The description adds no extra meaning beyond what the schema provides, so baseline of 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?
The description clearly states the tool estimates gas cost for a token transfer in both PHRS and USD. It distinguishes from siblings like send_usdc or get_transaction_history by focusing on cost estimation.
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?
Usage is implied (before a transfer to estimate cost), but no explicit guidance on when to use versus alternatives or when not to use. No exclusion criteria or alternative tools mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get live Pharos Atlantic Testnet stats: block number, gas price, and latest block details
| Name | Required | Description | Default |
|---|---|---|---|
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must cover behavioral traits. It correctly indicates a read-only operation returning live stats, but omits details like response format, rate limits, or permissions. The listed fields (block number, gas price, latest block details) partially compensate.
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?
A single, front-loaded sentence that communicates the core purpose without any extraneous words. Ideal conciseness.
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 low-complexity tool with one optional parameter and no output schema, the description covers the essential information. It could explicitly mention the default network (testnet) but is otherwise sufficient.
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% for the single parameter ('network' with enum and description). The description adds no additional semantic value beyond the schema, so baseline score of 3 is appropriate.
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 clearly states the verb 'Get' and resource 'network stats', listing specific fields (block number, gas price, latest block details). However, it inaccurately implies only testnet while the schema supports both testnet and mainnet, causing slight ambiguity.
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?
No explicit when-to-use or alternatives are provided, but the tool's simplicity makes implicit usage clear. It stands distinct from sibling tools which handle wallets, tokens, and transactions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the live USD price of PHRS, USDC, USDT, or WETH from CoinGecko
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token symbol to price | |
| currency | No | Quote currency (only USD supported) | USD |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. States it fetches live price from an external source (CoinGecko). Does not disclose potential rate limits, latency, or that it's read-only, but adequate for basic understanding.
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?
Single sentence, no extraneous words. Front-loaded with key action and source.
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?
No output schema. Description does not specify return format (e.g., number, object, error cases). Adequate for a simple price tool but leaves agent guessing about response structure.
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 clear enum descriptions for token, network, and currency. Description adds only the phrase 'live USD price' which is already implied. No extra semantics beyond 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?
Clearly states it gets live USD price of specified tokens (PHRS, USDC, USDT, WETH) from CoinGecko. Distinct from sibling tools which are balance, send, transaction, and safety checks.
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 describes when to use (to get live USD price). No exclusions or alternatives needed given sibling context; simple price lookup is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get recent transactions for an address from the Pharos Atlantic explorer
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet address to fetch history for | |
| limit | No | Number of transactions to return (default 10, max 50) | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description lacks behavioral details such as rate limits, authentication requirements, or how 'recent' is defined. Minimal transparency.
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?
Single sentence, no redundant information. Efficient and well-structured.
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?
Missing details on output format, error behavior, and usage context. For a tool with three parameters and no output schema, description is insufficient.
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 has 100% coverage with descriptions for all three parameters. Description adds no additional meaning beyond 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?
Description clearly states verb 'Get', resource 'transactions for an address', and source 'Pharos Atlantic explorer'. Distinguishes from sibling tools like get_wallet_balances.
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?
No guidance on when to use this tool versus alternatives. Does not mention any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get PHRS (native), USDC, USDT, WETH, and WPHRS balances for any wallet on Pharos Atlantic Testnet
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | The wallet address to check balances for | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must bear full burden. Only states it gets balances; does not disclose side effects, authentication, rate limits, or caching behavior.
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?
Single sentence, 16 words, front-loaded with action and key details. No unnecessary words.
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?
No output schema and description does not explain return value format. Missing info on response structure and network parameter scope (description mentions only testnet).
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%, baseline is 3. Description lists tokens but adds no parameter-specific meaning beyond what schema provides.
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?
Description clearly states it retrieves balances for specific tokens on Pharos network. However, it mentions only testnet while the schema includes mainnet, causing minor inconsistency.
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?
No guidance on when to use this tool versus alternatives like get_token_price. Lacks explicit when-to-use or when-not-to-use context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Build a full wallet intelligence report: balances with USD values, transaction count, wallet age estimate, and GoPlus safety status
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes | Wallet address to build a profile for | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description clearly states the tool is read-only and details the returned data (balances, transaction count, age, safety), providing full behavioral context.
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?
Single sentence with a colon-separated list of outputs; no wasted words.
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?
Despite no output schema, the description enumerates all major output components (balances, transaction count, age, safety), making the tool's behavior clear.
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 covers 100% of parameters with clear descriptions. The tool description adds no new parameter information, so 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?
The description specifies a comprehensive report combining balances with USD values, transaction count, wallet age, and safety status, differentiating it from sibling tools like get_wallet_balances or check_wallet_safety.
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 implies this tool is for a full intelligence report, but does not explicitly state when to use alternatives like get_wallet_balances or check_wallet_safety.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a payment only if multiple token price conditions pass, combined with AND or OR logic
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient wallet address | |
| amount | Yes | Amount to send in human readable units, e.g. "5.00" | |
| token | Yes | Token to send if conditions pass | |
| conditions | Yes | List of price conditions to evaluate | |
| logic | No | AND requires every condition to pass, OR requires at least one | AND |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description fully responsible for behavioral context. It states the conditional nature but does not disclose outcomes when conditions fail (e.g., no transaction sent, any fees incurred), permissions required, or side effects like state changes.
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?
Single sentence that is direct and informative. No extraneous words. Front-loads the key action and condition constraint.
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 tool with 6 parameters and no output schema, the description is minimal. It does not explain return values, error handling, or the fate of the payment if conditions fail. Adequate but could be more complete.
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 parameters are well-documented. The tool description adds no new parameter-level meaning beyond restating the logic combination already in the schema. Baseline score of 3 is appropriate.
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?
Description clearly states 'Send a payment only if multiple token price conditions pass, combined with AND or OR logic.' It specifies a concrete verb and resource, distinguishes from simpler conditional payment tools by emphasizing multiple conditions and logic combination.
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?
Description implies usage for multi-condition payments but lacks explicit guidance on when to choose this over alternatives like 'conditional_payment' or 'send_token'. No 'when not to use' or prerequisite conditions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Screen the recipient with GoPlus first, then send the token only if the recipient is not high risk
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient wallet address | |
| amount | Yes | Amount in human readable units, e.g. "5.00" | |
| token | Yes | Token to send | |
| skip_safety_check | No | Set true to send even if the recipient is flagged as risky | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the screening step and conditional sending, but does not detail what happens if screening fails, what errors occur, or any prerequisites like token approvals or gas fees. The behavior is partially transparent but lacks depth.
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 a single sentence that is front-loaded with the primary action. Every word contributes to the understanding of the tool's purpose, with no wasted space. Highly concise and efficient.
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 5 parameters, no output schema, and no annotations, the description should cover more details. It explains the main logic but omits what the tool returns (e.g., transaction hash, error messages) and any prerequisites (e.g., wallet must have sufficient balance and possibly token approval). The description is adequate for a simple tool but incomplete for robust usage.
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 workflow context (screening then sending) but does not enhance parameter-level meaning beyond what the schema provides. Baseline of 3 is appropriate.
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 clearly states a two-step workflow: screening the recipient with GoPlus, then sending the token only if safe. This distinguishes it from siblings like check_wallet_safety (screening only) and send_token (sending only), and specifies the resource (safe transfer) and action (screen then send).
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 implies using this tool when you want both screening and sending in one step, but does not explicitly state when to use alternatives like chaining check_wallet_safety with send_token, or when skipping safety checks is appropriate. The skip_safety_check parameter hints at a fallback but no explicit guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send any supported token (USDC, USDT, WETH, WPHRS) to an address on Pharos Atlantic Testnet
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token to send | |
| to | Yes | Recipient wallet address | |
| amount | Yes | Amount in human readable units, e.g. "5.00" for 5 USDC | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must convey behavioral traits. It only states the action without detailing side effects (e.g., gas costs, transaction fees), required permissions, or what happens on success/failure. The network scope contradiction further undermines transparency.
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 a single sentence, which is concise and front-loaded. However, it omits critical details such as network scope clarification and return value, making it efficient but incomplete.
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?
Given the lack of output schema and annotations, the description should cover return values (e.g., transaction hash), prerequisites, and network constraints. It fails to do so, leaving significant gaps for a tool with 4 parameters and multiple sibling tools.
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 baseline is 3. The description does not add extra information beyond the schema's parameter descriptions. The example for 'amount' is already present in the schema, so no additional value is provided from the description.
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 clearly specifies the action ('Send') and resource ('any supported token'), listing specific token types. However, it limits the network to 'Pharos Atlantic Testnet' while the schema includes both testnet and mainnet options, creating a contradiction that slightly reduces clarity. It does not distinguish from the sibling tool 'send_usdc', which appears to be a more specific alternative.
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?
There is no guidance on when to use this tool versus alternatives like 'send_usdc', 'batch_send', or 'conditional_payment'. The description does not specify prerequisites, such as having a sufficient balance or being connected to a wallet, nor does it indicate when the tool is not appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send USDC to an address on Pharos Atlantic Testnet, with an optional memo
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Recipient wallet address | |
| amount | Yes | Amount of USDC in human readable units, e.g. "5.00" | |
| memo | No | Optional memo recorded in the response | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behaviors. It fails to mention that sending is irreversible, requires sufficient balance, incurs fees, or returns a transaction hash. For a financial mutation, this is insufficient.
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 a single sentence that conveys the essential action, target, and optionality. No fluff or redundancy. Perfectly concise.
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 critical financial tool with no output schema and no annotations, the description is too brief. It doesn't mention transaction outcomes, reversibility, or network distinctions, leaving the agent underinformed for safe 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 coverage is 100%, with clear parameter descriptions. The description adds little beyond noting the optional memo. Since schema already covers 'human readable units' and network options, the description does not significantly enhance understanding.
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 clearly states it sends USDC to an address on Pharos Atlantic Testnet, with an optional memo. It distinguishes from generic 'send_token' but only mentions testnet, while the schema includes a network parameter for mainnet. This omission slightly reduces clarity.
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?
No guidance on when to use this tool vs. siblings like 'send_token' (generic), 'batch_send' (multiple), or 'conditional_payment'. The description does not specify prerequisites or contexts where this tool is preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unwrap WPHRS back into native PHRS (WETH-style withdraw)
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount of wrapped native token (WPHRS/WPROS) to unwrap, e.g. "1.5" | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It minimally describes the operation as a withdrawal-like process, but does not disclose potential fees, approval requirements, confirmations, or reversibility. More behavioral context is needed for a financial tool.
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 a single, concise sentence that front-loads the core purpose and includes a clarifying analogy. No extraneous information.
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 is simple (2 parameters, no output schema), and the description captures the main action. However, it misses a cross-reference to the sibling 'wrap_phrs' tool and does not explain the 'network' parameter. It is adequate but not thorough.
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 the schema provides full parameter definitions. The description adds an example for the 'amount' parameter but does not mention the 'network' parameter, leaving it to the schema. This aligns with the baseline where schema does the heavy lifting.
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 clearly states the action (unwrap) and the resources (WPHRS to native PHRS), and distinguishes from the sibling tool 'wrap_phrs' by mentioning the reversal nature and the WETH-style analogy.
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 implies the tool is used to convert wrapped tokens back to native, but does not explicitly state when to use it or provide guidance on prerequisites or alternatives. It assumes the user knows the context from the tool name and sibling relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check recent transactions for a matching incoming payment of an expected amount and token
| Name | Required | Description | Default |
|---|---|---|---|
| expected_from | No | Optional sender address the payment must come from | |
| expected_amount | Yes | Expected amount in human readable units, e.g. "5.00" | |
| token | Yes | Token the payment should arrive in | |
| wallet_address | Yes | The receiving wallet address to check | |
| since_minutes_ago | No | How far back to look for the payment (default 30 minutes) | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It describes a 'check' operation but does not disclose whether the tool is read-only, what side effects exist, or any behavioral traits like rate limits or idempotency.
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?
Single sentence with 12 words. No redundancy, perfectly front-loaded with action and object.
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?
No output schema, so description should explain return value but does not. Lacks details on matching logic (exact vs fuzzy), verification result type (boolean vs details), and how parameters beyond amount/token affect behavior.
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. Description adds minimal value beyond schema, only tying 'expected amount and token' to parameters. No additional parameter-level explanation.
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?
Description clearly states the verb 'Check' and the resource 'recent transactions for a matching incoming payment of an expected amount and token'. It distinguishes itself from sibling tools like get_transaction_history (which lists all transactions) by specifying verification of a specific incoming payment.
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?
No explicit guidance on when to use this tool versus alternatives. It does not mention when not to use it, nor does it reference siblings like get_transaction_history or create_payment_request.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wrap native PHRS into WPHRS (WETH-style deposit)
| Name | Required | Description | Default |
|---|---|---|---|
| amount | Yes | Amount of native gas token (PHRS/PROS) to wrap, e.g. "1.5" | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic operation, omitting details like whether wrapping is reversible, required permissions, gas costs, or what happens on chain. This is insufficient for a mutation tool.
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 a single, clear sentence with no unnecessary words. It is front-loaded with the essential action and result.
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 simple, two-parameter tool with no output schema and no annotations, the description is adequate but lacks completeness in areas like usage guidelines and behavioral transparency. It covers the core function but leaves gaps.
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 the two parameters. The tool description does not add any extra meaning beyond what's in the schema. Baseline score of 3 is appropriate.
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 clearly states the action (wrap), the input (native PHRS), and the output (WPHRS), using the analogy 'WETH-style deposit' which is immediately understandable. It distinguishes from sibling tools like unwrap_phrs.
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 does not provide any guidance on when to use this tool versus alternatives (e.g., no mention of prerequisites, no comparison with other wrapping or deposit tools). It's a minimal viable description but lacks context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch an x402-protected URL, automatically paying for it with USDC if the price is within max_price
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | URL of the x402-protected resource | |
| max_price | Yes | Maximum USDC you are willing to pay, e.g. "0.01" | |
| network | No | Network to use: testnet (default) or mainnet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the main behavior but lacks details on failure modes (e.g., what if price exceeds max_price?), network errors, or whether the operation is destructive (deducts USDC). The description does not disclose error handling or side effects beyond payment.
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?
Single sentence, front-loaded with the action verb 'Fetch'. No wasted words; each part clarifies the tool's core function.
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?
Given three parameters and no output schema or annotations, the description is somewhat complete for a simple fetch-and-pay tool. However, it lacks return value specification, error behavior, and clarification on what happens when price exceeds max_price, which is critical for a payment operation.
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 the schema already documents all parameters. The description adds context ('automatically paying for it with USDC') but does not provide additional semantics beyond what the schema offers. 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?
The description clearly states the tool fetches an x402-protected URL and automatically pays with USDC if the price is within max_price. It uses specific verbs ('fetch', 'pay') and identifies the resource, distinguishing it from sibling tools like send_usdc (which only sends USDC) or conditional_payment.
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 implies usage when accessing x402-protected resources, but does not explicitly state when to use versus alternatives, nor does it provide when-not-to-use guidance or mention prerequisites. Sibling tools exist for payments, but no comparative context is given.
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.
v0.1.3batch_sendcheck_contract_safetycheck_token_safetycheck_wallet_safetyconditional_paymentcreate_payment_requestestimate_gasget_network_statsget_token_priceget_transaction_historyget_wallet_balancesget_wallet_profilemulti_condition_paymentsafe_transfersend_tokensend_usdcunwrap_phrsverify_payment_receivedwrap_phrsx402_pay_for_resourceScored across 20 tools
Most tools have clearly distinct purposes, but there is some overlap among sending variants (send_token, safe_transfer, conditional_payment, etc.), which could cause misselection if descriptions are not carefully read.
All tools use snake_case with a verb_noun pattern, which is consistent. A few names like 'x402_pay_for_resource' break the pattern slightly, but overall it's predictable.
20 tools is on the higher end but still reasonable for a comprehensive payment and DeFi server. Each tool serves a specific function, and the count is justified by the scope.
The tool set covers all major workflows: sending (multiple variants), receiving verification, wrapping/unwrapping, safety checks, balances, network stats, and pricing. No obvious gaps for the declared testnet domain.
Policy-gated MCP treasury for AI agents — x402 subscribe, 50+ tools, multi-chain.
Wallet and payments for AI agents: auto-pay x402 APIs in USDC on XDC, within on-chain limits.
Give your AI agent an x402 wallet: discover and pay for services in USDC, or earn from your own.
Multi-chain wallet MCP. 18 tools: balance, swap, bridge, stake, claim. Pay-per-call USDC (x402 v2).