Click on "Install 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., "@pharos-paygate Check my wallet balance for USDC and ETH"
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.
Here are four things you can say to an AI agent with pharos-paygate connected:
"Check the balance of 0x1234..." - triggers get_wallet_balances, returns PHRS, USDC, USDT, WETH and WPHRS in one call "Send 5 USDC to 0x1234... if WETH is above 2000" - triggers conditional_payment, fetches live price, pays only if condition is met "Is 0x1234... safe to send money to?" - triggers check_wallet_safety, screens the address against GoPlus malicious address database "Fetch https://api.example.com/data and pay for it if it costs under 0.01 USDC" - triggers x402_pay_for_resource, handles the full 402 payment handshake autonomously
pharos-paygate is an MCP (Model Context Protocol) server that gives AI agents a complete payments and security toolkit on Pharos, across both the Atlantic Testnet and the Pacific Mainnet. It exposes 20 tools covering everything an agent needs to move money safely: checking balances, fetching prices, sending USDC or any supported token, conditional and multi-condition payments, batch payouts, transaction history, gas estimation, paying for x402-protected web resources, GoPlus-powered wallet and contract screening, safety-gated transfers, payment requests and verification, native token wrapping, wallet intelligence profiles, and live network stats. Every tool takes an optional network parameter so an agent can work on testnet by default and switch to mainnet just by saying "on mainnet". Install it once in Claude Desktop, Cursor, or any MCP-compatible client and your agent can transact on Pharos with plain English.
Related MCP server: HTTPayer MCP
These transactions were executed live on Pharos Atlantic Testnet during development:
USDC send: https://atlantic.pharosscan.xyz/tx/0x9d988fe11f13a560849ad0a331c9f3e5d7a5d834bf5169738c9990eb16b341db Conditional payment (WETH above 1000 USD): https://atlantic.pharosscan.xyz/tx/0xa3de353b01372f88ef94c71225e72bdb82cb7c1b37c6871ef69ebb13f6c0f742 Safe transfer with GoPlus screening: https://atlantic.pharosscan.xyz/tx/0x312d2382f85505f1e95becc882cdd1ad13e986cc51f5f0318accf1ef3863facd Multi-condition payment (WETH above 1000 USD AND USDC above 0.99): https://atlantic.pharosscan.xyz/tx/0x6dbe8241552b291a8e6ba80d28f6d08594467743350866ddee4fd59e55017fcb
AI agents are getting good at deciding when to pay for things, but they have no hands. They cannot hold a wallet, sign a transaction, or respond to an HTTP 402 Payment Required. Every team building agent commerce ends up rebuilding the same plumbing: RPC clients, decimal conversion, gas math, explorer lookups, payment protocol handshakes.
pharos-paygate packages all of that plumbing as a single MCP skill. The agent says "send 5 USDC to 0xabc..." and the skill handles address validation, decimal conversion, signing, broadcasting, waiting for the receipt, and handing back an explorer link. It also speaks x402, so an agent can buy access to paid APIs autonomously while staying inside a spending cap you set.
Fetches PHRS (native), USDC, USDT, WETH, and WPHRS balances for any wallet in a single multicall.
Input: address (string)
Output: array of {symbol, balance, raw} for all 5 tokens
"What's the balance of 0x1234...abcd on Pharos?"
Fetches a live USD price from the CoinGecko public API (no API key needed). PHRS is not listed on CoinGecko, so it returns a $0.10 estimate with a note saying so.
Input: token (PHRS | USDC | USDT | WETH), currency (USD, default USD)
Output: {token, price, currency, source, timestamp}
"What's the current price of WETH?"
Sends USDC to an address. Amounts are human readable, so "5.00" means 5 USDC.
Input: to (address), amount (string, e.g. "5.00"), memo (optional string)
Output: {txHash, explorer, status} with a link like https://atlantic.pharosscan.xyz/tx/0x...
"Send 5 USDC to 0x1234...abcd with the memo 'invoice 42'"
Generic transfer for any supported token. Decimals are handled per token (6 for USDC/USDT, 18 for WETH/WPHRS).
Input: token (USDC | USDT | WETH | WPHRS), to (address), amount (string)
Output: {txHash, explorer, status}
"Transfer 0.01 WETH to 0x1234...abcd"
Fetches the live price of a condition token, evaluates a comparison, and only sends the payment if the condition holds. If not, it tells you the current price versus the threshold and skips the payment.
Input: to, amount, token, condition_token (PHRS | USDC | USDT | WETH), condition_operator (gt | lt | gte | lte), condition_value (string)
Output: executed payment with tx hash, or a skip explanation with the current price
"Send 5 USDC to 0x1234...abcd if WETH price is above 2000"
Sends tokens to multiple recipients in sequence. One failed transfer does not stop the rest. Returns per-recipient results and a summary with success/fail counts and totals per token.
Input: recipients (array of {address, amount, token}), memo (optional)
Output: {results, summary: {total, successCount, failCount, totalSentByToken}}
"Pay 2 USDC each to these three addresses: 0xaaa..., 0xbbb..., 0xccc..."
Fetches recent transactions for an address from the PharosScan explorer API.
Input: address (string), limit (number, default 10, max 50)
Output: array of {hash, from, to, value, token, timestamp, status}
"Show me the last 10 transactions for my wallet"
Estimates the gas cost of a transfer before sending it.
Input: to (address), token (USDC | USDT | WETH | WPHRS | PHRS), amount (string)
Output: {estimatedGasUnits, gasPriceGwei, totalCostPhrs, totalCostUsd}
"How much gas would it cost to send 10 USDT to 0x1234...abcd?"
Implements the x402 HTTP 402 payment protocol. Makes the initial request, parses the payment requirements from the 402 response, and if the price is within your max_price cap it signs the payment and retries the request with the payment header. If the price exceeds the cap, it refuses and reports the actual price required. Nothing is ever signed above your cap.
Input: url (string), max_price (string, max USDC you are willing to pay, e.g. "0.01")
Output: the resource data, the price paid, and the settlement receipt
"Fetch https://api.example.com/premium-data and pay for it if it costs less than 0.05 USDC"
Screens a wallet address against the GoPlus Security database for malicious activity, blacklists, and sanctions. Free API, no key needed.
Input: address (string), chain_id (string, default "688689")
Output: {address, is_malicious, is_blacklisted, is_sanctioned, risk_level, risk_details, recommendation}
"Is 0x1234...abcd a safe address to send money to?"
Analyzes a token contract with GoPlus: honeypot detection, buy/sell taxes, mintability, and ownership risks.
Input: token_address (string), chain_id (string, default "688689")
Output: {token_address, is_honeypot, is_open_source, is_proxy, buy_tax, sell_tax, can_take_back_ownership, is_mintable, risk_level, risk_summary}
"Check if this token is a honeypot before I buy: 0xabcd..."
Analyzes a smart contract with GoPlus: verification status, proxy patterns, self destruct, and other risk items.
Input: contract_address (string), chain_id (string, default "688689")
Output: {contract_address, is_verified, is_open_source, is_proxy, risk_items, overall_risk, recommendation}
"Is the contract at 0xabcd... safe to interact with?"
The intelligent payment tool. Screens the recipient with GoPlus first, and only sends if the recipient is not flagged as high or critical risk. If the recipient is flagged, the transfer is aborted and the full safety report comes back instead. You can override with skip_safety_check if you are certain.
Input: to (address), amount (string), token (USDC | USDT | WETH | WPHRS), skip_safety_check (boolean, default false)
Output: safety check outcome plus transaction result, or an abort report
"Safely send 10 USDC to 0x1234...abcd, but check the address first"
Generates a structured payment request payable to your wallet, with a unique ID, expiry, and a human readable payment string you can hand to a counterparty.
Input: amount (string), token (USDC | USDT | WETH | WPHRS | PHRS), memo (optional), expires_in_minutes (number, default 60)
Output: {payment_request_id, payable_to, amount, token, memo, expires_at, created_at, status, payment_uri}
"Create a payment request for 25 USDC for invoice 1043, valid for 2 hours"
Checks recent incoming transactions for a payment matching an expected amount, token, and optionally a sender. Pairs with create_payment_request to close the loop on agent invoicing.
Input: expected_from (optional address), expected_amount (string), token, wallet_address (string), since_minutes_ago (number, default 30)
Output: {verified, matching_tx?: {hash, from, amount, timestamp, explorer_link}, message}
"Did I receive the 25 USDC payment from 0x1234...abcd yet?"
Wraps native PHRS into WPHRS by calling deposit() on the WETH-style wrapper contract.
Input: amount (string, human readable PHRS)
Output: {tx_hash, explorer_link, amount_wrapped, wphrs_received}
"Wrap 2 PHRS into WPHRS"
Unwraps WPHRS back to native PHRS by calling withdraw() on the wrapper contract.
Input: amount (string, human readable WPHRS)
Output: {tx_hash, explorer_link, amount_unwrapped, phrs_received}
"Unwrap 2 WPHRS back to PHRS"
Builds a full intelligence report on any wallet: all balances with USD values, total portfolio value, transaction count, an age estimate (new, active, veteran), and a GoPlus safety status, all in one call.
Input: address (string)
Output: {address, total_portfolio_usd, balances, transaction_count, wallet_age_estimate, safety_status, risk_level}
"Give me a full profile of the wallet 0x1234...abcd"
Fetches live Pharos network stats for testnet or mainnet straight from the RPC: current block, gas price, and the latest block's transaction count and timestamp.
Input: none
Output: {network, chain_id, block_number, gas_price_gwei, last_block_tx_count, last_block_timestamp, rpc_url, explorer}
"What's the current state of the Pharos network?"
The upgraded conditional payment. Takes a list of price conditions and combines them with AND or OR logic. Reports exactly which conditions passed and which failed, with current prices, whether the payment fires or not.
Input: to, amount, token, conditions (array of {condition_token, operator, value}), logic (AND | OR, default AND)
Output: executed payment with per-condition breakdown, or a detailed skip explanation
"Send 5 USDC to 0x1234...abcd if WETH is above 1500 AND USDT is at least 0.99"
You need Node.js 18 or newer.
The quickest way to get started:
npm install -g pharos-paygateFor developers who want to contribute or inspect the source:
git clone https://github.com/Oseodion/pharos-paygate.git
cd pharos-paygate
npm install
npm run buildThen create your env file:
cp .env.example .env
# edit .env and paste your wallet private keyVerify the server starts:
npm start
# should print: pharos-paygate MCP server running on stdioFor interactive testing there is an MCP Inspector script:
npm run inspectorOpen your Claude Desktop config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
If you installed via npm (recommended for most users):
{
"mcpServers": {
"pharos-paygate": {
"command": "pharos-paygate",
"env": {
"PRIVATE_KEY": "your_wallet_private_key_here",
"NETWORK": "testnet"
}
}
}
}If you cloned the repo (for developers):
{
"mcpServers": {
"pharos-paygate": {
"command": "node",
"args": ["/absolute/path/to/pharos-paygate/dist/index.js"],
"env": {
"PRIVATE_KEY": "your_wallet_private_key_here",
"RPC_URL": "https://atlantic.dplabs-internal.com",
"MAINNET_RPC_URL": "https://rpc.pharos.xyz",
"CHAIN_ID": "688689",
"NETWORK": "testnet",
"FACILITATOR_URL": "https://x402.org/facilitator"
}
}
}
}Note: PRIVATE_KEY is only needed for tools that send transactions. Read-only tools like get_wallet_balances, get_token_price, check_wallet_safety, and get_network_stats work without it. NETWORK defaults to testnet if not set.
Restart Claude Desktop fully after editing the config (Command+Q on Mac, not just closing the window).
Create or edit ~/.cursor/mcp.json (global) or .cursor/mcp.json (per project).
If you installed via npm:
{
"mcpServers": {
"pharos-paygate": {
"command": "pharos-paygate",
"env": {
"PRIVATE_KEY": "your_wallet_private_key_here",
"NETWORK": "testnet"
}
}
}
}If you cloned the repo:
{
"mcpServers": {
"pharos-paygate": {
"command": "node",
"args": ["/absolute/path/to/pharos-paygate/dist/index.js"],
"env": {
"PRIVATE_KEY": "your_wallet_private_key_here",
"NETWORK": "testnet"
}
}
}
}Then enable the server in Cursor's MCP settings.
pharos-paygate is a standard stdio MCP server, so it works in any MCP-compatible client. The same command / args / env block shown above goes into each client's config file:
Client | Config location | Config format |
Claude Desktop |
| Same JSON block with |
Cursor |
| Same JSON block with |
Windsurf |
| Same JSON block with |
Cline (VSCode extension) | MCP servers settings inside VSCode | Same JSON block with |
Goose |
| Same JSON block with |
Zed |
| Same JSON block with |
Continue |
| Same JSON block with |
Custom agent | Any agent built on | Same JSON block with |
Variable | Required | Description |
| For sending tools | Private key of the wallet that signs transactions. Read-only tools (balances, prices, history) work without it. Never commit this. |
| No | Pharos Atlantic Testnet RPC endpoint. Defaults to https://atlantic.dplabs-internal.com |
| No | Pharos Pacific Mainnet RPC endpoint. Defaults to https://rpc.pharos.xyz |
| No | Testnet chain ID. Defaults to 688689 |
| No | Default network when a tool call does not specify one: |
| No | x402 facilitator endpoint. Defaults to https://x402.org/facilitator |
The private key is only ever read from the environment. It is never logged, never returned in tool output, and never hardcoded anywhere in the source.
Every tool accepts an optional network parameter (testnet or mainnet). When omitted, it falls back to the NETWORK env var, and then to testnet. So existing setups keep working with no changes, and an agent can switch chains per request just by saying "on mainnet".
Network | Chain ID | Currency | RPC | Explorer |
Atlantic Testnet | 688689 | PHRS | ||
Pacific Mainnet | 1672 | PROS |
Token | Address | Decimals |
USDC |
| 6 |
USDT |
| 6 |
WETH |
| 18 |
WPHRS |
| 18 |
MultiCall3 |
| - |
x402 test USDC |
| 6 |
Token | Address | Decimals |
USDC |
| 6 |
WETH |
| 18 |
WPROS |
| 18 |
LINK |
| 18 |
MultiCall3 |
| - |
Note: the token send enums (USDC, USDT, WETH, WPHRS) are shared across both networks for backward compatibility. On mainnet, USDC and WETH work directly; USDT and WPHRS are testnet-only and return a clear "not available on this network" error. Mainnet-only tokens (WPROS, LINK) show up in balances and profiles automatically.
Four of the tools (check_wallet_safety, check_token_safety, check_contract_safety, and safe_transfer) are backed by the GoPlus Security API, a free public service that maintains databases of malicious addresses, honeypot tokens, and risky contracts across chains. No API key is needed for the lookups this skill makes.
Why this matters: an AI agent moving money is a new kind of attack surface. A scammer does not need to compromise the agent, they just need to get a bad address in front of it: a poisoned payment request, a phishing address in a website the agent scraped, a honeypot token in a list of "opportunities". Humans hesitate before sending money to a stranger. An agent executes.
The screening tools give the agent the same instinct. Before any transfer, it can ask whether the recipient has been linked to phishing, theft, money laundering, or sanctions, and get a concrete recommendation back: safe_to_transact, proceed_with_caution, or do_not_transact. The safe_transfer tool bakes this in: it refuses to send to addresses flagged high or critical risk unless you explicitly override it, and it also refuses to send blind if the screening service itself is unreachable.
Two honest caveats. GoPlus coverage of the Pharos Atlantic Testnet specifically is thin, so many testnet addresses come back with no data (the tools report risk_level "unknown" in that case rather than pretending). And no blacklist is complete: a clean screening result lowers risk, it does not eliminate it. Treat the screening as a seatbelt, not a guarantee.
HTTP has had a 402 Payment Required status code reserved since the 1990s, but nobody wired it up. x402 is an open protocol that finally does: a server responds to a request with 402 and a machine-readable description of what it costs, the client signs a token payment authorization, retries the request with a payment header, and a facilitator settles it on chain. No accounts, no API keys, no credit card forms.
This matters for agent commerce because agents cannot fill out checkout pages. With x402 an agent can discover a paid API, see the price, decide whether it is worth it, pay a fraction of a cent in USDC, and get the data, all in a single tool call lasting a couple of seconds. The x402_pay_for_resource tool implements the client side of this on Pharos (network eip155:688689), with a hard spending cap so the agent can never pay more than you allowed.
Reference implementation for Pharos: https://github.com/PharosNetwork/examples/tree/main/skills/x402-pharos
pharos-paygate/
src/
index.ts MCP server entry point, registers all 20 tools
config/pharos.ts chain definition, token addresses, ABIs
utils/client.ts viem public + wallet clients, result helpers
tools/ one file per tool
SKILL.md Pharos Skill Engine format capability index
.env.example environment templateIf you see EACCES permission denied on macOS, run with sudo:
sudo npm install -g pharos-paygateOr fix npm permissions permanently so you never need sudo again:
mkdir ~/.npm-global
npm config set prefix '~/.npm-global'
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.zshrc
source ~/.zshrc
npm install -g pharos-paygateOn Windows, open PowerShell or Command Prompt as Administrator:
Press Windows key
Search for PowerShell
Right click and select Run as Administrator
Then run: npm install -g pharos-paygate
Or if you use nvm on Windows, permissions are handled automatically.
If the command is not found after installing, your PATH may not include the npm global bin folder. Run:
npm config get prefixThen add that path plus /bin to your PATH in ~/.zshrc or ~/.bashrc and restart your terminal.
Close and reopen PowerShell or Command Prompt after installing. If still not found, run:
npm config get prefixAdd that path to your System Environment Variables under PATH.
Make sure you fully quit Claude Desktop and reopen it after editing the config file. On Mac press Command+Q, on Windows right click the taskbar icon and click Quit. Just closing the window is not enough.
The PharosScan explorer API has rate limits. If get_transaction_history or verify_payment_received return a rate limit error, wait 30 seconds and try again.
Make sure your wallet has PHRS on testnet or PROS on mainnet for gas fees. Get testnet PHRS from the faucet at https://testnet.pharosnetwork.xyz. Read-only tools like get_wallet_balances, get_token_price, check_wallet_safety, and get_network_stats work without any gas.
Contributions are welcome. The codebase is small on purpose, so it is easy to find your way around.
Fork the repo and create a feature branch
Add your tool in src/tools/ following the existing pattern: export a zod schema and a handler that returns {success, data, error?}
Register it in src/index.ts with safeHandler
Make sure npm run build passes with no errors
Test it with npm run inspector
Open a pull request with a short description of what the tool does and why
Bug reports and ideas for new payment primitives are just as useful as code.
MIT
Send tokens to multiple recipients in one call and get a per-recipient result summary
| Name | Required | Description | Default |
|---|---|---|---|
| memo | No | Optional memo recorded in the response | |
| network | No | Network to use: testnet (default) or mainnet | |
| recipients | Yes | List of recipients with address, amount, and token |
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 |
|---|---|---|---|
| network | No | Network to use: testnet (default) or mainnet | |
| chain_id | No | Chain ID for the lookup (defaults to the chosen network, "688689" for testnet) | |
| contract_address | Yes | Smart contract address to analyze |
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 |
|---|---|---|---|
| network | No | Network to use: testnet (default) or mainnet | |
| chain_id | No | Chain ID for the lookup (defaults to the chosen network, "688689" for testnet) | |
| token_address | Yes | Token contract address to analyze |
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 | |
| network | No | Network to use: testnet (default) or mainnet | |
| chain_id | No | Chain ID for the lookup (defaults to the chosen network, "688689" for testnet) |
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 | |
| token | Yes | Token to send if the condition is met | |
| amount | Yes | Amount to send in human readable units, e.g. "5.00" | |
| network | No | Network to use: testnet (default) or mainnet | |
| condition_token | Yes | Token whose USD price drives the condition | |
| condition_value | Yes | USD price threshold to compare against, e.g. "2000" | |
| condition_operator | Yes | Comparison operator: gt, lt, gte, or lte |
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 |
|---|---|---|---|
| memo | No | Optional memo describing what the payment is for | |
| token | Yes | Token the payment should be made in | |
| amount | Yes | Amount requested in human readable units, e.g. "5.00" | |
| network | No | Network to use: testnet (default) or mainnet | |
| expires_in_minutes | No | Minutes until the request expires (default 60) |
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 | |
| network | No | Network to use: testnet (default) or mainnet | |
| currency | No | Quote currency (only USD supported) | USD |
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 |
|---|---|---|---|
| limit | No | Number of transactions to return (default 10, max 50) | |
| address | Yes | Wallet address to fetch history 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, 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 | |
| logic | No | AND requires every condition to pass, OR requires at least one | AND |
| token | Yes | Token to send if conditions pass | |
| amount | Yes | Amount to send in human readable units, e.g. "5.00" | |
| network | No | Network to use: testnet (default) or mainnet | |
| conditions | Yes | List of price conditions to evaluate |
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 | |
| token | Yes | Token to send | |
| amount | Yes | Amount in human readable units, e.g. "5.00" | |
| network | No | Network to use: testnet (default) or mainnet | |
| skip_safety_check | No | Set true to send even if the recipient is flagged as risky |
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 |
|---|---|---|---|
| to | Yes | Recipient wallet address | |
| token | Yes | Token to send | |
| 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 | |
| memo | No | Optional memo recorded in the response | |
| amount | Yes | Amount of USDC in human readable units, 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 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 |
|---|---|---|---|
| token | Yes | Token the payment should arrive in | |
| network | No | Network to use: testnet (default) or mainnet | |
| expected_from | No | Optional sender address the payment must come from | |
| wallet_address | Yes | The receiving wallet address to check | |
| expected_amount | Yes | Expected amount in human readable units, e.g. "5.00" | |
| since_minutes_ago | No | How far back to look for the payment (default 30 minutes) |
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 | |
| network | No | Network to use: testnet (default) or mainnet | |
| max_price | Yes | Maximum USDC you are willing to pay, e.g. "0.01" |
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. Dates show when Glama detected each change.
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_resourceSeveral tools have overlapping purposes, especially around sending tokens: send_usdc is redundant with send_token (which also sends USDC), and conditional_payment, batch_send, safe_transfer, and multi_condition_payment all perform send-like operations with different modifiers. While descriptions help differentiate them, an agent may still struggle to select the correct one.
Most tool names follow a consistent verb_noun pattern in snake_case (e.g., get_wallet_balances, check_token_safety). However, a few names like safe_transfer (verb missing), conditional_payment (noun first), and x402_pay_for_resource (unusual prefix) deviate slightly from the pattern.
With 20 tools, the server covers a broad range of payment-related operations. While this is on the higher end of the ideal range, each tool serves a distinct purpose in the domain of wallet management, token transfers, safety checks, and network queries. The count feels slightly heavy but not excessive.
The tool set covers most essential operations: balance checks, price queries, token sending (with variants), safety screening, gas estimation, payment requests, transaction history, and wrapping. Minor gaps exist, such as the lack of a tool to list supported tokens or cancel payment requests, but agents can typically work around these.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
AI agent gateway with web fetching, data extraction, crypto pricing, and x402 payments
Wallet and payments for AI agents: auto-pay x402 APIs in USDC on XDC, within on-chain limits.
Pay-per-call DeFi intelligence API for AI agents on Base blockchain with x402 micropayments
Pay-per-call tools for autonomous agents, settled in USDC on Base via x402.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Oseodion/pharos-paygate'
If you have feedback or need assistance with the MCP directory API, please join our Discord server