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., "@Basis MCP Server What are my balances?"
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.
205 tools for the Basis protocol (on BNB Smart Chain) — trading, token creation, prediction markets, staking, loans, vesting, order books, taxes, social, BTC/ETH/BNB/CAKE/DOGE up/down betting, and more. Works with Claude Desktop, Claude Code, and any MCP-compatible client.
The SDK is bundled inside — no separate installation required.
Node.js v18 or higher
Claude Desktop (or any MCP-compatible client)
A BNB Smart Chain wallet private key
Related MCP server: Base MCP Server
git clone https://github.com/Launch-On-Basis/MCP-TS.git
cd MCP-TS
npm install
npm run buildYou need a BNB Smart Chain (BSC) wallet private key. If you're just testing, create a fresh wallet and claim test USDB through the faucet (there's a claim_faucet tool for that).
Open your Claude Desktop config:
Mac: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
Add this inside the "mcpServers" object (create it if it doesn't exist):
{
"mcpServers": {
"basis": {
"command": "node",
"args": ["/full/path/to/MCP-TS/dist/index.js"],
"env": {
"BASIS_PRIVATE_KEY": "0xYOUR_PRIVATE_KEY_HERE"
}
}
}
}Restart Claude Desktop. You should see "basis" appear under Connectors in the sidebar. If it shows as connected, you're good to go.
Open a new chat and ask:
"What are my balances?"
"What's the price of STASIS?"
"Show me active prediction markets"
"Create a token called DEMO with Floor+ mechanics"
Variable | Required | Description |
| Yes | BNB Smart Chain wallet private key (0x-prefixed) |
| No | Basis API key (starts with |
Tool | Type | Description |
| write | Buy a token with USDB. Previews before executing. |
| write | Sell a token for USDB. Checks balance first. |
| read | Get current USD price of a token. |
| read | Get raw token price (reserve ratio). |
| read | Preview buy/sell without executing. |
| write | Open leveraged position. Simulates first, requires confirmation. |
| write | Close/partially close a leverage position. |
| read | List all leverage positions. |
Tool | Type | Description |
| write | Create a new token. Earn 20% of all trades forever. Accepts image URL or local file. |
| write | Open frozen token to public trading. Irreversible. |
| write | Add wallets to frozen token's whitelist. |
| read | Get token state (frozen, supply, price). |
| write | Claim reward phase earnings. |
| read | Check claimable reward amount. |
| read | List tokens you created. |
| read | Check if address is a Basis token. |
| read | Get token creation fee. |
| read | Get floor price for a token. |
Tool | Type | Description |
| write | Create a prediction market with metadata. Accepts image URL or local file. |
| write | Buy outcome shares. Uncapped payouts. |
| write | Claim winnings from resolved market. |
| read | Market data + outcome probabilities. |
| write | Propose winning outcome (5 USDB bond). |
| write | Dispute a proposed outcome. |
| write | Vote during a dispute round. |
| write | Finalize resolution after challenge period. |
| write | Claim resolver bounty. |
| read | Check shares held in a market. |
| write | Stake/unstake for dispute voting. |
| read | Full resolution pipeline status. |
| read | Market bounty pool amount. |
| read | Market general pot amount. |
| read | Estimate shares for a USDB bet. |
| read | Potential payout for holding shares. |
| write | Buy from order book + AMM in one tx. |
| read | Min USDB seed required to create a public prediction market. |
Tool | Type | Description |
| write | Multi-step: buy STASIS, wrap to wSTASIS, lock. |
| write | Unlock, unwrap, optionally sell to USDB. |
| write | Borrow USDB against locked wSTASIS. |
| write | Repay vault loan. |
| read | Full vault position status. |
| read | Full loan details for an active vault loan. Returns null if none. |
| write | Extend vault or hub loan. |
Tool | Type | Description |
| write | Loan against any token. No price liquidation. |
| write | Repay a hub loan. |
| read | List active loans. |
| read | On-chain details for a specific loan. |
| read | Count of wallet's loans. |
| write | Add collateral to existing loan. |
| write | Claim remaining collateral from expired loan. |
| write | Claim USDB residue from a liquidated leverage position (uses loanId). |
| write | Partially sell hub loan collateral. |
Tool | Type | Description |
| read | Wallet balances (USDB, STASIS, wSTASIS, factory tokens). |
| read | List prediction markets. |
| read | Search/list tokens. |
| read | Full detail for a single token. |
| read | OHLC candles. |
| read | Recent trades. |
| read | Platform pulse stats. |
| read | Your trading stats. |
| read | Your tier, rank, streak. |
| read | Platform leaderboard. |
| read | Public profile for any wallet. |
| read | Your created tokens and markets. |
| read | Your referral data. |
| read | Today's cap-fill % for |
| read | Your order book history. Paginated, optional status/market/outcome filters. |
| read | View whitelist for a frozen token. |
| read | Comments on a token. |
| read | Loan event history. |
| read | Vault staking event history. |
| read | Prediction market event history. |
| read | Market liquidity data. |
| write | Remove wallet from whitelist. |
Tool | Type | Description |
| write | Register as AI agent on-chain (ERC-8004). Optional tx_hash for recovery. |
| read | Check if a wallet is a registered agent. |
| read | List registered AI agents. |
| read | Look up agent by wallet. |
| read | Get agent metadata URI. |
| read | Get wallet for an agent ID. |
| read | Get agent metadata by key. |
| write | Update agent metadata URI. |
| read | Recover agent ID from a registration tx hash. |
Tool | Type | Description |
| write | Create gradual vesting schedule. |
| write | Create cliff vesting. |
| write | Batch create gradual vestings. |
| write | Batch create cliff vestings. |
| write | Claim vested tokens. |
| write | Borrow against a vesting. |
| write | Repay vesting loan. |
| read | Details for a vesting schedule. |
| read | Batch details for multiple vestings. |
| read | Total vesting schedules. |
| read | Check claimable amount. |
| read | Your vestings (as beneficiary or creator). |
| read | Vesting IDs for a token. |
| write | Transfer to new beneficiary. |
| write | Extend vesting duration. |
| write | Add tokens to existing vesting. |
| write | Transfer creator role. |
| read | Vesting event history. |
Tool | Type | Description |
| write | Place limit sell order on prediction market. |
| write | Cancel an open order. |
| write | Fill a single order. |
| write | Sweep multiple orders. |
| read | Cost to fill an order. |
| read | Amounts out for buying an order. |
| read | List orders for a market. |
Tool | Type | Description |
| read | Tax rate for a token + wallet. |
| read | Current surge tax. |
| read | Base rates for all token types. |
| read | Remaining surge quota. |
| write | Start surge tax (creator only). |
| write | End surge tax. |
| write | Add dev fee share. |
| write | Remove dev fee share. |
| read | Un-distributed accrued USDB earnings for a dev on a specific token. |
| read | Lifetime distributed USDB earnings across every token a dev has a share on. |
Tool | Type | Description |
| read | Get reef posts feed. |
| read | Highlighted posts. |
| read | Single post with comments. |
| read | Posts by a wallet. |
| read | Vote data for a post. |
| write | Create a post. |
| write | Edit your post. |
| write | Delete your post. |
| write | Comment on a post. |
| write | Edit your comment. |
| write | Delete your comment. |
| write | Toggle vote on a post. |
| write | Toggle vote on a comment. |
| write | Report a post. |
Tool | Type | Description |
| write | Create private prediction market with metadata. Accepts image URL or local file. |
| write | Buy shares in private market. |
| write | Redeem private market winnings. |
| write | List sell order. |
| write | Cancel order. |
| write | Fill an order. |
| write | Sweep multiple orders. |
| write | Buy from order book + AMM. |
| write | Vote on outcome. |
| write | Finalize market. |
| write | Claim bounty. |
| write | Add/remove voter. |
| write | Manage whitelist. |
| write | Toggle buyer access. |
| write | Open to public. |
| read | Get market data. |
| read | Get your shares. |
| read | Check if you can buy. |
| read | Min USDB seed for non-private private market. |
| read | Min USDB seed for voter-panel private market. |
Tool | Type | Description |
| write | Claim daily USDB drip (up to 500/day based on eligibility signals). |
| read | Check faucet eligibility, signals, and cooldown. |
| write | Manually sync a tx to backend. |
| write | Sync loan tx. |
| write | Sync order tx. |
| read | Get Twitter verification challenge. |
| write | Verify a Twitter challenge tweet for account linking. |
| write | Submit a tweet tagging @LaunchOnBasis for points. Max 3/day. |
Tool | Type | Description |
| read | Resolved outcome of a finalized market. |
| read | Dispute/proposal periods and bonds. |
| read | Check voter eligibility. |
| read | Your resolver stake amount. |
| read | Bounty allocation per vote. |
| read | Vote tallies in a dispute round. |
| read | What a voter chose. |
| write | Veto a proposed outcome (admin). |
| read | Check if you've bet on a market. |
| read | Single outcome data. |
| read | Initial reserves for outcomes. |
| read | wSTASIS shares to STASIS value. |
| read | Total vault TVL. |
Tool | Type | Description |
| write | Update username, avatar, or social links. |
| read | Referral data for a wallet. |
| read | Your verified tweets. |
| write | Submit a bug report. |
| read | Get bug reports. |
| write | Comment on a project. |
| write | Delete a project comment. |
| read | Get project comments. |
| write | Upload image to Basis from URL (token or avatar purpose). |
| write | Upload local image file to Basis. For agents with filesystem access. |
| write | Upload image and set as profile avatar in one step. |
Tool | Type | Description |
| write | Start linking Moltbook account. Returns challenge to post. |
| write | Verify challenge post to complete account linking. |
| read | Check Moltbook link status, post count, karma. |
| write | Submit a Moltbook post for points (max 3/day). |
| read | List all verified Moltbook posts. |
Asset-as-arg shape: every tool takes asset: btc | eth | bnb | cake | doge. Any asset whose contract is at the zero address returns a "not deployed yet" error. tf is 0=5m, 1=15m, 2=1h, 3=4h, 4=24h.
Tool | Type | Description |
| read | Round struct by id (or current round if |
| read | Your bet on a round. |
| read | Preview shares for a hypothetical bet. Includes slippage. |
| read | Exact USDB claimable from a settled round. 0 = nothing to claim. |
| write | Place bull/bear bet. Auto-approves USDB, pre-checks balance + minBet, optional |
| write | Claim winnings/refund. Refuses to send if |
| write | Public settle of an ended round (anyone can call). |
| write | Public cancel after settle window expired (anyone can call). |
| read | Aggregate bet/claim summary across all assets + timeframes. |
| read | Paginated round list per token, optional |
| read | Current bull probability (bps + %) for the active round. |
| read | Estimated payout if active round settled now in your favor. |
| read | Minimum USDB bet amount per asset. |
| read | Round duration in seconds for a timeframe. |
| read | Check if betting is paused on an asset. |
| read | Current slippage threshold in BPS for the active round (decays 95%→55%). |
The MCP server wraps the Basis TS SDK into the Model Context Protocol. The SDK is bundled inside — no separate installation required. Each tool maps to one or more SDK methods, handling:
Token resolution — pass "STASIS" or a raw address
Amount conversion — human-readable numbers (e.g. 50 = 50 USDB) converted to 18-decimal BigInts internally
Path routing — 3-hop swap paths for factory tokens (USDB <> STASIS <> token) built automatically
Guardrails — balance checks before sells, simulation before leverage, vote/claim deduplication
BigInt serialization — all on-chain values safely serialized to JSON
claude --mcp-server "node /path/to/MCP-TS/dist/index.js"Or add to your project's .mcp.json:
{
"basis": {
"command": "node",
"args": ["/path/to/MCP-TS/dist/index.js"],
"env": {
"BASIS_PRIVATE_KEY": "0xYOUR_KEY"
}
}
}npm publish --access publicThen anyone can use it with:
{
"mcpServers": {
"basis": {
"command": "npx",
"args": ["-y", "@basis-markets/mcp-server"],
"env": {
"BASIS_PRIVATE_KEY": "0xTHEIR_KEY"
}
}
}
}Elastic License 2.0 — free to use, modify, and share. Cannot be offered as a hosted/managed service.
Add more tokens to existing vesting.
| Name | Required | Description | Default |
|---|---|---|---|
| vesting_id | Yes | ||
| amount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description must disclose behavioral traits. It only states 'add more tokens' but doesn't mention side effects, required permissions, reversibility, or return value. For a write operation, 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?
Single sentence is concise but at the expense of crucial details. It earns its place but lacks structure (e.g., separate sections for parameters or examples).
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 annotations, no output schema, and zero parameter descriptions, the description is severely incomplete. It omits what the agent needs to know: authentication, effects on vesting state, error conditions, and response format.
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 0% and description adds no meaning to parameters. 'vesting_id' and 'amount' are not explained; the agent must infer their roles from parameter names alone. No constraints or formats provided.
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 action (add more tokens) and the target (existing vesting). It distinguishes from sibling tools like 'create_cliff_vesting' and 'extend_vesting' by focusing on token addition rather than creation or time extension.
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 or not use this tool. It implies use for an existing vesting but lacks context about alternatives, prerequisites (e.g., requiring a valid vesting_id), or comparison to other funding methods.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch create cliff vestings. All share the same token, unlock_time, ecosystem.
| Name | Required | Description | Default |
|---|---|---|---|
| beneficiaries | Yes | Wallet addresses | |
| token | Yes | ||
| amounts | Yes | Amount per beneficiary | |
| unlock_time | Yes | ||
| memos | No | Memo per beneficiary | |
| ecosystem | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It only discloses that the parameters token, unlock_time, ecosystem are shared across the batch, but does not mention side effects, atomicity, permissions, or error handling.
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, efficient sentence that front-loads the action and adds only essential detail. No redundant or unnecessary 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?
Given the complexity of a batch operation with multiple arrays, the description lacks important details such as return value, array length matching, optionality of memos, and error behavior. It is insufficient for complete understanding.
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 schema coverage is 50%, and the description adds value by clarifying that token, unlock_time, and ecosystem are single values shared across all vestings, while beneficiaries and amounts are per-vesting arrays. However, it does not explain memos or constraints on amounts.
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 'batch create' and the resource 'cliff vestings', and distinguishes from sibling tools like 'create_cliff_vesting' by specifying that all vestings share the same token, unlock_time, and ecosystem.
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 like 'create_cliff_vesting' or 'batch_create_gradual_vesting'. The sharing constraint is implied but not contrasted with other options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Batch create gradual vesting schedules. All share the same token, start_time, duration, time_unit, ecosystem.
| Name | Required | Description | Default |
|---|---|---|---|
| beneficiaries | Yes | Wallet addresses | |
| token | Yes | ||
| amounts | Yes | Amount per beneficiary | |
| memos | No | Memo per beneficiary | |
| start_time | Yes | ||
| duration_days | Yes | ||
| time_unit | No | 0=Sec,1=Min,2=Hr,3=Day | |
| ecosystem | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It reveals that all schedules share parameters but omits side effects, permissions, transaction costs, or reversibility. 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, front-loaded sentence with no unnecessary words. Every part earns its place.
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 moderate complexity (8 params, no output schema), the description omits crucial context like array length requirements, error handling, success output, and behavioral gotchas for batch operations.
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 50%; the description adds that beneficiaries, amounts, and memos are per beneficiary and that shared paramaters are identical. However, it doesn't explain units for start_time or duration_days, leaving gaps.
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 'batch create' and the resource 'gradual vesting schedules', distinguishing it from siblings like 'create_gradual_vesting' and 'batch_create_cliff_vesting'.
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 notes common parameters but does not explicitly state when to use batch vs single creation or gradual vs cliff. This minimal guidance leaves the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy shares in a prediction market outcome. UNCAPPED payouts — winners split entire losing pool + general pot, NOT $1/share. Before betting: 1) get_my_shares for existing position 2) estimate_shares_out for new shares 3) get_potential_payout(TOTAL shares = existing + new, usdb=bet_amount) → payout_if_win is your TOTAL payout. Profit = payout_if_win - total_invested.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market token address | |
| outcome | Yes | Outcome name or index | |
| amount_usdb | Yes | USDB to bet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description discloses the payout mechanism (winners split losing pool + general pot, not $1/share) and profit formula. However, it omits potential side effects (e.g., fees, loss of bet amount if outcome loses) and return value format.
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 concise (~70 words) and front-loaded with the core action. It efficiently packs payout model, pre-steps, and profit formula. Minor improvement possible in structuring the pre-steps as a clearer list.
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 annotations and no output schema, the description covers payout model and prerequisites but misses output format, error conditions, and success behavior. An agent needs more information about what the tool returns after a bet.
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 descriptions for each parameter. The description adds value by explaining how parameters relate to profit calculation (e.g., get_potential_payout context). This enhances understanding 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?
The description clearly states the tool's purpose: 'Buy shares in a prediction market outcome.' It distinguishes from sibling tools like estimate_shares_out and get_potential_payout by being the actual execution step. The unique payout model (UNCAPPED, not $1/share) further clarifies its role.
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 provides a sequential pre-betting checklist: 1) get_my_shares, 2) estimate_shares_out, 3) get_potential_payout, and explains how to compute profit. This explicitly guides when and how to use the tool, reducing ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sweep multiple orders at once.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| outcome | Yes | ||
| order_ids | Yes | ||
| total_usdb | Yes | ||
| min_shares | No | Minimum shares to receive (default: 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations and no behavioral details. The description does not disclose side effects, idempotency, auth requirements, or any constraints beyond the action. Lacks transparency 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 extremely concise but at the expense of clarity. One vague sentence does not earn its place; it should provide more useful information without being verbose.
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, 5 parameters including an array, and complex domain (trading orders), the description is insufficient. It lacks details on return value, execution behavior, or constraints.
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?
Only 1 of 5 parameters has a description in the schema (20% coverage). The description adds no explanation of parameter roles (e.g., 'market', 'outcome', 'order_ids', 'total_usdb'). Minimal value 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?
The description 'Sweep multiple orders at once' is somewhat vague; 'sweep' is not a standard verb and does not clearly convey the action (e.g., execute, buy, fulfill). It distinguishes from 'buy_order' but lacks precision.
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 guidelines on when to use this tool over alternatives (e.g., 'buy_order', 'buy_orders_and_contract', 'pm_buy_multiple_orders'). The description does not provide context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill a single order on the order book.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| order_id | Yes | ||
| amount_usdb | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose side effects, required permissions, or whether the action is irreversible. 'Fill' implies mutation but no behavioral details are given, leaving the agent unaware of constraints or consequences.
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 one sentence (7 words) and front-loads the purpose. While concise, it sacrifices necessary detail; a slightly longer description could include context without losing efficiency.
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 3 required parameters and no output schema, the description is too minimal. It fails to explain what 'fill' means (e.g., market vs limit), expected outcomes, or how it relates to order lifecycle, leaving the agent with insufficient context.
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 description adds no meaning beyond the parameter names. The input schema has zero coverage and no enum constraints. Parameters like 'market' and 'amount_usdb' lack format, units, or relationships, forcing the agent to guess.
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 'Fill a single order on the order book' uses a specific verb and resource, clearly distinguishing from sibling tools like 'buy_multiple_orders' (multiple orders) and 'cancel_order' (cancelling). It precisely states the action and scope.
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 is provided on when to use this tool versus alternatives, such as when to use 'buy_multiple_orders' or 'list_order'. The description lacks any contextual prerequisites or decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy from order book + AMM in one transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| outcome | Yes | ||
| order_ids | Yes | ||
| amount_usdb | Yes | ||
| min_shares | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility. It only mentions the combination but fails to disclose ordering, gas costs, slippage, or other behavioral traits relevant to a multi-step trade.
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 gets the main point across. It is front-loaded and concise, though it could benefit from slightly more detail without becoming verbose.
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 complexity of combining order book and AMM, the lack of output schema, and numerous sibling tools, the description is insufficient. It does not explain return values, success criteria, or how the tool integrates with the workflow.
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 0% and the description adds no explanation for any of the five parameters (market, outcome, order_ids, amount_usdb, min_shares). The agent cannot infer meaning from the description alone.
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 that the tool combines order book and AMM purchases in one transaction, which distinguishes it from sibling tools like 'buy_order' (order book only). However, it could be more explicit about what 'AMM' or 'contract' entails.
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 is provided on when to use this tool vs alternatives such as 'buy_order', 'buy_multiple_orders', or 'pm_buy'. The description lacks context for choosing this combined approach.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy a token using USDB. Elastic supply — buying increases price. Previews before executing. NOTE: Floor+ tokens (multiplier 1-99) and prediction market tokens have 1.5% tax, other tokens have 0.5% — account for this in slippage.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token name (STASIS) or address | |
| amount_usdb | Yes | USDB to spend | |
| slippage_percent | No | Max slippage % (default: 1) | |
| wrap | No | Wrap output to wSTASIS (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits fully. It mentions elastic supply (price increases) and previews before executing, but lacks details on authorization needs, rate limits, or side effects. The tax rate note helps, but more 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?
The description is very concise: two sentences plus a note. It communicates essential information without fluff, and the key point about elastic supply is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description covers the action, price behavior, and tax implications well. It doesn't explain the return value or confirm it's a write operation, but it's fairly complete for a transaction 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%, so the baseline is 3. The description adds context about USDB spending and tax rates, but doesn't provide additional parameter-level meaning beyond what's in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (buy a token) and the resource (using USDB). It also notes elastic supply and price increase, which adds specificity. However, it doesn't differentiate from sibling buy tools like pm_buy or buy_order, which could cause confusion.
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 provides a note about tax rates and slippage, which gives some guidance. But it doesn't explicitly state when to use this tool vs alternatives (e.g., pm_buy for prediction markets) 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.
Cancel an open order.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only states 'Cancel' implying mutation, but does not disclose any behavioral details such as whether the operation is reversible, idempotent, or requires specific permissions.
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 very short (one sentence) and front-loaded, but it is too terse and lacks important details. It is not verbose, but it sacrifices completeness for brevity.
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?
There is no output schema, and the description does not mention return values, confirmation, or side effects. For a mutation tool, this is a significant gap that leaves the agent uncertain about the result.
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 schema has 0% description coverage, and the tool description adds no information about the parameters. While 'market' and 'order_id' are self-explanatory, the description does not clarify their format, constraints, or relationship to other order tools.
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 (cancel) and resource (open order), which is concise and unambiguous. However, it could be more specific about the type of order, but given the context, it is sufficiently clear.
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 is provided on when to use this tool versus alternatives like pm_cancel_order or list_order. The description lacks any context about prerequisites or conditions for cancellation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer vesting to new beneficiary.
| Name | Required | Description | Default |
|---|---|---|---|
| vesting_id | Yes | ||
| new_beneficiary | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'Transfer' implies mutation, but nothing is said about side effects (e.g., what happens to the old beneficiary, permission requirements, reversibility). This lack of transparency increases risk of misuse.
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?
At 4 words, the description is under-specified rather than efficient. It fails to convey essential context. A good concise description would still pack meaningful details about usage and parameters.
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 complexity of transferring a beneficiary (likely irreversible with legal implications) and the presence of sibling tools, the description is woefully incomplete. There is no output schema, no parameter descriptions, and no annotations to compensate. The agent lacks critical information 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 description coverage is 0%, meaning no parameter descriptions exist in the schema. The description provides zero additional information about 'vesting_id' or 'new_beneficiary', leaving the agent without guidance on format, constraints, or semantics (e.g., is 'new_beneficiary' a wallet address ID?). This is a critical gap.
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 'Transfer vesting to new beneficiary' clearly states the action (transfer) and the resource (vesting) and target (new beneficiary). However, it does not differentiate from sibling tool 'transfer_vesting_creator', which likely handles a different role. A brief note distinguishing them would improve 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 is provided on when to use this tool versus alternatives like 'transfer_vesting_creator' or 'add_tokens_to_vesting'. The agent is left to infer context from the tool name alone, which is insufficient for correct selection among many vesting-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim resolution bounty.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market token address | |
| round | No | Round (for early bounties) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Claim', implying a state-changing action, but it fails to disclose any behavioral traits such as required permissions, side effects, or idempotency. The agent has no insight into what happens when the tool is invoked.
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 extremely concise at two words, but conciseness should balance brevity with informativeness. Here, the under-specification undermines clarity, making it insufficient for an agent to understand the tool's role.
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 no output schema, no annotations, and a terse description, the tool definition lacks completeness. It does not explain what constitutes a bounty, the effect of claiming, or how it fits among siblings. The agent is left with significant 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?
The input schema provides descriptions for both parameters (market token address, round for early bounties) with 100% coverage. The tool description adds no additional parameter context, but since the schema is self-explanatory, a 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 'Claim resolution bounty' states a verb and resource, indicating the tool claims a bounty. However, it lacks specificity about what kind of bounty (e.g., bug report bounty, market resolution bounty) and does not differentiate from sibling 'pm_claim_bounty', resulting in vague purpose.
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 is provided on when to use this tool versus alternatives like pm_claim_bounty. The description does not specify prerequisites, typical use cases, or when not to use it, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim daily USDB from faucet (up to 500 USDB/day based on eligibility signals). Requires SIWE session. Check get_faucet_status first.
| Name | Required | Description | Default |
|---|---|---|---|
| referrer | No | Referrer wallet address (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses requirement for SIWE session and daily limit based on eligibility. As no annotations exist, description carries full burden. Minor gap: doesn't state behavior if already claimed, but get_faucet_status mitigates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler, front-loads purpose, then adds vital usage context. Every sentence earns its place.
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 or annotations, the description covers purpose, constraints, prerequisite, and authentication need. Slightly incomplete on return value but acceptable given simplicity.
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?
Only one optional parameter (referrer) with full schema coverage. Description adds no extra meaning beyond schema, so 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?
Clearly states the verb 'claim', resource 'USDB from faucet', and constraints (daily, up to 500, eligibility-based). Distinguishes from sibling get_faucet_status by mentioning it as a prerequisite.
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 advises to check get_faucet_status first, providing a clear prerequisite. Does not name alternative tools but the guidance is sufficient for correct use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim USDB residue from a liquidated leverage position. Position must be inactive (already liquidated) and have a non-zero claim. Uses loanId (leverage position id), NOT hubId.
| Name | Required | Description | Default |
|---|---|---|---|
| loan_id | Yes | Leverage position ID (from get_leverage_positions) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions state conditions but lacks disclosure of side effects, permissions, rate limits, or return value. Minimal behavioral context beyond prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences: first states purpose, second adds conditions and parameter note. Front-loaded, no wasted words, easy to parse.
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 one-param tool with no output schema, the description adequately covers core purpose, usage conditions, and parameter clarification. Could mention post-claim effects but still sufficient for agent selection.
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 description 'Leverage position ID (from get_leverage_positions)'. Description adds value by clarifying it's loanId NOT hubId, which compensates for any potential confusion.
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 the action (claim) and resource (USDB residue from a liquidated leverage position). Explicitly mentions 'leverage' to distinguish from other claim tools. No 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?
Specifies prerequisites: position must be already liquidated and have non-zero claim. Also clarifies parameter usage (loanId not hubId). Does not explicitly compare with sibling 'claim_liquidation' but conditions are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim remaining collateral from expired loan.
| Name | Required | Description | Default |
|---|---|---|---|
| loan_type | Yes | ||
| hub_id | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states the action, but does not disclose side effects (e.g., whether the loan is closed, if collateral transfer is atomic), prerequisites, or error conditions. 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 sentence, which is concise, but it is too brief to cover necessary details. It does not earn its place as it omits critical information about parameters and usage context.
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 tool's complexity (2 params, no output schema, no annotations), the description is woefully incomplete. It fails to specify when the loan must be expired, what hub_id references, or what the return value is, making it difficult for an agent to use correctly.
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 0%, and the description does not explain any of the two parameters (loan_type, hub_id). It adds no meaning beyond the schema field names, leaving the agent without guidance on how to fill them correctly.
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 uses a clear verb-object structure: 'Claim remaining collateral from expired loan.' It identifies the specific action and resource, effectively distinguishing it from sibling tools like claim_rewards or claim_leverage_liquidation, though it does not explicitly mention that distinction.
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 a loan is expired ('from expired loan'), but provides no guidance on when not to use this tool or alternatives. With siblings like claim_leverage_liquidation, explicit usage boundaries would help, but they are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim accumulated rewards from reward phase.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It does not mention whether the action is idempotent, destructive, or if it affects any other state (e.g., claiming removes rewards). The phrase 'reward phase' is ambiguous and lacks clarity on process.
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 very concise, front-loading the verb and resource. However, its brevity sacrifices needed context for a claim action, making it efficient but slightly under-specified.
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 single parameter and no output schema, the description should clarify what 'reward phase' refers to, what happens after claiming (e.g., tokens transferred to wallet), and any conditions (e.g., only once per phase). The current description is insufficient for complete understanding.
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 already provides a description for the 'token' parameter ('Token address'). The tool description adds no additional meaning beyond what the schema provides, so it meets the baseline for 100% coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Claim accumulated rewards from reward phase' which identifies the action and resource, but among many sibling claim tools (claim_bounty, claim_faucet, etc.), it provides no distinction on what type of rewards are being claimed, leaving 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 guidance on when to use this tool versus alternatives like claim_bounty or claim_vesting_tokens. There is no mention of prerequisites, such as whether the user must have participated in a specific reward phase or have pending rewards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim vested tokens from a vesting schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| vesting_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states 'claim' implying mutation, but does not disclose side effects, error conditions, or what happens upon success.
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 single-sentence description is concise and front-loaded with the essential verb and resource, containing 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?
The description does not mention return values, prerequisites, or error handling. For a claim tool with no output schema, this lack of completeness could confuse an AI agent about what to expect.
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?
With 0% schema description coverage, the description fails to explain the 'vesting_id' parameter beyond its name. The name is self-explanatory, but additional context (e.g., format, how to obtain) is missing.
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 ('claim') and the resource ('vested tokens from a vesting schedule'), directly distinguishing it from sibling tools that create or modify vesting schedules.
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 when tokens have vested, but it does not provide explicit guidance on when to use it versus alternatives, nor does it mention prerequisites like being the beneficiary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Close (or partially close) a leverage position. 10% increments.
| Name | Required | Description | Default |
|---|---|---|---|
| position_id | Yes | Leverage position ID | |
| percentage | No | 10-100, divisible by 10 (default: 100) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It mentions closing a position but does not describe side effects (e.g., position deletion, collateral impact, fees). Minimal transparency beyond the basic action.
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 includes the essential action and the increment constraint. It is concise, but could benefit from additional context without becoming verbose.
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 return values. The tool modifies state, but the description omits details about what happens after closing (e.g., confirmation, remaining position). Context is minimal.
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% description coverage for both parameters (position_id and percentage). The description adds '10% increments' which is already present in the percentage parameter description. No new semantic value 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?
The description clearly states the tool closes or partially closes a leverage position, specifying the operation (close) and the resource (leverage position). It also mentions 10% increments, which distinguishes it from related tools like leverage_buy or get_leverage_positions.
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 provides a usage constraint (10% increments) but does not explicitly state when to use this tool versus alternatives like leverage_buy or adjust leverage. No guidance on prerequisites (e.g., having an open position) is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert wSTASIS shares to STASIS value.
| Name | Required | Description | Default |
|---|---|---|---|
| shares | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'Convert,' implying a mutation but without stating side effects (e.g., whether shares are destroyed, fees, reversibility). 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 very concise (6 words) and front-loaded. Every word contributes, but it may be too brief, lacking important context. Still, it avoids fluff and is 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?
Given the tool's simplicity (1 param, no output schema, no annotations), the description is incomplete. It does not explain conversion rate, return format, or side effects. For a mutation tool, more detail is needed to ensure correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter 'shares' with no description coverage. The description adds meaning by indicating the shares are wSTASIS and the output is STASIS value. However, it does not specify units, range, or conversion implications, so it adds minimal additional value.
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 (convert) and the resource (wSTASIS shares to STASIS value). It distinguishes this tool from siblings like get_my_shares or stake/unstake operations, though the exact nature of conversion (e.g., exchange rate) is not clarified.
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. No prerequisites or conditions are mentioned, leaving the agent uncertain about context (e.g., whether shares must be owned, if conversion is always available).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create cliff vesting — all tokens unlock at once.
| Name | Required | Description | Default |
|---|---|---|---|
| beneficiary | Yes | ||
| token | Yes | ||
| amount | Yes | ||
| unlock_time | Yes | Unix timestamp | |
| memo | No | ||
| ecosystem | No | Ecosystem token address (default: MAINTOKEN) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose behavioral traits such as mutability, authorization requirements, or side effects. It only restates the basic function.
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 extremely concise (one sentence) but at the cost of essential details. It is not verbose, but it underserves the schema.
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 annotations, output schema, and parameter clarity, the description is inadequate for an agent to reliably invoke this tool without errors.
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 low (33%), and the description adds no parameter-level information. Parameters like 'beneficiary', 'token', 'amount' are left unexplained.
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 ('Create'), the resource ('cliff vesting'), and the key behavior ('all tokens unlock at once'). It effectively distinguishes from gradual vesting alternatives.
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 other vesting tools (e.g., create_gradual_vesting, batch variants). The description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create gradual vesting schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| beneficiary | Yes | Recipient wallet | |
| token | Yes | Token address | |
| amount | Yes | ||
| start_time | Yes | Unix timestamp | |
| duration_days | Yes | ||
| time_unit | No | 0=Second, 1=Minute, 2=Hour, 3=Day | |
| memo | No | ||
| ecosystem | No | Ecosystem token address (default: MAINTOKEN) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose any behavioral traits beyond the bare action. It does not mention permissions, side effects, or what constitutes a gradual vesting schedule. The minimal text adds no 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 concise sentence with no extraneous words. However, its brevity sacrifices useful content, though it is well-structured for a minimal description.
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 tool has 8 parameters, 5 required, and no output schema, the description is severely incomplete. It does not explain the vesting schedule concept, parameter roles, or return value, leaving the agent with insufficient context to use the tool correctly.
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 description does not explain any parameters beyond what the input schema already provides. With 63% schema coverage, the description should compensate for missing parameter descriptions but does not, leaving parameters like 'amount' and 'duration_days' unexplained.
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 creates a gradual vesting schedule, but does not differentiate from sibling tools like batch_create_gradual_vesting or create_cliff_vesting, leaving ambiguity about when to use this specific tool.
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 is provided on when to use this tool over alternatives. Sibling tools exist for batch creation and cliff vesting, but the description offers no context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create prediction market. Earn 20% of net trading fees forever. Provide image_url OR image_file_path.
| Name | Required | Description | Default |
|---|---|---|---|
| question | Yes | Market question | |
| symbol | Yes | Market token symbol | |
| outcomes | Yes | e.g. ['Yes', 'No'] | |
| end_time | Yes | ISO date or unix timestamp | |
| seed_usdb | No | USDB seed (min 50, default: 50) | |
| description | No | ||
| image_url | No | ||
| image_file_path | No | Local image file path (alternative to image_url) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description should disclose behavioral traits. It fails to specify side effects, permission requirements, or whether the operation is idempotent. The only behavioral hint is the fee earning, which is a feature, not a behavioral disclosure.
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 concise with two short sentences, no redundant information. However, it could be better structured to front-load critical usage info. Still, it earns a high score for being succinct.
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 complexity (8 parameters, numerous sibling tools, no output schema), the description is insufficient. It lacks guidance on when to create a market, what the return values are, and how it relates to similar tools like 'pm_create_market'. The AI would need more context to use it correctly.
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 high (75%), providing baseline 3. The description adds value by clarifying the mutual exclusivity of 'image_url' and 'image_file_path', which is not evident from the schema. This nuance helps the agent choose correctly.
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 'Create' and resource 'prediction market', and includes a unique benefit (earning fees). However, it does not differentiate from the sibling tool 'pm_create_market', which likely has similar functionality.
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 provides no guidance on when to use this tool versus alternatives. It mentions a fee incentive but does not indicate prerequisites, restrictions, or contrasting conditions with siblings like 'pm_create_market'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Comment on a token project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| content | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must fully convey behavioral traits. It only states 'Comment on a token project' which is vague. It does not disclose whether the comment is added, if it requires permissions, if it is irreversible, or what the response is. The behavioral transparency is very low.
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 extremely concise at one sentence, but it lacks necessary details, making it more under-specified than efficiently concise. It does not earn its place because it does not add enough value for an agent to use the tool correctly.
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 description is incomplete given the low schema coverage, lack of annotations, and output schema. It does not specify what happens upon success, error conditions, or how the parameters relate. An agent would lack sufficient information to use the tool correctly, especially among many similar 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?
The input schema has zero descriptions for its two parameters. The tool description adds no parameter-level explanation; it only implies that project_id and content are involved. This is insufficient for an agent to correctly provide values, especially since project_id may require specific format or constraints.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool 'Comment on a token project.' It identifies the action and subject, but lacks specificity about what 'comment' entails (create a comment) and does not differentiate from other comment tools like 'create_reef_comment'. The purpose is broadly clear but could be more precise.
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 provides no usage guidelines, failing to specify when to use this tool instead of alternatives like 'create_reef_comment' or 'create_reef_post'. There is no mention of context, 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.
Comment on a reef post.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as whether the operation is write-only, any side effects, or permission requirements. This is insufficient for a creation 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 sentence, making it concise, but it lacks structure (no separate sections). While efficient, it omits useful details that could be added without verbosity.
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 simplicity (2 required params, no output schema), the description does not cover what the comment's effect is, whether it replies to a previous comment, or what is returned. It is incomplete.
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?
With 0% schema description coverage, the description adds minimal meaning. It implies that 'body' is the comment text and 'post_id' identifies the post, but it does not explicitly define them, leaving ambiguity.
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's purpose: 'Comment on a reef post.' It uses a specific verb and resource. However, it does not explicitly differentiate from sibling tools like create_project_comment, though the name implies reef-specific context.
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 provides no guidance on when to use this tool, prerequisites, or when not to use it. It lacks explicit context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new reef post.
| Name | Required | Description | Default |
|---|---|---|---|
| section | Yes | ||
| title | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only says 'Create', implying a mutation, but fails to disclose permissions, idempotency, side effects, or return values. This is insufficient for a creation operation.
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 short sentence, which is concise but lacks substantive information. It is not wasteful, but it under-specifies the tool.
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 tool has three required parameters with no schema descriptions, no output schema, and no annotations, the description is critically incomplete. It fails to provide essential context for correct 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?
The input schema has 0% description coverage, and the tool description does not explain the parameters (section, title, body). The agent cannot infer valid values or constraints from the definition alone.
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 'Create' and the resource 'reef post', distinguishing it from siblings like 'create_reef_comment' and 'edit_reef_post'. However, it does not define what a 'reef post' is, leaving some 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 guidance is provided on when to use this tool versus alternatives such as 'create_reef_comment' or 'edit_reef_post'. The agent receives no context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new token. You earn 20% of every trade forever. Stable+ = price only up, Floor+ = real movement with protection. Provide image_url OR image_file_path (at least one required).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Token full name | |
| symbol | Yes | Token ticker | |
| type | Yes | Token type | |
| stability | No | 1-90 for Floor+ (default: 50) | |
| start_lp | No | Starting virtual liquidity 100-10000 (default: 1000) | |
| description | No | ||
| image_url | No | Image URL | |
| image_file_path | No | Local image file path (alternative to image_url) | |
| website | No | ||
| telegram | No | ||
| No | |||
| frozen | No | Start frozen (default: false) | |
| usdb_for_bonding | No | USDB to seed for frozen tokens | |
| auto_vest | No | Enable auto-vesting | |
| auto_vest_duration | No | Auto-vest duration in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It explains token type behaviors but omits side effects, permission requirements, or creation costs. Limited 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 concise with three sentences, front-loading the main action. It efficiently adds value without unnecessary details.
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 tool's complexity (15 parameters, no output schema), the description covers the core purpose and key differentiators but lacks information on prerequisites, costs, or return values. Adequate but not fully 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?
The description adds meaning beyond the input schema by clarifying the image requirement ('Provide image_url OR image_file_path') and explaining token types ('Stable+ = price only up, Floor+ = real movement with protection'). This compensates for 73% schema coverage.
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 'Create a new token' with a specific verb and resource. It distinguishes token types (Stable+, Floor+) and mentions the earning mechanism, making the purpose unambiguous.
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 explains the tool's functionality but does not provide explicit guidance on when to use it versus sibling tools or when not to use it. Context is implied by the tool name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete a project comment.
| Name | Required | Description | Default |
|---|---|---|---|
| comment_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a destructive action but does not disclose behavioral traits such as idempotency, error handling, or authorization requirements. With no annotations, 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 very concise but lacks necessary detail. It is not verbose, but the trade-off is under-specification.
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, annotations, and parameter descriptions, the description fails to provide enough context for an agent to invoke the tool correctly. It omits return value, error handling, and prerequisite details.
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 0% description coverage, and the description adds no information about the 'comment_id' parameter (e.g., what it identifies, format constraints).
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 'delete' and the resource 'project comment', which is specific and distinct from sibling tools like create_project_comment or delete_reef_comment.
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 is provided on when to use this tool versus alternatives (e.g., delete_reef_comment) or any prerequisites (e.g., ownership, authentication).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete your reef comment.
| Name | Required | Description | Default |
|---|---|---|---|
| comment_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must carry behavioral transparency. 'Delete' implies destruction, but the description does not state irreversibility, required ownership, or any side effects (e.g., removing associated votes). The hint 'your' is not enough.
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, short sentence that is clear and to the point. However, it omits critical details that could be included without verbosity, such as ownership and permanence.
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?
Without output schema or annotations, the description should cover fundamental aspects of a delete operation. It fails to mention that deletion is permanent, requires ownership, or what happens to associated data like votes or replies. This is insufficient for an AI agent to reliably invoke the 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?
The only parameter, 'comment_id', has no description in the schema (0% coverage) and the tool description provides no explanation of its meaning or source. The agent must infer its purpose and format without guidance.
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 'Delete your reef comment' clearly identifies the action (delete) and resource (reef comment). It distinguishes from siblings like 'delete_reef_post' and 'edit_reef_comment'. The possessive 'your' implies ownership, adding a bit of specificity.
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 is provided on when to use this tool versus alternatives such as 'delete_project_comment' or 'edit_reef_comment'. There are no prerequisites, exclusions, or context about ownership or permissions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete your reef post.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavioral traits. It states 'Delete' implying mutation, but omits whether the deletion is reversible, if permissions are needed, or any side effects (e.g., cascading deletes).
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 only three words, which is concise but underspecified. For a simple delete operation, it could be slightly expanded without losing 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?
Given the lack of annotations and output schema, the description is too minimal. It fails to address error conditions, prerequisites, or the outcome of the 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?
The input schema has one parameter (post_id) with 0% schema description coverage. The description adds no meaning beyond the schema; it does not explain what post_id represents or how to obtain it.
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 ('Delete') and resource ('your reef post'). The verb-resource pairing is specific and distinguishes it from siblings like create_reef_post or edit_reef_post.
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 usage guidance is provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites like ownership or the existence of the post being required.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Dispute proposed outcome (5 USDB bond).
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market token address | |
| outcome | Yes | Alternative outcome |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It mentions a '5 USDB bond' implying a cost, but does not explain what happens to the bond, the dispute process, or any side effects such as whether the dispute triggers a voting period.
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 very concise with a single sentence. However, it sacrifices completeness for brevity; for a tool with two parameters and no annotations, a slightly longer description could improve clarity without losing 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?
Given the tool's nature (disputing outcomes with a bond) and the lack of annotations or output schema, the description is insufficient. It fails to explain the effect of the dispute, how the bond is handled, or what constitutes an 'alternative outcome', leaving the agent underinformed.
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 already provides 100% coverage with descriptions for both parameters. The description adds no additional meaning or constraints beyond what the schema states, so a 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 uses the verb 'Dispute' and object 'proposed outcome', clearly identifying the action and resource. It further distinguishes from siblings like 'propose_outcome' and 'veto_outcome' by mentioning the '5 USDB bond', adding specific context that differentiates it.
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 is provided on when to use this tool versus alternatives such as 'veto_outcome' or 'propose_outcome'. There is no mention of prerequisites, conditions, or suitable contexts for disputing an outcome.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit your reef comment.
| Name | Required | Description | Default |
|---|---|---|---|
| comment_id | Yes | ||
| body | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral transparency. It only says 'Edit your reef comment', which implies mutation, but fails to disclose whether ownership is required, if there are time limits, or what the side effects (e.g., overwriting) are.
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 extremely concise with one short sentence. While not verbose, it lacks necessary detail and is borderline under-specified.
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 annotations, output schema, and parameter descriptions, the description is insufficient for an agent to use the tool correctly. It omits ownership constraints, allowed actions, and result expectations.
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 0% coverage and the description adds no meaning to parameters. 'comment_id' and 'body' are not explained, so the agent cannot infer their format or purpose beyond the schema names.
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 'Edit' and the resource 'reef comment', making the tool's purpose immediately understandable. However, it does not differentiate from siblings like delete_reef_comment or create_reef_comment.
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 is provided on when to use this tool versus alternatives such as delete_reef_comment or vote_reef_comment. There are no exclusions, prerequisites, or context clues for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Edit your reef post.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | ||
| title | No | ||
| body | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only says 'Edit,' which implies mutation but offers no details on side effects, permissions, or what happens to the original post. 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 short sentence, which is concise but lacks necessary detail. It would benefit from additional context. Conciseness should not come at the expense of completeness.
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, no annotations, and three undocumented parameters, the description is severely incomplete. It fails to explain what fields are editable, constraints, or the result of the operation. A complete description would provide this context.
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 3 parameters with 0% description coverage. The description does not mention or clarify any parameters beyond what the schema provides (e.g., post_id is required, title and body are optional). The description adds no value to understanding the 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 states 'Edit your reef post.' which clearly indicates the action (edit) and resource (reef post). It is distinct from siblings like create_reef_post and delete_reef_post. However, it does not specify which fields can be edited, which is implied but not detailed.
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 create_reef_post or delete_reef_post. The description does not provide context for appropriate usage or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
End surge tax on your token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
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 only states the action but does not disclose side effects, permissions required, or what happens to the surge tax state. For a mutation tool, 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, very concise. It avoids unnecessary words. However, it could be more informative without becoming verbose.
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 tool's simplicity (one parameter, no output schema), a complete description should explain what a surge tax is, that it must be active, and how to identify the token. The current description lacks this context.
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 one required parameter 'token' with 0% description coverage. The description adds no meaning beyond the parameter name, leaving ambiguity about whether it expects a token address, symbol, or identifier.
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 ('End') and the resource ('surge tax') and specifies it applies to 'your token'. It distinguishes well from siblings like 'start_surge_tax' and 'get_surge_tax'.
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 or why to use this tool versus alternatives. It does not mention prerequisites, such as whether a surge tax must be active, nor does it indicate when to use 'start_surge_tax' instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extend vault or hub loan. ~400x cheaper than new loan.
| Name | Required | Description | Default |
|---|---|---|---|
| loan_type | Yes | ||
| hub_id | No | Required for hub | |
| days | Yes | ||
| pay_in_stable | No | Pay extension fee in USDB (default: true) | |
| refinance | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the action and cost benefit, failing to mention side effects, safety, or whether the operation is destructive. It does not indicate if permissions are required or what changes occur.
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 very concise with two sentences. The first sentence states the action, the second adds a key benefit. No unnecessary words, though it could be slightly more structured to hint at parameters.
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 five parameters and no output schema or annotations, the description is incomplete. It doesn't explain how to specify the loan (loan_type and hub_id), what 'days' means, or what the output is. The agent lacks enough context to use the tool confidently.
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 only 40% (2 of 5 parameters have descriptions). The description adds no parameter-level meaning; it mentions 'vault or hub' which is already in the schema enum, but doesn't explain 'days', 'hub_id' beyond the schema, or 'refinance'.
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 extends vault or hub loans, with a specific verb and resource. It distinguishes the action from taking a new loan, though it does not explicitly differentiate it from sibling tools like 'extend_vesting' or 'take_loan'.
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 extending an existing loan rather than taking a new one, citing cost savings. However, it lacks explicit guidance on when not to use it (e.g., if the loan is not extendable) or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extend vesting duration.
| Name | Required | Description | Default |
|---|---|---|---|
| vesting_id | Yes | ||
| days | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose any behavioral traits such as mutability, authorization needs, or side effects. It adds no value beyond the tool name.
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 extremely concise with only one sentence, but it is under-specified rather than efficiently informative. It fails to earn its place by omitting critical details.
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 two required parameters, no output schema, and many sibling vesting tools, the description is wholly incomplete. It lacks information on return values, side effects, and relationship to other 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?
The input schema has two parameters with no descriptions. The description does not explain the meaning of 'vesting_id' or 'days', nor does it specify allowed values (e.g., positive/negative).
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 'Extend vesting duration' clearly states the action and resource. It is distinct from sibling tools like 'change_vesting_beneficiary' but does not explicitly differentiate itself.
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 other vesting modifications, nor any prerequisites or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finalize market resolution after challenge period.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market token address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only says 'finalize', which suggests an irreversible state change, but lacks details on side effects (e.g., payouts, stake handling, permissions) beyond the name. Agents need more 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?
The description is one sentence, but it is minimally informative. It is not wordy, but could be more helpful without being longer. Not quite concise due to lack of content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, and the tool being an irreversible action, the description is insufficient. It omits crucial context about outcomes, prerequisites, and effects, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The parameter description 'Market token address' is clear and matches the schema. No additional meaning added beyond what the 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?
The description clearly states the verb 'finalize' and the resource 'market resolution', and specifies the timing 'after challenge period', distinguishing it from earlier resolution steps like dispute_outcome or propose_outcome.
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 or not use this tool. It implies the condition 'after challenge period' but does not state prerequisites, alternatives, or when to avoid it (e.g., if challenge period not expired).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get agent ID from a registration transaction hash (recovery tool).
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only states the basic function but does not disclose error behavior (e.g., invalid tx_hash), prerequisites (must be a registration tx), or whether any side effects exist. The minimal disclosure leaves significant gaps.
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, front-loaded sentence with no extraneous words. It efficiently conveys the action and context.
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, the description does not clarify what the return value looks like (e.g., string format, error cases). For a simple retrieval tool, it is somewhat incomplete but still usable for basic understanding.
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 sole parameter tx_hash is described only by its name in the schema (0% coverage). The tool description adds the context 'registration transaction hash', providing some meaning beyond the schema, but does not specify format or constraints (e.g., hex length).
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', the resource 'agent ID', and the source 'registration transaction hash'. It also adds context as a 'recovery tool', distinguishing it from sibling tools like get_agent_metadata or lookup_agent that use agent identifiers.
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 for recovering agent ID from a registration tx, but does not explicitly state when to use this tool versus alternatives like lookup_agent or is_agent_registered. No when-not or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get metadata key for an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| key | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the burden falls entirely on the description. It only implies a read operation but gives no details on side effects, auth requirements, rate limits, or return 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?
The description is very short (6 words) and front-loaded. However, conciseness comes at the cost of missing essential details. It could be expanded slightly to add value without becoming verbose.
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 2-parameter tool with no output schema and no annotations, the description fails to convey what the tool returns or how it behaves. The agent is left guessing about the result format and edge cases.
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 0%, meaning no parameter descriptions in the schema. The description does not explain the role of agent_id or key, nor their allowed values or formats.
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 (Get) and target (metadata key for an agent). However, it lacks specificity—does it retrieve the value of a key or the key itself? Also, it does not differentiate from sibling tools like get_agent_uri or get_agent_wallet.
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. No prerequisites, exclusions, or context provided. Given many get_* siblings, the agent has no basis to choose this over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the metadata URI for an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose traits like idempotency or side effects. It only says 'Get', failing to confirm it's a pure read operation or specify any required permissions. The behavioral profile is not established.
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 is efficient, but it could be expanded to include key context (e.g., return type) without becoming verbose. It earns its place but is too terse for full utility.
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 a single parameter, the description should at least hint at the return value format or common use cases. It does not, leaving the agent underinformed for a tool that could be easily confused with similar getters.
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 0%, and the description does not explain the 'agent_id' parameter at all. It should clarify what constitutes a valid agent_id (e.g., from registration) or any constraints, but it provides 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?
The description clearly states it retrieves a 'metadata URI' for an agent. Among many get_* siblings, this distinguishes itself by specifying the exact resource (URI) and implies it's a simple retrieval, not a complex query.
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_agent_metadata or get_agent_wallet. The description does not mention scenarios or prerequisites, leaving the agent to guess based solely on the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get wallet address for an agent ID.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. However, it does not disclose any behavioral traits (e.g., effect of missing agent_id, data source, or performance characteristics).
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?
Very short (5 words) and to the point, but lacks essential details. Could benefit from a sentence about return value or usage context.
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 simplicity of the tool (1 param, no output schema), the description is still incomplete. Does not mention what the wallet address is (e.g., string format, blockchain) or what happens if the agent ID is invalid.
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 0%, meaning the description does not elaborate on the 'agent_id' parameter beyond the schema. No guidance on format, range, or how to obtain it.
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 action (Get) and resource (wallet address for an agent ID). It is specific and distinct from sibling tools like get_agent_metadata or get_agent_uri.
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 get_agent_metadata or get_agent_uri. No prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get remaining surge tax quota for a token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It does not disclose whether the operation is read-only, requires authentication, or has side effects. The tool name implies a read, but this is not explicitly stated.
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 extremely concise at one sentence, but it lacks structure (e.g., separate sections for purpose, parameters, behavior). It is efficient but omits critical details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and no annotations, the description should explain the return value format, usage context, and any dependencies. It fails to do so, leaving the agent without sufficient information to invoke the tool correctly.
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 0%, and the description adds no information about the 'token' parameter beyond its existence. It does not specify what format (address string, ID), source, or constraints apply.
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 ('Get') and the resource ('remaining surge tax quota') with a single required parameter ('token'). It distinguishes from sibling tools like 'get_surge_tax' by specifying 'quota' vs. 'tax' (likely different concepts). However, it does not clarify what 'surge tax quota' represents, which could be ambiguous.
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 is provided on when to use this tool versus alternatives (e.g., get_surge_tax, start_surge_tax). The description lacks any context on prerequisites or appropriate scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wallet balances — USDB, STASIS, wSTASIS, factory tokens.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose side effects, authentication, or rate limiting. It only lists token types. There is no mention that this is a read-only, safe operation, or what the response contains beyond a hint of token names. This leaves the agent uncertain about 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?
The description is a single, compact sentence that conveys essential information without wasted words. It front-loads the purpose ('Wallet balances') and specifies the token types efficiently.
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 partially explains return values by naming token types, but it does not indicate the format (e.g., amounts, list) or explicitly state that balances belong to the authenticated user. For a parameterless tool, this leaves some ambiguity, but the core information is present.
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 no parameters, so the description does not need to explain them. The baseline for empty params is 4. The description adds value by listing the specific token types returned, which helps set expectations 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?
The description clearly states the tool returns wallet balances for specific token types (USDB, STASIS, wSTASIS, factory tokens). The verb and resource are implied by the name, making the purpose understandable. However, it does not specify whose wallet (presumably the user's), which is a minor 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 guidance is provided on when to use this tool over alternative get tools (e.g., get_my_tokens, get_my_stats). There are many sibling tools with similar purposes, and the description does not differentiate use cases or state prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get base tax rates for all token types.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits like data freshness, authentication requirements, or response format. For a read operation, additional context on scalability or caching would be helpful.
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 efficiently conveys the tool's purpose without 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 description lacks details about the output format or what 'base tax rates' constitute. Without an output schema, the agent may not understand the returned structure. Additionally, no explanation of which token types are considered.
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 tool has zero parameters, and the schema coverage is 100%. The description adds no further parameter details, which is acceptable. 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 (get), the resource (base tax rates), and scope (all token types). It effectively distinguishes from siblings like get_tax_rate which likely returns a single rate.
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 such as get_tax_rate or get_surge_tax. The description does not provide context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bounty allocation per vote for a market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
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 only explains the basic operation but does not disclose any behavioral traits such as side effects, permissions, or rate limits, which are essential for a full 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?
The description is a single sentence with no wasted words. It is efficient, though lacking structural elements like bullet points or examples.
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 getter with one parameter and no output schema, the description is minimally adequate. However, it does not explain the return value or any additional context, leaving gaps for an agent.
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 sole parameter 'market' is a string with no description in the schema (0% coverage). The description does not elaborate on what 'market' refers to, leaving ambiguity about its format or expected values.
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 the resource 'bounty allocation per vote' for a market. It is specific enough to distinguish from many sibling get_* tools, though it does not explicitly differentiate from similar ones like 'get_bounty_pool'.
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, no prerequisites or context for usage. The description merely states the function without any directional advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bounty pool amount for a prediction market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations absent; description only says 'Get' implying read-only but no further behavioral context (auth, rate limits, side effects). Minimal disclosure.
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?
One concise sentence, but too short to provide necessary context. Not front-loaded beyond the name.
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 only hints at 'amount' without specifying format or semantics. For a simple tool, more detail on return value would be helpful.
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 0%; parameter 'market' is a generic string with no added meaning. Description does not explain what 'market' refers to (ID, address, etc.).
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 verb (get), resource (bounty pool amount), and context (prediction market). Distinguishes from siblings like get_bounty_per_vote and claim_bounty.
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. No prerequisites or when-not-to-use information provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get bug reports.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| limit | No |
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 only states the basic action without disclosing traits like read-only nature, authentication requirements, rate limits, or return behavior. The description adds no value beyond the name.
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 extremely short (one sentence) and front-loaded with the key action. However, it is overly terse; adding parameter context would improve without sacrificing 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?
Given the large number of sibling tools and the minimal input schema, the description lacks essential details such as return format, filtering behavior, pagination, or outcome examples. It is not sufficient for proper tool selection and 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 0% with no parameter descriptions. The description does not explain what 'status' or 'limit' mean or how they affect results. The enum values for status are self-explanatory, but the lack of parameter guidance is a significant gap.
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 (Get) and resource (bug reports). It is a specific verb-resource pair that distinguishes the tool's purpose from mutation tools like 'submit_bug_report', but among many 'get_*' siblings, no differentiation is provided.
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 (e.g., other get_* tools or submit_bug_report). The description provides no context about expected use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get amounts out for buying an order with USDB.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| order_id | Yes | ||
| amount_usdb | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden. It only says 'Get amounts out', implying read-only, but does not disclose any potential side effects, rate limits, authentication requirements, or error 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?
The description is a single concise sentence with no unnecessary words. It is efficiently structured for quick comprehension.
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 complexity (3 parameters, no output schema), the description is insufficient. It fails to explain what 'amounts out' represents, the output format, or any calculation logic. A more complete description would clarify the return value.
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 0%, so parameter descriptions are absent. The description only clarifies that 'amount_usdb' is the amount to spend, but does not explain 'market' or 'order_id' beyond their names. Minimal added meaning.
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 the resource 'amounts out for buying an order with USDB'. It distinguishes from sibling tools like 'buy_order' by name and wording, but does not explicitly contrast them.
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 is provided on when to use this tool versus alternatives such as 'buy_order' for execution. No context about 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.
Check claimable rewards amount before claiming.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token address | |
| investor | No | Investor address (default: your wallet) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description indicates a read-only check (no side effects) but does not detail return format or potential edge cases.
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 unnecessary words; highly efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter tool, description provides necessary context; no output schema needed as return value is implied.
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 descriptions; description adds no extra meaning beyond schema, so baseline score.
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 the tool checks claimable rewards amount before claiming, distinguished from sibling claim_rewards which performs the actual claim.
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 says 'before claiming', indicating when to use; implies a pre-check step, effectively distinguishing from claim_rewards.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check claimable amount for a vesting.
| Name | Required | Description | Default |
|---|---|---|---|
| vesting_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation but does not explicitly state it is safe or non-destructive. Since no annotations are provided, the description carries the full burden, yet it lacks details on authentication, rate limits, or error handling.
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 with no unnecessary words, making it highly 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?
For a tool with one parameter and no output schema, the description is minimal and fails to explain what 'claimable amount' means or what the tool returns, making it incomplete for an agent to use effectively.
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 one parameter 'vesting_id' with 0% description coverage, and the tool description does not mention or explain this parameter, leaving the agent without any understanding of its meaning or format.
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 'Check claimable amount for a vesting' clearly states the verb 'check' and the resource 'claimable amount for a vesting', which distinguishes it from sibling tools like 'get_vesting_details' or 'claim_vesting_tokens'.
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 information is provided about when to use this tool versus alternatives such as 'get_vesting_details' or 'claim_vesting_tokens', leaving the agent without guidance on selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get un-distributed accrued USDB earnings for a dev on a specific token. Reads the pending balance before next distribution.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token contract address | |
| dev | No | Dev wallet address (default: your wallet) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'reads the pending balance', indicating a read operation, but lacks details on side effects, permissions, or rate limits. Minimal behavioral disclosure beyond basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. Essential information is front-loaded: action, resource, and key constraint ('before next distribution').
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, but description indicates that a pending balance is returned. For a simple read operation, this is fairly complete. Could specify return type (e.g., number or string), but not critical for agent 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?
Input schema covers both parameters with descriptions in the schema itself (100% coverage). The description adds no extra meaning beyond what the schema already provides, so 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?
The description clearly states the tool retrieves 'un-distributed accrued USDB earnings' for a developer on a specific token, with a verb ('get') and specific resource ('creator earnings'). It differentiates from siblings like 'get_dev_total_earnings' by specifying 'pending balance before next distribution'.
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?
Implies usage for checking pending earnings before distribution, but no explicit when-to-use, when-not-to-use, or alternatives. Sibling 'get_dev_total_earnings' exists but is not mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a dev's lifetime distributed USDB earnings across every token they have a share on.
| Name | Required | Description | Default |
|---|---|---|---|
| dev | No | Dev wallet address (default: your wallet) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It implies a read-only query but does not mention authentication requirements (the default wallet hint is minimal), rate limits, data freshness, pagination, or whether the result is a sum or per-token breakdown. The absence of an output schema further compounds this gap.
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 that directly states the tool's function. No extraneous information; every word adds value.
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 absence of an output schema, the description should have clarified the return format (e.g., single number vs. list). The phrase 'lifetime distributed USDB earnings across every token' suggests aggregation but is ambiguous. For a simple tool with one parameter, this is minimally adequate 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?
The input schema covers the single parameter 'dev' with a description already including the default behavior. The tool description adds no additional semantic information about the parameter or its relation to the result, so with 100% schema coverage, a 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 tool retrieves a dev's lifetime distributed USDB earnings across all tokens they have a share on. The verb 'Get' and the specific resource 'lifetime distributed USDB earnings' make the purpose unambiguous and distinguishable from sibling tools like get_balances or get_creator_earnings, though an explicit differentiation would strengthen it.
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 is provided on when to use this tool versus alternatives like get_creator_earnings or get_balances. The description only states what the tool does, leaving the agent to infer context from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check faucet eligibility — signals, claimable amount, cooldown timer. Must be authenticated.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description adds authentication requirement and implies read-only nature, but does not disclose other behavioral traits like rate limits or idempotency beyond what annotations would cover.
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 wasted words. Information is front-loaded and every word adds value.
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 zero parameters and no output schema, the description fully explains what the tool returns (signals, claimable amount, cooldown timer) and the authentication requirement. Complete for a status check 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?
Input schema has zero parameters, so schema coverage is 100% vacuously. Description adds no parameter info, but baseline is 4 since parameters are absent.
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 'Check' and resource 'faucet eligibility', listing specific outputs (signals, claimable amount, cooldown timer). It distinguishes from sibling 'claim_faucet' by focusing on status verification.
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?
States 'Must be authenticated' but lacks explicit guidance on when to use versus alternatives like 'claim_faucet'. The usage context is implied but not fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the factory token creation fee.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It does not state that the tool is read-only or whether it requires authentication. It lacks any behavioral context beyond the action of 'getting' the fee.
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 with no superfluous words. It efficiently conveys the tool's purpose.
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 tool has no parameters and no output schema, the description provides sufficient context for a simple fee retrieval. It could be improved by hinting at the return type (e.g., 'returns the fee as a number'), but the current description is adequate.
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 tool has zero parameters, and the schema coverage is 100% (empty schema). Per rubric, baseline is 4 for zero-parameter tools. The 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?
The description clearly states the tool retrieves the 'factory token creation fee', which is a specific and distinct resource. Among siblings with similar 'get_*' names, this tool's purpose is unambiguously identified as fetching a particular fee.
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 like get_tax_rate or get_base_tax_rates. However, the description implies it should be used to obtain the fee amount, and the simplicity of the tool reduces the need for extensive guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the resolved outcome of a finalized market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only states the tool returns a 'resolved outcome' for a 'finalized market', but does not disclose behavior for non-finalized markets, error handling, or response format.
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, but it lacks structure such as usage notes or parameter details. It is adequately brief but could be more informative without losing 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?
No output schema is provided, and the description fails to explain what the resolved outcome looks like. Given the domain complexity and the existence of sibling tools, this description is insufficient for an agent to use the tool correctly.
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 0%, and the description does not explain the 'market' parameter (e.g., format or example). The agent must infer its meaning from the tool name alone.
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 retrieves the resolved outcome of a finalized market. However, it does not distinguish from the sibling tool 'get_outcome', leaving ambiguity about when to use which.
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 is provided on when to use this tool versus alternatives like 'get_outcome' or 'get_market_resolution_status'. The agent is left to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the USDB floor price for a factory token. Does NOT work on STASIS — only factory-created tokens.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Factory token address (not STASIS) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It clearly discloses the limitation to factory tokens. Additional details like output format or potential side effects are negligible for this simple read 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?
Two concise sentences, front-loaded with the main action, and the exclusion is clearly stated. No redundant 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 description is complete for a simple single-parameter tool. It does not specify the return format, but that is generally expected to be a numeric price. Given no output schema, slight additional detail could help, but not critical.
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 already describes the parameter (factory token address, not STASIS) with 100% coverage. The description reinforces this but adds no new semantic value 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?
The description clearly states the tool gets the USDB floor price for a factory token, and explicitly contrasts with STASIS tokens. This differentiates it from sibling tools like get_price or get_token_price.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states it does NOT work on STASIS, only factory-created tokens, guiding the agent on when to avoid it. However, it does not name alternative tools for STASIS or other price queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get general pot amount for a prediction market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only states the retrieval purpose without mentioning idempotency, authorization requirements, or side effects. The agent gains no insight beyond the obvious.
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 focused sentence with no redundancy. It is concise and front-loaded, though it could be slightly more informative without sacrificing brevity.
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 tool's low complexity (one simple parameter), the minimal description is partially adequate. However, no output schema exists, and the description fails to explain the return value or any constraints, leaving gaps for the agent.
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 0% description coverage for the 'market' parameter. The description does not clarify what 'market' refers to (e.g., ID, address, name), leaving the agent to guess. This is insufficient for correct parameter usage.
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 retrieves a 'general pot amount' for a prediction market, using a specific verb and resource. However, it does not distinguish 'general pot' from similar concepts like 'potential payout' in sibling tools, so it loses a point for lack of differentiation.
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 is provided on when to use this tool versus alternatives (e.g., get_potential_payout, get_market_info). The description lacks context for appropriate invocation or exclusions, making it hard for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get initial reserves for a number of outcomes.
| Name | Required | Description | Default |
|---|---|---|---|
| num_outcomes | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose if the operation is read-only (likely) or any side effects, permissions, or constraints. Minimal transparency beyond the name. Score 2.
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 7-word sentence, very concise. It is front-loaded with verb and object. However, it may be too terse, missing helpful details. Score 4 for efficient structure but slight under-specification.
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 no output schema, the description should hint at return value. It does not. The tool is simple but the description lacks completeness for an agent to fully understand usage. Score 2 for missing details about output and any constraints.
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 0%, and the description adds 'for a number of outcomes' which clarifies that num_outcomes is that number. This adds meaning beyond the schema's bare type definition, but does not specify range, integer vs float, or format. Baseline 3 due to low coverage and partial compensation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the verb 'Get' and resource 'initial reserves' with a specific context 'for a number of outcomes'. It is clear but does not distinguish from other 'get_*' tools or explain what 'initial reserves' are. A score of 4 reflects clear purpose with slight vagueness.
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. The description implicitly suggests it is for retrieving initial reserves, but lacks context, prerequisites, or exclusions. Score 2 for minimal implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get platform leaderboard.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It does not mention that the tool is read-only, whether it requires authentication, or any pagination behavior. The agent learns nothing beyond the name.
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 with no unnecessary words. It is as concise as possible while still communicating the core action.
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 only 2 self-explanatory parameters, the description could be adequate, but it lacks details on pagination defaults, error cases, or the shape of the returned data, which are needed for a complete tool definition.
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?
Both parameters (page, limit) have no descriptions in the schema, and the description adds zero additional meaning. The agent has to infer from parameter names alone, which is insufficient for correct invocation.
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 'Get platform leaderboard' clearly states the action (get) and resource (leaderboard), but it does not specify what the leaderboard ranks (e.g., by volume, profit). It is distinct from siblings like 'get_market_list' or 'get_token_list', but lacks further specificity.
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_market_list' or 'get_token_list'. There are no prerequisites, context, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all leverage positions for the wallet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description implies non-destructive action via 'List', but does not disclose any behavioral traits such as authentication needs, rate limits, or side effects.
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 wasted words. Clearly communicates the tool's purpose.
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 list tool with no parameters, no output schema, and no annotations, the description fully covers what the tool does.
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?
Input schema has zero parameters, so schema description coverage is 100%. Baseline is 4 for zero parameters, and description adds no extra param info which is acceptable.
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 uses specific verb 'List' and resource 'leverage positions', clearly stating the function. It distinguishes from siblings like 'close_leverage' and 'leverage_buy' which involve different actions.
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?
Does not explicitly state when to use this tool or mention alternatives. Usage is implied: to see all positions before taking other actions, but no direct guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get loan event history.
| Name | Required | Description | Default |
|---|---|---|---|
| source | No | ||
| action | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only says 'get', implying read-only, but does not disclose pagination, authentication needs, or potential side effects (though unlikely). The brevity leaves much unknown.
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 very short, which is concise, but at the cost of clarity and completeness. It could be improved by adding parameter context without becoming verbose.
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 optional parameters and no output schema, the description is severely incomplete. It fails to explain the tool's functionality beyond its name, leaving significant gaps for agent decision-making.
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 0%, and the description adds no information about the three parameters (source, action, limit). Their purpose and expected values are entirely unclear, forcing the agent to guess.
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 'Get loan event history' specifies the verb and resource, but is vague among sibling tools like get_loans, get_user_loan_details, and get_vault_events. It does not clarify what constitutes an 'event' or how it differs from other loan-related endpoints.
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 such as get_loans or get_user_loan_details. There is no context about filtering, prerequisites, or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List loans. Monitor expiry — silent auto-liquidation.
| Name | Required | Description | Default |
|---|---|---|---|
| active_only | No | Default: true |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full burden. The phrase 'Monitor expiry — silent auto-liquidation' is ambiguous: it might imply the tool triggers liquidation or merely displays it. There is no clear statement on whether the tool is read-only or has side effects, which is insufficient for a potentially destructive 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?
The description is very short at two sentences, with the main purpose front-loaded. It is concise and free of unnecessary words, though it could be slightly more informative without losing 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?
Given the tool handles loans with potential auto-liquidation, the description lacks essential details such as output format, behavior of the 'active_only' parameter, and whether the monitoring function is passive or active. Without an output schema, more explanation is needed.
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% for the single parameter 'active_only', and the schema description already defines its default. The tool description does not add any additional meaning or usage context for this parameter, so baseline score 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 states the verb 'List' and the resource 'loans', clearly indicating the tool lists loans. However, it does not differentiate from sibling tools like get_user_loan_details or get_vault_loan, and the additional mention of monitoring adds ambiguity. A more precise scope (e.g., all loans vs. user's loans) would improve 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?
The description provides no guidance on when to use this tool versus alternatives like get_user_loan_details or get_loan_events. No context is given about prerequisites, filtering behavior, 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.
Get prediction market event history.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | ||
| market_token | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must convey behavioral traits. It only states 'get', implying a read operation, but does not disclose pagination behavior, data ordering, or what constitutes an event. This is insufficient for an agent to understand side effects or prerequisites.
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 short sentence, which is concise but lacks structure and detail. It does not earn its place as it omits critical 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?
Given no output schema and zero annotation coverage, the description is far from complete. It does not explain what the tool returns, how the parameters affect results, or any constraints, making it inadequate for a tool with three untyped parameters.
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 0%. The three parameters (action, market_token, limit) are not explained in the description or schema. The agent has no context on what values to provide or their purpose, severely hampering correct invocation.
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 'Get prediction market event history' clearly identifies the resource (event history) and the verb (get). It is distinct from other get_* tools like get_market_info or get_market_liquidity, though it could be more specific about the nature of events.
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 is provided on when to use this tool versus alternatives. With many similar get_* siblings, the description should indicate that this tool is for historical event data rather than current state or other market details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get market data + outcome probabilities.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market token address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose any behavioral traits such as read-only nature, potential side effects, or required permissions. For a data retrieval tool, the safe assumption is read-only, but this is not stated.
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 extremely concise at 6 words, but it sacrifices clarity for brevity. It lacks structure and fails to convey important details about the tool's output or context.
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 absence of an output schema, the description should explain what 'market data' and 'outcome probabilities' include. It provides no such detail, leaving the agent to guess the return structure, which is incomplete for effective 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?
Schema coverage is 100% with the parameter description 'Market token address'. The tool description adds no additional meaning beyond what the schema already provides, so it meets the baseline but does not 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 the verb 'get' and the resources 'market data + outcome probabilities', indicating it retrieves combined market information. However, it does not distinguish it from sibling tools like 'get_market_data', which may also return market data, reducing specificity.
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 is provided on when to use this tool versus alternatives such as 'get_market_data' or 'get_market_liquidity'. The agent must infer usage from the name alone, which is insufficient given the many similar tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get liquidity data for a prediction market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| outcome_id | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description does not disclose any behavioral traits (e.g., whether data is static or real-time, pagination, rate limits). The minimal description fails to compensate for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely concise (one sentence). No wasted words, but at the cost of depth. Could benefit from more structure without losing 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?
No output schema and minimal description. Does not explain what liquidity data is returned, data format, or any edge cases. Incomplete for agent 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?
With 0% schema description coverage, the description adds no meaning to the parameters. Parameter names alone (market, outcome_id, limit) are insufficient without explanation of expected format or purpose.
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 action (get) and object (liquidity data for a prediction market), which is specific. However, it does not differentiate from sibling tools like get_market_info or get_market_events.
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 instead of alternatives. No context about prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List prediction markets.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and description does not disclose behavioral traits like read-only nature, pagination, or rate limits. Agent gets no context beyond the name.
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?
Extremely brief (one sentence), but under-specified. Fails to convey essential details while being concise. Every sentence should add value, and this one does not provide enough.
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 zero annotations, the description is entirely inadequate. It does not explain the return format, default behavior, or how to interpret results.
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?
Description provides no information about the parameters (status filter, limit). Schema has 0% description coverage, so the agent has no guidance on how to use the available 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?
Description clearly states the tool lists prediction markets, which is a specific verb and resource. However, it lacks differentiation from sibling tools like get_market_info or get_market_liquidity.
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, such as get_market_info for detailed data or pm_get_market_data for more complex queries.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full resolution pipeline status.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market token address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It does not state that the tool is read-only, mention any side effects, or describe error conditions. This is insufficient for an agent to understand the tool's 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?
The description is extremely concise (five words) but is structured as a noun phrase rather than a complete sentence. While brevity is positive, the lack of a full sentence impairs clarity and makes it read more like a title than a functional description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and no annotations, so the description must provide sufficient context about what the tool returns. Saying 'status' is too vague; the agent cannot infer the specific fields or structure (e.g., state, timestamps, resolution outcomes). This leaves a significant information gap.
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% description coverage for the single parameter 'market', which is described as 'Market token address'. The tool description adds no extra semantic value beyond the schema, so the baseline score of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description 'Full resolution pipeline status.' indicates the tool provides status information about the resolution pipeline for a market. However, it is vague: it does not specify what aspects of the pipeline are included (e.g., final outcome, dispute status), nor does it differentiate from sibling tools like 'get_outcome' or 'get_final_outcome'.
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. No prerequisites, conditions, or exclusions are mentioned. The description is purely declarative, offering no context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get minimum seed amount (USDB) required to create a public prediction market. createMarket reverts below this.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description adds some behavioral context by stating that createMarket reverts below the returned amount. However, it does not disclose other traits such as rate limits, caching, or any side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences pack purpose and behavioral context without waste. Front-loaded with the key action.
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 parameters and no output schema, the description fully covers what the tool does, its return value (seed amount in USDB), and how it relates to createMarket. Complete for the tool's simplicity.
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?
There are no parameters, so the description cannot add parameter-specific details. It does clarify that the output is in USDB, which adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves the minimum seed amount for creating a public prediction market, and distinguishes from private variants by specifying 'public'. It also provides helpful context that createMarket reverts below this amount.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage before creating a market but provides no explicit guidance on when to use this tool versus siblings like pm_get_min_seed_private or pm_get_min_seed_public. No exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check Moltbook link status — linked, verified, post count, karma.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read operation ('check') and lists return items, but fails to disclose any potential side effects, permissions, or rate limits. For a read-only tool, it is minimally adequate.
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 clear, front-loaded content. No wasted 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 zero parameters and no output schema, the description covers the essential purpose and return fields. However, it could specify the output format (e.g., object structure) for better 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?
There are no parameters (0 params, schema coverage 100%). Baseline for no parameters is 4. The description adds no param info but is not required to.
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 checks 'Moltbook link status' and lists specific attributes (linked, verified, post count, karma), making its purpose unambiguous. It is distinct from sibling tools like 'get_verified_moltbook_posts' or 'verify_moltbook'.
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 checking status but provides no guidance on when to use this tool versus alternatives like 'get_verified_moltbook_posts' or 'link_moltbook'. No explicit when-not-to-use or exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Today's cap-fill percentages for the authenticated wallet. Returns { date, resetsInSeconds, pointCaps[4]: trading|prediction|creator|positions, countCaps[2]: social_x|social_moltbook }. Each percent is 0-100. Caps reset at 00:00 UTC.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description mentions the authenticated wallet context and reset time (00:00 UTC), which adds some behavioral context. However, it does not disclose potential side effects, rate limits, or authorization requirements beyond 'authenticated wallet'.
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 three concise sentences without redundancy. It efficiently conveys purpose, output structure, and additional context (percentage range and reset time). No fluff.
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 tool with no parameters and no output schema, the description fully explains the return values and their semantics. It is complete for an agent to understand and invoke correctly.
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 no parameters, so schema coverage is 100% trivially. The description thoroughly explains the output structure, including all fields and their meaning, adding significant value 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?
The description clearly states it returns today's cap-fill percentages for the authenticated wallet, listing specific fields (date, resetsInSeconds, pointCaps with 4 types, countCaps with 2 types) and percentages range. This is specific and distinct from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives. It is a standalone tool for checking daily caps, but no 'use when' or 'don't use when' information is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your order book history. Paginated with optional status/market/outcome filters.
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status (e.g. open, filled, canceled) | |
| market_token | No | Filter to a specific market | |
| outcome_id | No | Narrow to a single outcome (0-indexed) | |
| page | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Mentions pagination and optional filters, but with no annotations, it omits details like data freshness, rate limits, or authentication needs.
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 efficient sentence front-loads purpose, scope, and features with 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?
Lacks details on return format or pagination behavior; with 5 params and no output schema, the description is adequate but not fully 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?
Description echoes schema for 3 documented params but adds no extra context for 'page' and 'limit' beyond 'paginated', leaving 2 params underdocumented.
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 retrieves the user's order book history with pagination and optional filters, distinguishing it from global 'get_orders' sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implies use for personal order history but lacks explicit when-to-use or alternatives compared to siblings like 'get_orders'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your profile — tier, rank, streak.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not explicitly state that this tool is read-only or has no side effects. It only describes the output, leaving the agent to infer behavior from the tool name.
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?
Extremely concise: one sentence listing the key output attributes. No wasted words; front-loaded with purpose.
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 description is adequate for a parameterless tool, but it lacks detail on the full response format or any potential error conditions. Given no output schema, more context about the return value could be helpful.
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?
No parameters exist, so schema coverage is 100%. The description adds value by indicating the specific output fields (tier, rank, streak), which is meaningful beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns the user's profile, specifically tier, rank, and streak. It is a specific verb (get) and resource (profile), and distinguishes from siblings like get_public_profile by focusing on the user's own profile.
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_public_profile. The description does not provide any context for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your created tokens and markets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as authentication requirements, data scoping beyond 'created,' or common nuances like empty results handling.
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 redundant words. It efficiently conveys the tool's purpose.
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 tool with no parameters and no output schema, the description provides the basic purpose but does not explain what the returned data looks like (e.g., list of IDs or full objects), leaving some ambiguity.
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?
With zero parameters, the description does not need to add parameter-level information. The baseline of 4 is appropriate as the schema is fully covered.
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 retrieves 'your created tokens and markets,' which is specific and distinguishes it from other get_my_* tools that retrieve different resources like tokens or orders.
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 is provided on when to use this tool vs alternatives like get_my_tokens or get_market_list. It does not specify 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 your referral data.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as authentication requirements, rate limits, or data freshness. The agent has no insight into side effects or prerequisites.
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, concise and to the point, with 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?
For a simple retrieval tool with no parameters and no output schema, the description is minimally adequate. However, it lacks context about what specific data constitutes 'referral data' (e.g., count, link, history).
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 zero parameters, so schema coverage is 100%. The description adds no parameter semantics, but with no parameters, the baseline is 4.
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 the resource 'referral data', indicating it retrieves the user's own referral data. However, it does not explicitly differentiate from the sibling tool 'get_public_profile_referrals', which likely returns public referral data for others.
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 provides no guidance on when to use this tool versus alternatives or when not to use it. Given the presence of 'get_public_profile_referrals', a note on the distinction would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Your trading stats — trades, tokens created, loans.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose behavioral traits such as authentication requirements, rate limits, caching, or whether data is real-time. For a read operation, basic transparency is missing.
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 'Your trading stats'. No extraneous information. Efficiently conveys purpose.
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?
While no output schema exists, description lists three stat categories but is vague about format, time range, or aggregation. Adequate for a simple stats tool, but could be more informative for agents.
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?
No parameters exist, so schema provides full coverage. Description adds value by specifying what the stats cover (trades, tokens created, loans), compensating for lack of param details.
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 (get), resource (stats), and specific aspects (trades, tokens created, loans). Differentiates from many get_my_* siblings by being an aggregate stats tool.
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 vs alternatives like get_my_orders or get_my_tokens. The name and description imply it's for overall stats, but no guidance on when not to use or what distinguishes it from other personal data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tokens you created with prices and state.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the burden. It states the tool lists user-created tokens with prices and state, but it does not disclose authorization requirements, rate limits, or potential side effects. Basic transparency is provided, but no additional behavioral context beyond what is obvious.
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 concise sentence that is front-loaded with the action and resource, containing 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?
For a simple zero-parameter tool, the description adequately states what is returned (user's tokens with prices and state). However, it could benefit from mentioning ordering or pagination, but given the tool's simplicity, it is mostly 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?
The input schema has zero parameters and 100% coverage. According to guidelines, zero parameters warrant a baseline of 4, and the description adequately describes the output without needing parameter semantics.
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 uses a specific verb 'List' and identifies the resource 'tokens you created', clearly differentiating it from siblings like get_token_list and get_my_shares.
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 or when not to use this tool compared to alternatives like get_token_list or get_my_tokens. Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List vestings where you are beneficiary or creator.
| Name | Required | Description | Default |
|---|---|---|---|
| role | No | Default: beneficiary |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description implies a read-only operation ('List') and adds the filtering by role, but does not disclose pagination, sorting, or output format. With no annotations, the description carries the full burden and 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?
The description is a single concise sentence with no unnecessary words. It front-loads the verb and resource, making it 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?
Despite lacking an output schema and detailed behavior, the description covers the essential purpose and parameter for a simple list tool. It is sufficient for an agent to understand what the tool does and how to use it.
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% coverage with a single parameter 'role' with an enum and a default note. The description adds context by explaining the role filter ('where you are beneficiary or creator'), but this is already implied by the 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?
The description clearly states the verb 'List' and the resource 'vestings' and specifies the scope 'where you are beneficiary or creator', which effectively differentiates this tool from other vesting-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context that the tool is for querying the user's own vestings based on role. It does not explicitly mention when not to use it or compare with alternatives like get_vesting_details, but the role filter gives sufficient guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get cost to fill an order.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| order_id | Yes | ||
| fill_amount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey behavioral traits. It only states it is a 'get' operation, implying read-only, but does not disclose any side effects, permissions, rate limits, or potential errors. The description fails to compensate for the missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence of five words, front-loading the purpose. It avoids unnecessary detail, but given the complexity of the system and the number of parameters, a slightly longer description could improve clarity without harming 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?
With no output schema and minimal description, the agent lacks information about return values, potential errors, and the meaning of inputs. The tool is part of a large set of financial operations; this description does not provide enough context for an agent to determine correct invocation without additional heuristics.
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 three parameters (market, order_id, fill_amount) with no descriptions, and overall schema_description_coverage is 0%. The description adds no explanation of what these parameters mean, their formats, or valid values. The agent must infer semantics from names alone, which is insufficient for correct use.
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 (get) and the resource (cost to fill an order), making the purpose understandable. However, it lacks specificity about what 'cost' entails (e.g., estimated vs. actual), and does not differentiate it from other get_ tools like get_price or get_buy_order_amounts_out, though the unique combination of parameters suggests a distinct function.
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 is provided on when to use this tool versus alternatives, such as get_price or get_buy_order_amounts_out. There is no mention of prerequisites, context, or when not to use it. This forces the agent to rely solely on the tool name and returned data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List orders for a market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| status | No | ||
| outcome_id | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states the basic action, leaving out important details like whether the tool is read-only, returns all orders or only open ones, or has pagination.
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 extremely concise with one sentence, but it sacrifices necessary detail. While not verbose, it fails to convey essential information, earning a middle score.
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 4 parameters, no output schema, and no annotations, the description is incomplete. It does not provide enough context for an agent to use the tool correctly, such as return format or error cases.
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 0% description coverage and the description does not clarify any parameters. 'market' is not explained, and 'status', 'outcome_id', and 'limit' are left ambiguous, so the description adds no value beyond parameter names.
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 lists orders for a market, using a specific verb and resource. However, it does not differentiate from sibling tools like 'get_my_orders' or 'list_order', which could lead to confusion.
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 is provided on when to use this tool versus alternatives. For example, an agent might need to know that 'get_my_orders' should be used for user-specific orders, but the description omits such distinctions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get data for a single prediction market outcome.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| outcome | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral information. It only states 'Get data' without specifying read-only nature, required permissions, side effects, or response characteristics. The description lacks necessary context for safe invocation.
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 very short and front-loaded, which aids quick scanning. However, it is too minimal to be considered optimally concise—it omits necessary detail, making it under-informative rather than efficiently compact.
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 tool has two required parameters and no output schema or annotations, the description is insufficient. It does not explain what data is returned or how the outcome parameter relates to prediction markets. The tool cannot be used confidently without further context.
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 0%, yet the description adds no meaning to the parameters 'market' and 'outcome'. It does not explain their formats, constraints, or expected values. The description fails to compensate for the poor schema coverage.
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 identifies the verb (Get) and resource (data for a single prediction market outcome). It states the tool's purpose without ambiguity. However, it does not differentiate from similar sibling tools like get_final_outcome or get_market_info, which could lead to confusion.
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 is provided on when to use this tool versus alternatives. There is no mention of use cases, prerequisites, or exclusion criteria. The description does not help the agent decide between get_outcome and other sibling get_* tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Platform pulse — phase, stats, currency.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only hints at returning 'pulse' data, but does not mention safety (e.g., read-only), performance, or any side effects.
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?
Extremely concise at 7 words. Information is front-loaded. However, the brevity sacrifices clarity, which slightly reduces the score from a perfect 5.
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 should provide more detail. It tells the general topic but lacks structure or specifics. For a simple read tool, it is barely adequate.
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 tool has zero parameters, and schema description coverage is 100%. The description does not need to explain parameters, so it meets the baseline. No additional meaning required.
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 'Platform pulse — phase, stats, currency' indicates the tool returns platform-related data, but it is vague and does not clearly specify what 'phase', 'stats', or 'currency' refer to. It distinguishes from sibling tools by name, but lacks precise purpose.
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 like get_market_info or get_my_stats. The description provides no context on its role or when it is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Calculate prediction market resolution payout: (yourShares / winningCirculatingShares) × totalPool. Two modes: (1) CURRENT: pass existing shares, usdb=0. (2) BET PREVIEW: pass total shares (existing+new), new_shares_from_bet = new shares from estimate_shares_out, usdb = bet amount.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| outcome | Yes | ||
| shares | Yes | Your total shares (existing for current, existing+new for preview) | |
| new_shares_from_bet | No | New shares from estimate_shares_out. Omit or 0 for current position. | |
| estimated_usdb_to_pool | No | 0 for current. Bet amount for preview. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It explains the calculation but does not disclose if the tool is read-only, required permissions, or potential side effects. The formula is described, but there is no mention of what happens if inputs are invalid or if the tool is idempotent.
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 concise with two sentences. The first sentence front-loads the core purpose and formula. The second sentence, though slightly dense, efficiently explains the two modes. Could be improved by using bullet points for clarity.
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 description covers the formula and modes but lacks mention of the return value. Without an output schema, the agent does not know what the tool returns (e.g., a number, an object). It also assumes prior knowledge of 'estimate_shares_out' without explaining how to obtain it.
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 60%; the description adds meaning beyond the schema by explaining the roles of 'shares', 'new_shares_from_bet', and 'estimated_usdb_to_pool' in the context of the two modes. However, 'market' and 'outcome' are not elaborated 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?
The description clearly states 'Calculate prediction market resolution payout' and provides the exact formula. It distinguishes two modes (CURRENT and BET PREVIEW), which differentiates it from sibling tools like 'get_price' or 'preview_trade'.
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 explains when to use each mode (CURRENT for existing position, BET PREVIEW for estimating potential payout). It references 'estimate_shares_out' as a prerequisite for preview mode. However, it does not explicitly state when NOT to use this tool or list alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current USD price of a token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token name or address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the function. It fails to disclose behavior like error handling for invalid tokens, caching, or whether a network call is required.
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 redundancy, and front-loaded with the core action. Every word serves a purpose.
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 one-parameter tool with no output schema, the description is adequate but lacks behavioral details and fails to differentiate among many sibling price 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 coverage is 100% with one well-described parameter. The description adds 'USD price' context but does not elaborate beyond what the schema already says. Baseline score 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 retrieves the current USD price of a token. However, among sibling tools like get_token_price and get_floor_price, it lacks differentiation on what specific price source or scope it covers.
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 such as get_token_price or get_floor_price. The description does not mention context, prerequisites, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
OHLC candles for a token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| interval | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description is too sparse. It fails to disclose important behavioral traits such as pagination, ordering, or default limit.
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?
Very short (4 words), but lacks necessary detail. It is front-loaded but under-specified.
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 exists, so description should explain return format. It mentions 'OHLC candles' but omits details like number of candles, ordering, or default limit.
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 0%. Description does not explain the meaning of 'token', 'interval', or 'limit' parameters. Only 'interval' has self-explanatory enum values.
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 returns OHLC candles for a token, which is specific. However, it does not differentiate from sibling tools like get_price or get_trade_history.
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 others. Does not mention use cases or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comments on a project.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It does not disclose behavioral traits like pagination (limit parameter), sorting, authentication requirements, or response format. This leaves significant ambiguity for an agent.
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, front-loaded with the core purpose. Every word is functional. However, it could be slightly expanded without losing conciseness, such as noting the optional limit parameter's effect.
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 read tool with no output schema and minimal annotations, the description lacks completeness. An agent would not know what the tool returns (e.g., a list of comment objects or just counts), making it insufficient for effective selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no meaning beyond the parameter names. The 'limit' parameter is not explained (e.g., max comments to return), and 'project_id' is not clarified beyond being required. The description fails to compensate for low schema coverage.
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 'Get comments on a project' clearly states the verb (Get) and resource (comments on a project), distinguishing it from sibling tools like create_project_comment or delete_project_comment.
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 others. The simple read nature implies basic usage, but alternatives are not mentioned. For a straightforward getter, this is acceptable but not helpful for complex decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get public profile for a wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states the purpose; it does not disclose behavioral traits such as being read-only, rate limits, or authentication requirements.
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 waste; perfectly concise for a simple getter tool.
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 exists, yet the description does not hint at what the public profile contains (e.g., fields like name, bio), leaving the agent uninformed about the return value.
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 description mentions 'wallet' but adds no detail on format or constraints beyond the schema; schema coverage is 0%, so the description should compensate but does not.
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 'Get public profile for a wallet' clearly states the action and resource, and distinguishes from sibling tools like 'get_my_profile' by specifying 'public'.
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_my_profile' or other profile-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get referral data for a wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavior fully. It only states the action without mentioning whether the wallet must be public, return format, or side effects. 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?
The description is a single clear sentence, efficient for a simple tool with one parameter.
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 low complexity, the description still omits important context like whether the endpoint is public, what referral data includes, or typical use cases. Incomplete for an ideal agent understanding.
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 0%, yet the description adds no detail about the 'wallet' parameter (e.g., format, constraints, examples). Fails to compensate for missing schema 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 tool gets referral data for a wallet, but it does not differentiate from the sibling tool 'get_my_referrals', which likely serves a similar purpose for the current user.
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_my_referrals' or any context about prerequisites (e.g., authentication).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get reef posts feed.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Feed section (e.g. 'general') | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as pagination, ordering, authentication requirements, or what the feed contains. It is minimal and leaves key behaviors unspecified.
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 is front-loaded with the tool's purpose. It is not overly verbose, but could benefit from additional context without becoming long.
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 no output schema and two parameters, the description lacks completeness. It does not explain what the feed returns, how results are ordered, or any default behavior, leaving significant gaps for the AI agent.
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 50%; the section parameter has a description with an example, but the limit parameter lacks any description. The description adds no meaning beyond the schema for limit, and only an example for section.
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 (Get) and resource (reef posts feed), which is specific. However, it does not differentiate from sibling tools like get_reef_feed_by_wallet, which implies a general feed but lacks explicit scope.
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 (e.g., get_reef_feed_by_wallet vs get_reef_highlights). The description is a single sentence with no usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get reef posts by a specific wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so description should compensate. It only states the function, but does not disclose behavior like whether it returns posts authored by or involving the wallet, or any pagination or ordering details.
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 but lacks necessary detail to be fully informative. It earns its place but could be expanded.
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 or annotations, and the existence of sibling tools, the description is insufficient. Does not explain relationship to get_reef_feed or get_reef_post, nor any constraints.
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 0% and description adds no meaning. Does not explain what 'wallet' represents (author?) or what 'limit' does (max count? pagination?).
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 retrieves reef posts filtered by a specific wallet. The verb 'Get' and resource 'reef posts' are specific, but lacks explicit differentiation from siblings like get_reef_feed.
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 (e.g., get_reef_feed for general feed). No context on prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get highlighted reef posts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but fails to disclose any behavioral traits (e.g., read-only, authentication needs, 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?
Single sentence with no unnecessary words, front-loaded with verb 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?
Adequate for a simple no-parameter getter, but could clarify what 'highlighted' entails to avoid ambiguity.
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 0 parameters (100% coverage), so the description cannot add meaning; baseline 4 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 (get) and resource (highlighted reef posts), but does not differentiate from sibling tools like get_reef_feed or get_reef_post by explaining what 'highlighted' means.
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; no context on prerequisites or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a single reef post with comments.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should compensate but does not. It fails to disclose whether the operation is read-only, requires authentication, or what happens on missing post_id. The phrase 'with comments' is helpful but 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 concise (one sentence, 6 words) and front-loaded, but it omits necessary information, making it under-specified rather than optimally 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?
Despite the tool's simplicity (one parameter, no nested objects), the description lacks completeness. No output schema is provided, and the description does not explain the return structure, error handling, or any prerequisites, leaving significant 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?
The schema has 0% description coverage and the description adds no meaning to the 'post_id' parameter. It does not mention format, origin, or constraints, leaving the agent without guidance beyond the type string.
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 the resource 'a single reef post with comments', making its purpose unambiguous. It distinguishes from sibling tools like get_reef_feed (multiple posts) but does not explicitly differentiate from other single-post getters.
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 is provided on when to use this tool versus alternatives, such as other get_reef_* tools or when a specific post_id is available. The description lacks context for appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get vote data for reef content.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but only says 'Get vote data', implying a read operation. No mention of return format, pagination, or any side effects. Insufficient for an agent to understand 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?
The description is a single sentence, which is concise but too brief to be informative. It front-loads the purpose but omits necessary details.
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 is the only source of context. It fails to describe return data, behavior, or limitations, making it incomplete for an agent to use effectively.
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 0% and the description does not explain the sole parameter 'post_id' beyond what the schema shows (string, required). No added context about what ID format or how it filters data.
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 ('vote data for reef content'), indicating a read operation. However, it does not distinguish from siblings like 'get_vote_count' or 'get_voter_choice', so it's not fully differentiating.
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 such as 'vote_reef_post' or 'get_vote_count'. The agent receives no context about selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get dispute period, proposal period, bond amounts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only indicates a read operation via 'Get' but omits details like rate limits, data freshness, or whether authentication is required. Minimal 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?
The description is a single, front-loaded sentence that efficiently conveys the purpose without extraneous 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 the tool's simplicity (no parameters, no output schema), the description adequately covers what it retrieves. However, it could be improved by noting that return values are static or caching 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?
There are no parameters, so schema coverage is 100%. Per guidelines, a baseline of 4 applies since no parameter documentation is needed.
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 specifies the exact constants retrieved: dispute period, proposal period, bond amounts. This distinguishes it from other get tools that retrieve different data.
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 explains what the tool does but provides no guidance on when to use it versus other get tools (e.g., get_market_info, get_fee_amount). Usage context is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your resolver stake amount.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | Default: your wallet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose behavioral traits. It fails to mention that this is a read-only operation or any side effects. The bare description 'Get your resolver stake amount' provides no 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, front-loaded, but too brief. It lacks helpful context (e.g., return value, read-only nature) that could be added without significant verbosity.
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 exists, but the description does not explain what the tool returns (just 'stake amount' implied). It lacks annotation context (read-only) and does not address edge cases or further details about the stake.
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 one parameter 'wallet' described as 'Default: your wallet'. The description adds no additional meaning 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 'Get your resolver stake amount' uses a specific verb ('Get') and resource ('resolver stake amount'). It clearly indicates the tool returns the stake amount. However, it does not distinguish from sibling 'resolver_stake' which is a different action (staking), so differentiation is implicit via name only.
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 'resolver_stake' or 'get_resolver_constants'. The description does not mention context or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current surge tax for a token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only states it 'gets' data (read), but does not disclose any behavioral traits such as required permissions, rate limits, or behavior for invalid tokens.
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 short sentence, which is concise, but it may be too sparse; it does not fully earn its place given the lack of detail.
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 large number of sibling tools and the absence of an output schema, the description should provide more context (e.g., return value format). It is incomplete for an agent to reliably use it.
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 schema has 0% description coverage for the parameter 'token'. The description does not explain what 'token' refers to (e.g., address, symbol), leaving the agent with no additional semantic meaning beyond the raw type.
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 (get), resource (surge tax), and scope (for a token). This differentiates it from sibling tools like get_base_tax_rates or get_tax_rate.
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_tax_rate, or any prerequisites. The description merely states what it does without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current tax rate for a token+wallet.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| wallet | No | Default: your wallet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits such as read-only status, side effects, rate limits, or authentication requirements. For a read operation, it is reasonable to assume no side effects, but the description fails to confirm this.
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 with no redundancy. It communicates the core purpose efficiently. However, it could be slightly more informative without losing 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?
Given no output schema and low parameter coverage, the description is incomplete. It fails to specify the format of the tax rate (e.g., percentage), the meaning of the wallet parameter (default behavior unclear), or any return value details. For a tool in a complex domain, more context is needed.
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 2 parameters with only 50% description coverage (wallet has a default note, token has none). The description adds no extra meaning beyond the schema; it does not explain what 'token' and 'wallet' represent or how the tax rate is computed. Since coverage is low, the description should compensate but does not.
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 the resource 'current tax rate' with relevant scope 'for a token+wallet'. It distinguishes itself from sibling tools like 'get_base_tax_rates' and 'get_surge_tax' by specifying the combination of token and wallet.
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 provides no guidance on when to use this tool versus alternatives such as 'get_base_tax_rates' or 'get_surge_tax'. It does not mention context, prerequisites, or exclusions, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get comments on a token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose whether this is read-only, authentication needs, or pagination behavior. The description is too minimal to inform the agent about important behavioral aspects.
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 short sentence, which is concise but at the expense of necessary detail. It is front-loaded but insufficient.
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 low complexity, the description lacks details about return values, error cases, or behavior when token is missing. No output schema exists to compensate.
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 0%. The description does not explain the 'token' parameter format or the 'limit' parameter meaning. Without param descriptions, the agent has no clue how to use them correctly.
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 'comments on a token', distinguishing it from other comment tools. However, it could be more specific about what a 'token' refers to.
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_project_comments or get_reef_comments. The description lacks context on prerequisites or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full detail for a single token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavior. It only implies a read operation but doesn't mention auth, rate limits, or any side effects. Missing crucial context for safe use.
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, but it sacrifices valuable information. It could be expanded to include what 'full detail' entails without being verbose.
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?
Without an output schema, the description should describe return values. 'Full detail' is too vague; the agent cannot predict what data it will receive. Incomplete for a single-param 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%, and the description adds no extra meaning beyond the parameter's 'Token address' description. This meets the baseline but does not 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 the verb 'Get' and resource 'full detail for a single token', distinguishing it from list operations. However, 'full detail' is vague and doesn't differentiate from other token detail tools like get_token_state or get_token_price.
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 (e.g., get_token_price, get_token_state). The agent has no basis to choose this over similar get_* functions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List/search tokens. Filter by creator with dev param.
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | ||
| dev | No | Filter by creator wallet address | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It fails to mention important behaviors like pagination, ordering, empty results, or whether it only returns tokens owned by the user. The one-sentence description 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?
Very concise and front-loaded with the verb 'List/search'. However, brevity comes at the cost of completeness; a bit more detail would improve without damaging 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?
Given 3 parameters with low schema coverage, no output schema, and no annotations, the description is too minimal. It does not explain return format, pagination, or scope of the listing. Sibling tools add confusion without differentiation.
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 only 33% (dev param described). The description adds nothing beyond repeating the dev filter. Parameters 'search' and 'limit' are not explained. Much meaning is missing.
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 lists/searches tokens and specifies a filter by creator, which gives a clear verb+resource. However, it does not distinguish from siblings like get_token_detail or get_token_state, which are also about tokens.
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_detail or get_my_tokens. The description implies a general listing but context about scope or comparison to other list tools is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get raw token price (reserve ratio). Different from get_price (USD).
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It correctly identifies the tool as a getter (read operation) but adds no further behavioral context such as data freshness, rate limits, or side effects. The description is adequate 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 extremely concise with two sentences conveying purpose and differentiation. There is no wasted text, and the key action is front-loaded. It perfectly balances brevity and 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?
Given the simplicity of the tool (single parameter, no output schema), the description is mostly complete. It explains the purpose and clarifies the difference from a key sibling. However, it could mention the return type or format (e.g., a number representing the ratio) to be fully self-contained.
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% with the parameter 'token' clearly described as 'Token address'. The description adds the phrase 'reserve ratio' which adds context to the returned value, but provides no additional meaning about the parameter itself. Baseline of 3 is appropriate given high schema coverage.
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 gets 'raw token price (reserve ratio)' and explicitly differentiates it from the sibling tool 'get_price' which returns USD price. This is specific and distinguishes it effectively.
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 provides explicit guidance by stating 'Different from get_price (USD)', indicating when to use this tool (for raw reserve ratio) vs alternatives. However, it does not mention any exclusions or conditions for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get token state — frozen, bonded, supply, price.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token name or address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description carries full burden. It only states what is returned, not any behavioral traits (e.g., read-only, rate limits, authentication needs). It adds minimal transparency beyond the tool's name.
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 without redundancy, efficiently conveying the tool's purpose. However, it could be slightly improved by front-loading key information without increasing length.
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 mentions four aspects of token state but does not specify the output format or other possible fields. It is adequate for a simple tool but could be more complete, especially among many 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 coverage is 100% with parameter description 'Token name or address'. The tool description does not add extra meaning for the parameter, so it meets baseline but does not 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 the verb 'get' and resource 'token state', enumerating specific aspects (frozen, bonded, supply, price). It effectively distinguishes itself from sibling tools like get_token_detail and get_token_price by focusing on a specific subset of token state.
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, nor any mention of when not to use it. Given the large number of sibling tools, the description misses an opportunity to direct the agent to the appropriate tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get vesting schedule IDs for a token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not state whether this operation is read-only, idempotent, or requires any permissions. Although a 'get' operation is implicitly safe, the description should explicitly mention it, especially given the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core purpose. It is appropriately sized for a simple tool, but could be slightly more descriptive without losing 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?
Given the lack of output schema and the tool's simplicity, the description does not fully prepare the agent for using the tool. It fails to describe the return format (e.g., list of string IDs) or any constraints (e.g., whether the token must exist). The context of many sibling tools also demands better differentiation.
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 0% description coverage for its only parameter ('token'), and the description does not add any meaning beyond the schema. It does not specify what 'token' refers to (e.g., address, symbol, ID) or provide format expectations. This leaves the agent with no additional guidance.
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 ('Get') and the resource ('vesting schedule IDs for a token'), distinguishing it from siblings like get_vesting_details (which gets details for a specific vesting) and get_vesting_count (which gets a count). It is specific enough to inform the tool's purpose.
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 provides no guidance on when to use this tool versus alternatives. With many similar get_* tools for vesting (e.g., get_vesting_count, get_vesting_details), an agent would benefit from hints like 'Use this to get a list of all vesting schedule IDs for a token, before calling get_vesting_details for specific ones.' No such context is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get total assets in the staking vault.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits like whether the call is a simple read, if it requires authorization, or if it returns cached data. The current description only mentions 'Get total assets', which does not add transparency beyond the name.
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 immediately conveys the tool's purpose. There is no redundancy or unnecessary information, making it highly 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?
Despite having no parameters and a simple function, the description lacks details on the return value format or scope (e.g., whether it's for the caller's vault or a global total). Without an output schema, this missing context could lead to confusion.
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 zero parameters and 100% coverage, so there is no need for additional parameter description. As per guidelines, baseline is 4 for 0-parameter tools.
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 the resource 'total assets in the staking vault', distinguishing it from siblings like 'get_vault_status' or 'get_vault_events'. It leaves no ambiguity about what the tool returns.
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 is provided on when to use this tool versus alternatives such as 'get_vault_status' or 'get_vault_events'. The context of staking vault is implied but not explicitly stated, and there are no notes 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.
Recent trades for a token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| type | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. It only states it returns 'recent trades,' but omits whether it is read-only, authentication needs, rate limits, or output format. The description adds minimal behavioral context beyond the function name.
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, too brief to be informative. While concise, it sacrifices critical details that an agent needs, such as parameter explanations and output structure.
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 annotations, no output schema, and only three parameters (one required), the description fails to provide sufficient context for correct usage. It does not describe the return format, pagination, or any constraints, leaving the agent underinformed.
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 0%, and the description does not explain any of the three parameters (token, type, limit). The agent must rely solely on the schema, which lacks descriptions. No value is added for parameter 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 'Recent trades for a token' clearly indicates the tool retrieves trade data for a specific token. It distinguishes from sibling tools like get_orders or get_price_history, but lacks specificity on what constitutes 'recent' and does not differentiate from similar trade-related tools like preview_trade.
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 is provided on when to use this tool versus alternatives such as preview_trade, get_order_history, or other trade-related functions. The description offers no context for appropriate invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count of loans for the wallet.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It does not specify what 'wallet' means (user's own or arbitrary), whether it counts active/overdue/all loans, or the return type. Lacks essential 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?
A single, unambiguous sentence. Extremely concise and front-loaded with 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 parameters, the description does not explain the return value format, edge cases (e.g., no loans), or which wallet is referenced. Given the complexity of the tool's context (multiple loan-related siblings), this is insufficient for reliable agent selection.
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?
Input schema has 0 parameters, so the description does not need to add parametric detail. According to rules, baseline is 4. No additional semantics required.
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 states 'Count of loans for the wallet', which indicates the tool returns a numerical count. The verb 'get' in the name and resource 'loan count' make the purpose reasonably clear, but the phrase is a noun phrase rather than an imperative, which 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 versus siblings like 'get_loans' or 'get_user_loan_details'. No context about prerequisites, applicable wallets, or alternative tools is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get on-chain details for a specific loan.
| Name | Required | Description | Default |
|---|---|---|---|
| hub_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure. It only states 'Get on-chain details' implying read-only, but lacks specifics on return format, data freshness, or any side effects. Minimal value added.
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 extremely concise (7 words) but at the cost of omitting essential parameter context. It is not verbose, but the brevity hinders usability.
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 tool has one required parameter and no output schema, the description should at least clarify the parameter and the scope of 'details'. It fails to do so, leaving the agent with insufficient information to invoke the tool correctly.
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 sole parameter 'hub_id' is a number with no description. Schema description coverage is 0%, and the description adds no explanation of what hub_id represents (e.g., loan identifier, user ID). The agent cannot infer how to populate it correctly.
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 'Get on-chain details for a specific loan' clearly states the verb (get) and resource (loan details). It is direct and unambiguous, though it does not differentiate from similar loan-related tools like 'get_loan_events' or 'get_vault_loan'.
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 is provided on when to use this tool versus the many sibling loan tools (e.g., 'get_loans', 'get_loan_events', 'get_vault_loan'). The description gives no context about prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get vault staking event history.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It simply states 'Get vault staking event history' without disclosing behavioral traits such as whether it is read-only, what events are included, ordering, or pagination (despite a limit parameter). The lack of detail makes it hard for an agent to anticipate 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?
The description is extremely concise (5 words), but conciseness comes at the cost of adequacy. It lacks structure and necessary details. While it is front-loaded, it is under-specified for a tool with two parameters and many siblings.
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, no annotations, and many sibling tools, the description provides insufficient context. It does not explain return values, parameter usage, or when to choose this tool over alternatives. The description is far from 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 0%, meaning the description must explain parameters. It fails to mention either 'action' or 'limit' or provide any context for their values. The agent has no guidance on how to set these 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 states 'Get vault staking event history,' providing a clear verb and resource. However, it lacks specificity on what constitutes a vault staking event and does not differentiate from other event-fetching tools like get_loan_events or get_vesting_events. It is not a tautology but could be more precise.
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 usage guidance is provided. The description does not indicate when to use this tool versus similar event-listing tools. Siblings like get_loan_events, get_market_events, and get_vesting_events exist, yet no differentiation is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get full loan details for an active vault loan. Handles the vault-as-borrower indirection automatically. Returns null if no active vault loan.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | User wallet address (default: your wallet) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses key behaviors: automatic indirection handling and null return for inactive loans. Although it doesn't explicitly state read-only nature, the verb 'Get' implies non-destructive behavior, and no contradictions exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, fully front-loaded. Every word serves a purpose: action, special handling, and edge-case return. No waste.
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 getter with one optional parameter and no output schema, the description covers essential behavioral aspects (indirection, null return). It lacks output structure details, but given the tool's simplicity and sibling context, this is acceptable.
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 the 'wallet' parameter with default behavior. The description adds no additional meaning beyond schema, meeting baseline. No extra detail is needed.
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: 'Get full loan details for an active vault loan.' It distinguishes itself from siblings by specifying 'vault loan' and mentioning automatic indirection handling. The return behavior (null if none) is explicit.
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 provides clear usage context: handles vault-as-borrower indirection and returns null when no active loan exists. While it doesn't explicitly compare to sibling tools, the purpose is specific enough for an agent to decide when to use this tool over others like get_loans or get_user_loan_details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Complete vault position status.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as read-only nature, authentication requirements, or side effects. The word 'Complete' is ambiguous regarding what is returned. The description adds minimal transparency beyond the tool name.
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 extremely concise (3 words) and front-loaded with the key information. However, the term 'Complete' could be clarified. It earns its place but could be slightly more informative without much overhead.
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 leaves out what 'vault position status' includes. For a tool with no parameters, users still need to understand the format or scope of the returned data. The description is insufficient to fully understand the tool's output or behavior in the context of sibling vault 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?
The tool has no parameters, and the schema coverage is 100% (trivially). The description provides no parameter information, which is acceptable since no parameters exist. Baseline score of 3 applies because the schema already fully covers the (non-existent) 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 'Complete vault position status' clearly indicates the tool retrieves a full snapshot of vault position data. The verb 'get' is implied by the name, and the resource is specified. Among many vault siblings, it is distinct from other specific vault queries like get_total_vault_assets, though no explicit differentiation is provided.
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 is given on when to use this tool versus alternatives like get_total_vault_assets or get_vault_events. The description does not state context, prerequisites, or exclusions for usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all your verified Moltbook posts.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits beyond the basic function. Since no annotations exist, the description carries the full burden but fails to mention that it is read-only, whether it requires prior verification, or any other constraints.
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 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?
For a tool with no parameters and no output schema, the description is complete. It clearly states what the tool does (list verified Moltbook posts) with no missing information given the simplicity.
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?
There are zero parameters, so the baseline is 4. The description does not need to add parameter information, and the schema is already fully covered (100% coverage).
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 uses a specific verb ('List') and resource ('your verified Moltbook posts'), clearly distinguishing it from siblings like get_verified_tweets or get_moltbook_status. It precisely indicates the tool's function and scope.
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 is provided on when to use this tool versus alternatives. Siblings like get_moltbook_status or verify_moltbook_post exist, but there is no comparative context to help the agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your verified tweets.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits, such as authentication requirements, return format, or side effects.
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?
Extremely concise at one sentence, but lacks informative details; could be improved without adding bulk.
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 description is too minimal given no parameters, no output schema, and no annotations; it fails to provide sufficient context for a complex tool ecosystem.
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?
No parameters exist, so the baseline is 4; the description adds no additional meaning but the schema is already complete.
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 and resource (get verified tweets), but it does not specify what 'verified' means or differentiate from similar tools like get_verified_moltbook_posts.
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; given many sibling tools, the description provides no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total vesting schedules created.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states what the tool does without disclosing any behavioral traits. For example, it does not indicate whether the count is global or filtered, whether it requires authentication, or if it is a read-only operation. The description adds minimal 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?
The description is a single, concise sentence with no unnecessary words. It is front-loaded and directly conveys the tool's purpose.
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 simplicity of the tool (no parameters, no output schema), the description is reasonable but could be more complete. It does not specify the return format (e.g., integer) or any filtering scope. For a minimal tool, this 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?
The tool has zero parameters, and the input schema is fully covered with no properties. The description implicitly adds meaning by specifying that the count is for 'vesting schedules created,' which provides context beyond the empty schema. Per rubric, baseline for 0 params is 4.
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 'Total vesting schedules created' clearly states the tool returns a count of vesting schedules. It uses a specific verb and resource, and distinguishes itself from other get_vesting_* tools that return details or lists.
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 implicitly suggests using this tool to get a count of vesting schedules, but gives no explicit guidance on when to use it versus alternatives, such as get_vesting_details or get_vesting_events. There is no mention of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a vesting schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| vesting_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal disclosure. No annotations provided, and the description only says 'Get details' without explaining return values, side effects, or authentication needs.
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 fluff. However, it may be too terse for full utility, but it earns its place.
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, no annotations, and one parameter, the description fails to provide enough context for correct agent 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 coverage is 0%, and the description does not clarify what vesting_id represents or how to obtain it. The parameter is documented only by name and type in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves details for a vesting schedule, using a specific verb and resource. However, it does not distinguish from sibling tools like get_vesting_details_batch or get_my_vestings.
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. It lacks context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for multiple vestings at once.
| Name | Required | Description | Default |
|---|---|---|---|
| vesting_ids | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states it 'gets details' without indicating read-only nature, potential response size, performance impact for large batches, or any other behavioral traits.
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 extremely concise (6 words) and front-loaded. However, it may be too terse for a tool with no other documentation. It earns its place but could benefit from slight expansion without losing 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?
Given the low schema coverage, no annotations, no output schema, and 1 parameter, the description is incomplete. It fails to specify what 'details' are returned, whether an empty array is valid, or any error conditions.
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 0%, so the description should explain the parameter meaning. The parameter name 'vesting_ids' is somewhat self-explanatory, but the description adds no additional context about the expected format, size limits, or required permissions.
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 retrieves details for multiple vestings, distinguishing it from single-vesting getters like get_vesting_details. However, it could be more explicit about the scope and how it differs from similar sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., get_vesting_details for a single vesting). The description lacks any context about prerequisites, limitations, or best practices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List vesting events from API.
| Name | Required | Description | Default |
|---|---|---|---|
| action | No | ||
| vesting_id | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavior. It only states 'list' which suggests a read operation, but does not explicitly confirm read-only, nor does it mention side effects, permissions, pagination, 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?
At four words, the description is extremely concise, but this comes at the cost of essential information. It is not verbose, but it is not efficient either—it sacrifices completeness for brevity.
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 absence of annotations, output schema, and parameter documentation, the description is critically incomplete. The agent has no way to understand return structure, event types, or how parameters filter results, making this tool nearly unusable from the definition alone.
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 0%; the description adds no meaning for the three parameters (action, vesting_id, limit). Without any parameter details, the agent cannot infer valid values or usage, severely hampering correct invocation.
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 states verb 'list' and resource 'vesting events', indicating the tool's core function. However, it does not distinguish from sibling tools like get_vesting_details or get_vesting_count, lacking specificity on scope or event types.
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 provided on when to use this tool versus alternatives. The description fails to mention context, prerequisites, or exclusions, leaving the agent without decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get vote count for an outcome in a dispute round.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| round | Yes | ||
| outcome | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose behavioral traits like read-only nature or side effects. With no annotations, the description should carry this burden but fails to add any 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?
The description is a single, front-loaded sentence with no unnecessary words. It is concise, though potentially too brief given the complexity of the tool.
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 description fails to provide sufficient context for correct usage: no return value description, no parameter clarification, and no relation to dispute rounds beyond the name. Incomplete for a tool with 3 required parameters and no output schema.
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 0% description coverage, and the description adds no meaning to the parameters 'market', 'round', or 'outcome'. It does not explain what each parameter represents.
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 ('Get') and the resource ('vote count for an outcome in a dispute round'), distinguishing it from sibling tools like 'get_voter_choice' or 'vote_on_dispute'.
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 (e.g., 'get_voter_choice', 'get_final_outcome'). Missing context about 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.
Get what a voter chose in a dispute round.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| round | Yes | ||
| voter | No | Default: your wallet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It only indicates a read operation without specifying side effects, authentication requirements, or what happens if the voter hasn't voted. This is insufficient for a complete behavioral profile.
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 with no extraneous words. It is front-loaded and efficient, though it could benefit from a bit more structure to include parameter details.
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 annotations and output schema, the description should provide more context. It does not explain the return value format, default values, or potential errors. For a simple tool, it is missing key details.
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 description adds no information about the three parameters. Only the 'voter' parameter has a schema description, while 'market' and 'round' are undocumented. With 33% schema coverage, the description fails to compensate, leaving parameter meaning unclear.
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 retrieves the choice of a voter in a dispute round. It uses a specific verb and resource. However, it does not differentiate from sibling tools like get_vote_count or get_outcome, but the context of 'dispute round' adds specificity.
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 is provided on when to use this tool versus alternatives such as vote_on_dispute or get_vote_count. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
View whitelist for a frozen token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| wallet | No | Filter by wallet | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description uses 'View' which suggests a read-only operation, but it does not confirm non-modification or disclose any behavioral traits like required permissions or actions upon missing parameters.
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 extremely concise with a single sentence, but it lacks necessary detail for a complete understanding. Conciseness is good but does not compensate for missing 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?
For a view tool with no output schema, the description should explain what is returned (e.g., list of wallets). It is too minimal given the complexity of the parameter set and the absence of 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 low (33%) as only 'wallet' has a description. The tool description does not explain the meaning of 'token' (e.g., address vs. symbol) or 'limit', leaving ambiguity 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?
The description clearly states 'View whitelist for a frozen token,' specifying the verb (view), resource (whitelist), and context (frozen token). It distinguishes from sibling tools like whitelist_wallets which manage the whitelist.
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 such as pm_manage_whitelist or whitelist_wallets. The description implies it's for viewing only but does not clarify scenarios or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if you have bet on a prediction market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully convey behavioral traits. It does not disclose whether the tool is read-only, what it returns (e.g., boolean), or any side effects. The minimal description fails to compensate for the missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, which is concise and front-loaded. It could be slightly expanded with essential details without becoming verbose, but overall it is 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?
Given the lack of output schema and annotations, the description is too brief to be complete. An agent needs to know the return type (e.g., boolean) and how to interpret the result. The minimal description does not provide sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one parameter 'market' with 0% description coverage. The description does not add any meaning about what 'market' expects (e.g., ID, address, or other format). The burden falls entirely on the description to explain the parameter, but it is absent.
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 'Check' and the resource 'if you have bet on a prediction market', which is specific and distinguishes it from general getter tools. However, it could be more precise about what constitutes 'bet on' (e.g., any outstanding bet) and how it differs from similar tools like 'get_my_shares' or 'pm_get_user_shares'.
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. With many sibling tools for checking bets or shares, the description does not provide any context about preferred usage or when to choose this over others like 'pm_get_user_shares' or 'get_my_orders'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add collateral without new origination fee.
| Name | Required | Description | Default |
|---|---|---|---|
| loan_type | Yes | ||
| hub_id | No | ||
| amount | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The only behavioral trait disclosed is the absence of an origination fee. No mention of state mutations, error conditions, or side effects. With no annotations, 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 short sentence, achieving conciseness but at the cost of missing critical information. It is front-loaded but under-specified.
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 complexity of loan operations and numerous sibling tools, the description is too brief. It lacks output schema and does not explain the overall effect (e.g., collateral addition impact on loan status).
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 description provides no explanation of the three parameters (loan_type, hub_id, amount). Schema coverage is 0%, so agents must infer meaning from names alone, risking misuse.
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 (add collateral) and a key benefit (no new origination fee). However, it does not explicitly mention that this applies to an existing loan, though the name implies it.
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 take_loan or extend_loan. The description lacks context for when this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a wallet is registered as an agent.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | Wallet to check (default: yours) |
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 does not disclose whether the operation is read-only, requires authentication, or what the return value looks like (e.g., boolean). Minimal 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?
The description is a single sentence, very concise. No fluff, but could be slightly expanded without losing 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 simple check tool with no output schema, the description omits return value details (e.g., returns boolean). The tool is incomplete for an agent to confidently invoke and handle the response.
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%, and the parameter 'wallet' has a clear description in the schema. The tool description adds no additional semantic value 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?
The description states a specific verb 'Check' and resource 'if a wallet is registered as an agent', clearly differentiating it from sibling tools like 'register_agent' or 'list_agents'.
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 vs alternatives (e.g., 'lookup_agent', 'get_agent_wallet'). Usage is implied but not clarified.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if a token address is a valid Basis ecosystem token.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose the return type (likely boolean), authentication requirements, or any side effects. It only states the checking behavior without further detail.
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 of 9 words, front-loading the key information without any filler. Every word earns its place.
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 tool's simplicity (one parameter, no output schema), the description is adequate but lacks mention of return value or behavior details. It is sufficient 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?
The schema has 100% parameter coverage with a basic description ('Token address'). The tool description adds no additional semantics beyond that, so 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?
The description clearly states the action (check) and the subject (if a token address is a valid Basis ecosystem token). It is specific and distinguishes itself from sibling tools like get_token_detail or get_token_list.
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 for verifying ecosystem token validity but does not provide explicit guidance on when to use it versus alternatives, nor does it mention 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.
Check if a wallet is an eligible resolver voter.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | No | Default: your wallet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only check, but lacks explicit disclosure of side effects, permissions, or rate limits. Given no annotations, the description carries the burden, yet it 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, no waste, highly concise with clear meaning.
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 check function with one optional parameter and no output schema, the description is adequate. It missing explanation of 'eligible resolver voter' but is acceptable.
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 schema has 100% coverage for the single parameter. The description adds 'Default: your wallet', providing practical context 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?
The description clearly states the verb 'check' and the specific resource 'wallet eligibility as resolver voter', distinguishing it from sibling tools like 'is_agent_registered' or 'is_ecosystem_token'.
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, nor any conditions or prerequisites. The description merely states the function without context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open leveraged position. NO price liquidation — time-based only. Simulates first, requires confirm=true.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token name or address | |
| amount_usdb | Yes | USDB collateral | |
| days | Yes | Loan duration (10-1000) | |
| confirm | Yes | Must be true to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses no price liquidation (time-based only), simulation first, and confirm=true requirement. This adds significant behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences, front-loaded with the main action. Every sentence adds value with 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?
For a leveraged position tool with no output schema and no annotations, the description covers core functionality, simulation, and confirmation. Could mention fees or execution details, but overall adequate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description does not add additional meaning to parameters beyond what the schema already provides. It only restates that confirm must be true.
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 opens a leveraged position. It specifies key features: no price liquidation, time-based only, simulation, and confirmation requirement. This distinguishes it from related tools like close_leverage.
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 for opening a leveraged position but does not explicitly guide when to use this tool versus alternatives like close_leverage or extend_loan. No when-not-to-use or prerequisites provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start linking your Moltbook account. Returns a challenge to post.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | Your agent name on Moltbook |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description alone must disclose behavior. It mentions returning a challenge but does not indicate whether the tool mutates state, requires authentication, or has side effects.
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 very short and to the point. However, it may be too brief, lacking sufficient detail for an agent to understand the full context. No wasted words, but could be more informative.
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?
Without an output schema or annotations, the description should explain the linking flow more thoroughly. It does not describe what the challenge is for or how to proceed, leaving significant 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 fully documents the parameter. The description adds no additional meaning beyond the parameter name, resulting in a baseline score.
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 initiates linking a Moltbook account and returns a challenge. However, it does not differentiate from sibling tools like 'verify_moltbook' that may be subsequent steps.
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. The phrase 'Start linking' implies it is the first step, but no explicit context or exclusion of other linking-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List registered AI agents.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavioral traits. It merely states 'list', implying a read operation, but does not specify pagination behavior, rate limits, or any potential side effects. The description fails to add meaningful behavioral context beyond the verb itself.
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. However, it lacks structure—no headings, examples, or key information front-loaded. While brevity is valued, it sacrifices completeness.
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 provide enough context for correct invocation. It omits details like return format, pagination limits, and whether the list is comprehensive. The description is insufficient for an agent to use the tool confidently.
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 includes two parameters (page, limit) but has 0% description coverage. The tool description does not mention these parameters or their semantics. An agent cannot infer how to use pagination from the description alone, which is critical for a list tool.
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 'List registered AI agents' clearly states a verb ('List') and a resource ('registered AI agents'), making the purpose understandable. However, it does not differentiate from sibling tools like 'lookup_agent' or 'get_agent_uri', which could cause confusion about which tool to use for listing vs. retrieving details.
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 is provided on when to use this tool versus alternatives. There is no mention of pagination, filters, or any context about when listing is appropriate compared to other agent-related tools. The description lacks any usage directives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place limit sell order on prediction market outcome. This is the ONLY way to sell prediction market shares — there is no AMM sell, only order book.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market token address | |
| outcome | Yes | Outcome index | |
| amount | Yes | Shares to sell | |
| price_per_share | Yes | Price per share in USDB |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states it is a 'limit sell order', implying execution only at specified price, but does not elaborate on order lifecycle, partial fills, or failure conditions. Some behavioral context is added, but not comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The first sentence states the action, the second provides critical context. Efficient and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, so the agent has no idea what the tool returns. The description does not mention return values, side effects, prerequisites (e.g., holding shares), or error conditions. This is a significant gap for a 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 all parameter descriptions present. The description adds minimal extra meaning beyond the schema, only clarifying the 'limit' nature which relates to price. Since schema already documents parameters well, rating is baseline 3.
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 places a limit sell order on a prediction market outcome, using specific verb+resource. It distinguishes itself from any AMM sell by declaring there is no AMM sell, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'This is the ONLY way to sell prediction market shares', giving clear context for when to use. However, it does not list explicit alternatives or when-not-to-use scenarios, though the exclusivity implies its singular role.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Lookup an agent by wallet address.
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden for behavioral disclosure. It states a lookup action but fails to mention whether it is read-only, what it returns, error handling, or any side effects. The minimal statement provides only the core action, not enough 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 of 6 words, efficiently conveying the core purpose. It is front-loaded with the verb and noun, ideal for quick comprehension.
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 tool's simplicity (one parameter, no output schema, no annotations), the description is too minimal. It does not specify what the tool returns (e.g., agent metadata, ID, or details), making it incomplete for an agent to decide if it is the correct tool among many similar getter siblings.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage on parameters. The description adds only that the lookup is 'by wallet address', which is already implied by the parameter name 'wallet'. This adds little 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?
The description uses a specific verb 'Lookup' and resource 'agent', clearly indicating the action and target. It distinguishes itself from siblings like 'get_agent_wallet' by specifying 'by wallet address' as the lookup method, making the purpose unambiguous.
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 is provided on when to use this tool over alternatives such as 'get_agent_metadata' or 'get_agent_id_from_tx'. The agent must infer usage solely from the tool name and description, lacking explicit when/not or alternative suggestions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Partially sell hub loan collateral. 10% increments.
| Name | Required | Description | Default |
|---|---|---|---|
| hub_id | Yes | ||
| percentage | Yes | 10-100, divisible by 10 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description bears full burden. It does not disclose side effects, authentication needs, or impact on the loan (e.g., whether the loan remains active). Minimal 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?
Two short sentences, front-loaded with the action and key constraint. Every word earns its place with no 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?
The tool has only 2 parameters and no output schema, but missing behavioral context (e.g., prerequisites, side effects) leaves the agent underinformed, especially 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?
Input schema covers 50% of parameters with descriptions (percentage has a description, hub_id does not). Description reiterates the 10% increment constraint but adds no new insight into hub_id or parameter formatting.
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 action ('partially sell') and resource ('hub loan collateral'), with a specific constraint ('10% increments'). This distinguishes it from sibling tools like 'sell_token' or 'repay_loan'.
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 (e.g., full sale, repayment). The description implies it's for partial sales but does not mention prerequisites or scenarios where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy shares in a private market outcome.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| outcome | Yes | ||
| amount_usdb | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the action with no disclosure about side effects, transaction requirements, or operational constraints like market availability or fee structures.
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?
Extremely short phrase, but under-specified. It is not a full sentence and lacks critical details; brevity here sacrifices usefulness.
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 three required parameters and no output schema, the description fails to provide essential context such as what constitutes a market identifier, how outcomes are numbered, or the currency unit for amount_usdb. The tool is part of a complex private market system, and the description is grossly 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?
The input schema has 0% description coverage, and the description adds no explanation for any of the three required parameters (market, outcome, amount_usdb). The agent gets no context about their format, allowed values, or units.
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 the action (buy), resource (shares), and context (private market outcome). Distinguishes from generic buy tools, but does not explicitly differentiate from similar sibling tools like pm_buy_order or pm_buy_multiple_orders.
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 prerequisites, typical usage scenarios, or provide any hints about 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.
Sweep multiple private market orders.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| order_ids | Yes | ||
| amount_usdb | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description does not disclose side effects, permissions required, or what 'sweeping' entails (e.g., batch execution, cancellation, or aggregation). The behavioral profile is unclear.
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?
Extremely short at four words, which is concise but at the expense of informativeness. It does not front-load key details.
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 annotations, no output schema, and three required parameters, the description is severely lacking. It fails to explain return values, error handling, or how the tool interacts with the market.
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 0%. Description adds no meaning to parameters 'market', 'order_ids', or 'amount_usdb'. Agent must infer their purpose from names alone.
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 uses verb 'sweep' implying execution of multiple orders, and 'private market orders' distinguishes from public market tools like 'buy_multiple_orders'. However, it does not explicitly differentiate from siblings like 'pm_buy' or 'pm_buy_order'.
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 such as 'pm_buy_order', 'pm_buy', or 'buy_multiple_orders'. Agent has no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill a private market order.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| order_id | Yes | ||
| amount_usdb | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'fill' without mentioning side effects, permissions, or state changes. The agent lacks information on whether this is a mutation or read operation.
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, short sentence. While concise, it is under-specified and lacks necessary detail, reducing usefulness. Conciseness should not come at the cost of clarity.
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 three required parameters, no output schema, and no behavioral hints, the description is severely incomplete. It does not explain the result of 'fill', order lifecycle, or error conditions.
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 0% (no parameter descriptions in schema). The description adds no meaning to the three required parameters (market, order_id, amount_usdb). It fails to explain what each parameter represents or how they are used.
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 'Fill a private market order' states a verb and resource, distinguishing privacy from public orders via the term 'private'. However, it does not differentiate from sibling tools like 'pm_buy' or 'pm_buy_multiple_orders', lacking specificity in scope.
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 (e.g., public 'buy_order' or other pm_ variants). No context about prerequisites or conditions for private market orders.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy from private market order book + AMM in one transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| outcome | Yes | ||
| order_ids | Yes | ||
| amount_usdb | Yes | ||
| min_shares | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only says 'in one transaction' but does not explain side effects (e.g., order consumption, AMM interaction), required permissions, failure modes, or atomicity. For a mutation tool, this minimal disclosure 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, concise but lacking structure. It conveys the core action efficiently but omits necessary details. It is not overly verbose, but the brevity hurts clarity given the tool's complexity.
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 5 parameters, no output schema, many sibling tools, and no annotations, the description is severely lacking. It does not explain what 'buy from order book + AMM' entails, how the parameters are used, or what distinguishes this tool from similar ones. The description is far from complete for correct agent 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?
The input schema has 5 parameters with 0% description coverage. The tool description adds no explanation of parameter meanings or usage. Without any parameter context, the agent cannot correctly invoke the tool.
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's action: buying from private market order book and AMM in one transaction. It uses a specific verb and resource, and the phrase 'in one transaction' hints at a combined operation, distinguishing it from sibling tools like pm_buy_order or pm_buy_multiple_orders. However, it does not explicitly name alternatives or differentiate further.
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 is provided on when to use this tool versus alternatives (e.g., pm_buy_order, pm_buy_multiple_orders). There are no prerequisites, constraints, or exclusions mentioned. Given the large number of sibling buy-related tools, this is a significant omission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cancel private market order.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| order_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must disclose behavioral traits. It only says 'cancel', which implies mutation, but lacks details on side effects, authorization, or success/failure 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?
Extremely concise (4 words), no wasted text. Front-loaded with verb 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 no output schema, no annotations, and 0% schema description coverage, the description is severely incomplete. It lacks details on return values, errors, and usage context.
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 0%. The description does not explain what 'market' or 'order_id' represent or any constraints. No additional meaning added 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?
The description states the action ('Cancel') and resource ('private market order') clearly. It implies a distinction from the sibling 'cancel_order' tool, but does not explicitly differentiate.
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 'cancel_order'. No context about prerequisites or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check if you can buy on private market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description doesn't disclose that this is likely a read-only check, nor what criteria determine eligibility. Minimal 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 short sentence, no unnecessary words. Front-loaded but may be too terse for full clarity.
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?
Though simple, the description lacks important details like return value type (boolean), what conditions affect the check, and any prerequisites. Not complete for effective 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?
Schema coverage is 0%. Description does not explain the 'market' parameter's meaning, format, or restrictions beyond being required.
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 checks eligibility to buy on the private market, distinguishing it from other pm_* buy tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives like pm_buy or other checks. Lacks context about it being a precondition check.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim private market bounty.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must disclose behavioral traits. It only says 'claim', implying a write operation, but omits details like authorization needs, side effects, or return 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?
Extremely concise at 4 words, but this brevity sacrifices informativeness. The description is under-specified rather than efficiently conveying necessary details.
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 simplicity of the tool (1 param, no output schema), the description should be more complete. It fails to explain the purpose, parameter meaning, or outcome, making it insufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter 'market' with no description (0% schema coverage). The tool description does not explain what 'market' refers to (e.g., ID, name), leaving the agent without sufficient context.
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 'Claim private market bounty' clearly states the verb and resource, and the 'pm_' prefix distinguishes it from the sibling 'claim_bounty' tool, indicating public vs private markets. However, it lacks detail on what claiming entails.
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 is provided on when to use this tool versus alternatives like 'claim_bounty', or any prerequisites. The description does not mention when not to use it or provide 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.
Create a private prediction market with metadata. Provide image_url OR image_file_path.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| symbol | Yes | ||
| outcomes | Yes | ||
| end_time | Yes | ||
| private_event | No | Default: true | |
| frozen | No | ||
| seed_usdb | No | ||
| description | No | ||
| image_url | No | ||
| image_file_path | No | Local image file path (alternative to image_url) | |
| website | No | ||
| telegram | No | ||
| No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions 'Create' indicating a write operation but lacks details on permissions, destructiveness, rate limits, or side effects. The image constraint is noted, but overall behavior is minimally disclosed.
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 concise with two sentences, front-loading the main action. However, it is overly terse; adding more relevant details without increasing verbosity would improve utility.
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 13 parameters, no output schema, and no annotations, the description is severely incomplete. It does not address required parameters, default values (e.g., private_event default true), or post-creation behavior. The tool's complexity demands more thorough documentation.
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 only 15% (only 'image_file_path' has a description). The description adds the constraint 'Provide image_url OR image_file_path' but does not explain other critical parameters like name, symbol, outcomes, end_time, etc. The description fails to compensate for the low schema coverage.
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 creates a 'private' prediction market with metadata, distinguishing it from the sibling 'create_market' which likely creates public markets. The verb 'Create' and resource 'private prediction market' are specific and unambiguous.
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 private markets but does not explicitly state when to prefer this over alternatives like 'create_market' or 'pm_buy'. No exclusions or context for when not to use are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open private market to public.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It only states the effect ('open to public') but omits whether the action is reversible, required permissions, side effects on other users, or state changes. This is insufficient for a mutating operation.
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 minimal (one sentence, 4 words). While concise, it sacrifices clarity; a slightly longer description including context would improve usability without being verbose.
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 complexity (one parameter, no output schema) and existence of sibling pm_ tools (e.g., pm_create_market, pm_finalize), the description is incomplete. It does not explain if the market must already be private, what the outcome is, or how it interacts with other market operations.
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 one parameter 'market' (string, required) with no schema description (0% coverage). The description adds no meaning, leaving agents to guess what value constitutes a valid market identifier (e.g., ID, name, address).
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 'Open private market to public.' clearly states the verb 'Open' and the resource 'private market', which matches the tool name pm_disable_freeze. It identifies the tool's core action, but could better distinguish from siblings like pm_create_market or pm_finalize.
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 (e.g., pm_create_market, pm_buy). The description does not specify prerequisites, context, or exclusion criteria, leaving the agent to infer usage from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Finalize a private market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'Finalize', implying a state change, but does not explain consequences, permission requirements, or reversibility.
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 concise (one sentence), but it is under-specified. It earns its place but lacks necessary details.
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 complexity (many sibling tools, no output schema), the description is incomplete. It does not explain the finalization process, side effects, or what distinguishes this from similar 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 coverage is 0%, and the description adds no information about the 'market' parameter beyond its name. The parameter name is somewhat self-explanatory, but no format or constraints are given.
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 'Finalize' and the resource 'private market', which provides a clear purpose. However, it does not distinguish from the sibling tool 'finalize_market' or clarify the context of private vs public markets.
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 'finalize_market' or other pm_* tools. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get private market data.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description fails to disclose any behavioral traits such as side effects, permissions, or rate limits. It merely restates the function name.
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 extremely concise but at the expense of clarity. A single sentence with no structure or detail is insufficient for effective tool invocation.
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 no output schema, no annotations, and a single undocumented parameter, the description is highly incomplete. The agent cannot determine the tool's purpose or usage from this alone.
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 0%, and the description adds no meaning for the required 'market' parameter. The agent receives no hints about its format or allowed values.
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 'Get' and the resource 'private market data', but is vague on what constitutes private market data. It does not differentiate from similar sibling tools like pm_get_min_seed_private or pm_get_user_shares.
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. With many sibling tools for private markets, the description lacks context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get min seed amount (USDB) for a voter-panel private market. Often 0.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description only states what it returns. It does not indicate that the operation is read-only, safe, or has any prerequisites.
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 key information, no redundant words. Extremely 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 parameterless tool, the description adequately explains the purpose and typical output. It could specify the return type (number) 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?
No parameters exist, so the schema covers all. The description adds the insight 'Often 0', which provides useful context about typical values.
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 retrieves the minimum seed amount in USDB for a voter-panel private market. The name and description together distinguish it from siblings like 'get_min_seed' and 'pm_get_min_seed_public'.
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 lacks guidance on when to use this tool over alternatives. It does not mention when 'private' vs 'public' applies or any context for when the value is non-zero.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get min seed amount (USDB) for a non-private private market. Higher than private-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description implies it is a read operation returning a numeric amount. It does not describe side effects or edge cases, but for a getter this is minimally acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no unnecessary words. Front-loaded with action and resource, concise and clear.
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 description is adequate for a simple getter tool with no parameters and no output schema. It explains the value and distinguishes it from a related tool. Slightly lacking in what the agent should do with the result, but 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?
No parameters exist in the schema, so parameter semantics are not needed. The description adds no parameter info, which is acceptable when schema coverage is 100% and there are zero 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 gets the minimum seed amount (USDB) for a non-private private market. It uses specific verb 'get' and resource 'min seed amount', and distinguishes from private-only markets by noting it's higher.
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 tells when to use it (for non-private private markets) and contrasts with private-only via 'higher than private-only'. It does not explicitly name sibling tools but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List sell order on private market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| outcome | Yes | ||
| amount | Yes | ||
| price_per_share | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, and the description fails to disclose any behavioral traits. It does not mention read-only status, authentication needs, rate limits, or what the list returns (e.g., pagination, order details).
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, but it is under-specified. It lacks necessary information that would make it informative, so it is not efficiently 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?
Given four required parameters, no output schema, and no annotations, the description is highly incomplete. It does not explain what the list returns, how filters work, or any other critical details.
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 0% and the description adds no meaning to the parameters. The four parameters (market, outcome, amount, price_per_share) remain unexplained beyond their names.
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 'List', the resource 'sell order', and the context 'on private market'. It distinguishes from sibling 'list_order' which presumably handles public market orders.
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 is provided on when to use this tool versus alternatives like 'list_order' or when not to use it. Implies private market usage but lacks explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add/remove voter for private market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| voter | Yes | ||
| status | Yes | true=add, false=remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only states 'add/remove voter' without mentioning side effects, permissions required, or what happens if the voter already exists. The status parameter is described in the schema, but the description adds no further 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?
The description is highly concise at one sentence, but it is under-specified. While every word is used, the brevity comes at the cost of missing critical details, making it borderline acceptable.
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 prerequisites, expected outcomes, and confirmation of success. It only states the basic action, leaving the agent without enough context to use the tool reliably.
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 description does not elaborate on the 'market' or 'voter' parameters beyond what is in the schema. With only 33% schema description coverage, the description should compensate but fails to provide meaningful additional semantics.
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 (add/remove) and resource (voter for private market), distinguishing it from sibling tools like pm_vote or pm_manage_whitelist. However, it does not explicitly differentiate from other voter management tools, so not a perfect 5.
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 is provided on when to use this tool versus alternatives (e.g., pm_vote for voting, pm_manage_whitelist for whitelist management). The description does not elaborate on prerequisites or context, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage private market whitelist.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| wallets | Yes | ||
| max_usdb | Yes | ||
| tag | No | ||
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits, but 'Manage' is too generic. It fails to indicate side effects, permissions, or whether the operation is additive or subtractive.
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?
Extremely concise but at the expense of clarity. Important information is omitted. Conciseness should not undermine usefulness.
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 5 parameters, no output schema, and numerous siblings, the description is severely incomplete. An agent cannot reliably invoke this tool based on the provided information.
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 0% and the description does not explain the meaning or expected input for any of the 5 parameters (market, wallets, max_usdb, tag, status). This is a critical gap.
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 'Manage private market whitelist' states a verb and resource, but 'Manage' is vague and does not specify the exact operation (add, remove, update). Compared to siblings like 'whitelist_wallets' and 'remove_whitelist', it lacks differentiation.
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. The description provides no context, prerequisites, or exclusions, leaving the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Redeem winnings from a private market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description fails to disclose behavioral traits such as authorization requirements, side effects (e.g., token transfer), or error conditions. The agent lacks critical context for safe invocation.
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 but too sparse. It front-loads the core action but omits essential details, making it barely adequate.
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 absence of annotations and output schema, the description is incomplete. It does not explain return values, potential errors, or steps after redemption. For a mutation tool, this 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?
The input schema has 0% description coverage. The sole parameter 'market' is a plain string with no explanation of what it represents (e.g., market ID, name). The description adds no meaning beyond the schema, leaving the agent to guess.
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 'Redeem winnings from a private market' clearly specifies the action (redeem) and the resource (winnings from a private market). It distinguishes from the sibling tool 'redeem_winnings' by specifying 'private', making the tool's purpose unambiguous.
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 is provided on when to use this tool versus alternatives like 'redeem_winnings' or other private market tools. There is no mention of prerequisites or typical use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Toggle private event buyer access.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| buyers | Yes | ||
| status | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavior. 'Toggle' implies a state change, but the description does not clarify whether it adds/removes buyers, requires specific permissions, or has side effects. The agent is left to infer the mutation behavior from the parameter names 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?
The description is extremely concise: a single sentence. While it avoids verbosity, it sacrifices necessary information. There is no structure (e.g., bullets or sections) to aid comprehension, but the length is appropriate for the simplicity of the action if parameters were explained elsewhere.
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 tool has three required parameters, no output schema, no annotations, and many related sibling tools, the description is deeply insufficient. It fails to explain return values, side effects, prerequisites (e.g., market must be private), or how it relates to pm_manage_whitelist. The agent cannot confidently use this tool without additional context.
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?
With 0% schema description coverage, the description must explain parameter meanings. It does not define 'market,' 'buyers,' or 'status.' The agent cannot infer that 'market' is an identifier, 'buyers' are addresses, or that 'status' toggles access on/off. This is a significant gap.
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 'Toggle private event buyer access' clearly states the verb 'toggle' and the resource 'private event buyer access.' It gives a general sense of the tool's function, but it does not differentiate from sibling tools like pm_manage_whitelist or pm_manage_voter, which might handle similar access controls.
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 usage guidelines are provided. The description does not specify when to use this tool versus alternatives, nor does it mention prerequisites or context. The agent receives no guidance on appropriate invocation scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vote on private market outcome.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| outcome | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full burden. Stating 'Vote' implies mutation but provides no details on side effects, reversibility, permissions, or state changes. Insufficient for a write operation.
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 very short and front-loaded, but the brevity comes at the cost of missing critical information. It is concise but not necessarily effective.
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 tool's complexity (voting on private markets) and lack of annotations, output schema, and parameter descriptions, the description is woefully incomplete. It fails to provide a complete picture for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description adds no parameter info. Neither 'market' (string) nor 'outcome' (number) are explained. The agent cannot infer what values to provide.
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 'Vote on private market outcome' clearly identifies the action (vote) and the resource (private market outcome). It distinguishes from most sibling tools like pm_create_market and pm_finalize, but does not differentiate from vote_on_dispute, which is also a voting action.
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 (e.g., vote_on_dispute) or prerequisites (e.g., must have shares, market must be open for voting). The description lacks context for appropriate usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Preview a buy or sell without executing.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token name or address | |
| amount_usdb | No | USDB amount (for buys) | |
| amount_token | No | Token amount (for sells) | |
| direction | Yes | 'buy' or 'sell' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the transparency burden. It only states it is a preview and does not execute, but fails to disclose what the preview shows (e.g., price impact, fees), whether it modifies state, or any required conditions. Minimal disclosure.
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 extremely concise at 6 words, with no wasted phrases. It front-loads the core purpose effectively.
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 annotations, output schema, and many sibling tools, the description is too brief. It does not explain what the output represents, prerequisites, or how it integrates with other trade operations.
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% description coverage, so each parameter is already documented. The description adds no extra semantic meaning beyond the 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?
The description clearly states it previews a buy or sell without executing, using a specific verb and resource. It distinguishes itself from execution tools like buy_token and sell_token, but could be more explicit about what 'preview' entails.
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 before executing a trade ('without executing'), but does not explicitly mention when to use or avoid it compared to siblings. No alternatives or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose winning outcome (5 USDB bond).
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market token address | |
| outcome | Yes | Outcome name or index |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the 5 USDB bond requirement, which is a key behavioral trait. However, with no annotations, it fails to mention other important aspects like prerequisites, side effects, or what happens after proposing (e.g., dispute period).
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 extremely concise (one sentence) and front-loaded with the action. It wastes no words, though it could be slightly expanded with more context without losing 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?
Given the complexity of the domain and many similar sibling tools, the description is insufficient. It does not explain the role of 'proposing' an outcome, return values, or how it integrates with other actions like finalization or disputes.
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% coverage with descriptions for both parameters. The tool description adds no additional meaning beyond the schema, which is adequate but not enhanced.
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 'propose winning outcome' and mentions the bond requirement. However, it does not specify which market or context, leaving some ambiguity about its precise role among sibling tools like 'dispute_outcome' or 'finalize_market'.
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 is provided on when to use this tool versus alternatives (e.g., 'dispute_outcome', 'veto_outcome', 'finalize_market'). The description offers no 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.
Claim winnings from resolved market.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market token address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; description carries full burden. Discloses only basic action, not behavioral traits like mutability, idempotency, or side effects. For a claim operation, more details are 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 with no wasted words. Concise and appropriately sized for a simple tool.
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?
Adequate for a one-parameter tool, but lacks explanation of results, error conditions, or prerequisites. No output schema, so description could add return info.
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 one parameter described as 'Market token address'. Description adds condition 'resolved market', providing slight extra meaning. 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 'Claim' and resource 'winnings from resolved market', distinguishing it from other claim-type sibling tools like claim_rewards and claim_bounty.
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 vs alternatives or prerequisites. Does not mention that market must be resolved or that user must have winnings, though implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Register as AI agent on-chain (ERC-8004).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Agent display name | |
| description | No | Agent description | |
| capabilities | No | ||
| tx_hash | No | Optional: recover agent ID from a previous registration tx |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only implies state change ('register') but does not mention side effects like gas costs, uniqueness constraints, or success/failure conditions. The optional tx_hash parameter hints at recovery but is not explained.
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, front-loaded sentence that efficiently communicates the core purpose. It is concise but at the cost of omitting necessary details about usage and behavior.
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, no annotations, and 75% schema coverage, the description fails to provide essential context. It does not explain what the tool returns, prerequisites, or side effects. A registration tool requires more detail to be usable.
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 75% (3 of 4 params described). The description adds no additional meaning beyond the schema's parameter descriptions. Baseline is 3 since 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 ('register'), the resource ('AI agent'), and the mechanism ('on-chain (ERC-8004)'). It distinguishes from sibling tools like list_agents and is_agent_registered which are query-only.
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 provides no guidance on when to use this tool, prerequisites, or alternatives. It does not explain if the agent must already exist, if wallet connection is needed, or how it differs from registration-like tools in other contexts.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Remove wallet from frozen token whitelist.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| wallet | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, and the description does not disclose behavioral traits such as idempotency, error handling, authorization needs, or side effects. The description carries the full burden but falls short.
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 with no wasted words. It is efficient, though could be expanded to include more context without losing 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?
Given no output schema, no annotations, and only two parameters, the description is too sparse. It fails to explain return values, error states, or preconditions, which are important for a 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 description coverage is 0%, and the description does not add meaning beyond parameter names. The terms 'token' and 'wallet' are self-explanatory but no additional semantics are provided.
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 (remove), the target (wallet), and the context (frozen token whitelist). It distinguishes from sibling tools like whitelist_wallets and get_whitelist.
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, or prerequisites (e.g., token must be frozen, whitelist must exist). Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repay a hub loan.
| Name | Required | Description | Default |
|---|---|---|---|
| hub_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description reveals no behavioral traits. It fails to disclose whether repayment is destructive, what side effects occur (e.g., loan closure, balance changes), or any required permissions. The agent lacks critical context for safe invocation.
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 concise at 5 words, but this brevity sacrifices essential details. It is not overly verbose, but the lack of structure or additional sentences means it does not effectively communicate what the agent needs.
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 complexity of loan operations and the presence of multiple sibling tools, the description is severely incomplete. There is no output schema, no parameter details, and no behavioral context. The agent cannot determine the tool's full effect or correct usage from this description alone.
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 0%, and the description adds no parameter information. While 'hub_id' is somewhat self-explanatory as a loan identifier, the description should clarify what the parameter represents or any constraints. The agent must rely solely on the schema, which lacks descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Repay a hub loan,' which specifies the action (repay) and resource (hub loan). However, it adds no additional context beyond the tool's name and fails to distinguish from sibling tools like 'repay_loan_on_vesting' or 'vault_repay'. The purpose is clear but minimally sufficient.
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 usage guidelines are provided. The description does not indicate when to use this tool versus alternative loan repayment tools, nor does it mention any prerequisites (e.g., having an active hub loan). The agent receives no guidance on decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repay a loan taken against a vesting.
| Name | Required | Description | Default |
|---|---|---|---|
| vesting_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose side effects, permissions, reversibility, or any behavioral traits beyond the action. For a state-changing operation, 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?
One sentence, no unnecessary words. However, it sacrifices essential detail for brevity. Adequate conciseness but not ideal.
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 zero annotations, no output schema, and very sparse input schema, the description fails to provide necessary context about prerequisites, effects, or return values.
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?
Single parameter 'vesting_id' lacks description both in schema (0% coverage) and in tool description. No explanation of what it represents or how to obtain it.
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 'repay' and resource 'loan taken against a vesting', distinguishing it from sibling tools like 'repay_loan' and 'take_loan_on_vesting'.
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 (e.g., 'repay_loan'). With multiple loan-related siblings, explicit usage context is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a reef post.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | ||
| reason | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without revealing any behavioral traits. It does not disclose whether the report is anonymous, triggers moderation, or requires authentication, which is inadequate for an AI agent.
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, but it omits necessary details. While brevity is positive, the lack of critical information reduces its effectiveness.
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 tool's simplicity (2 params, no output schema), the description should still explain the reporting process, expected outcomes, and parameter usage. It fails to provide sufficient context for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not elaborate on the parameters (post_id, reason). The agent must infer from parameter names alone, missing crucial context about what 'reason' entails or accepted values.
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 'Report a reef post' clearly states the verb and resource, indicating the action of reporting a post. However, it lacks differentiation from sibling tools like delete_reef_post or vote_reef_post, which are distinct actions but not explicitly contrasted.
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 is provided on when to use this tool versus alternatives (e.g., delete_reef_post). The description does not mention any context, prerequisites, or scenarios for reporting, leaving the agent to infer usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a Twitter verification challenge code.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full burden. It reveals only that it 'gets' a challenge code, implying a read operation, but does not disclose any side effects, authentication requirements, rate limits, or whether it may have destructive implications.
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 appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and no parameters, the description is minimally sufficient: it states what the tool returns (a challenge code). However, it lacks context on how to use the code, the expected response format, or limitations.
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 no parameters, so the description does not need to add parameter meaning. Baseline for 0 params is 4, and the description is adequate.
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 obtains a Twitter verification challenge code, using the verb 'Get' and identifying the resource. It distinguishes itself from sibling tools which are mostly unrelated (e.g., verify_twitter, updown_*). However, it could be more specific about the code's purpose.
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 provides no guidance on when to use this tool, prerequisites, or alternatives. There is no mention of what the challenge code is needed for or when to call this versus other verification tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Stake/unstake for dispute voting eligibility.
| Name | Required | Description | Default |
|---|---|---|---|
| action | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It only states the action outcome without detailing side effects, state changes, permissions, or costs.
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, front-loaded sentence with no wasted words. Efficiently communicates the core action.
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 simplicity of the tool, the description still falls short. It omits essential details like what token is staked and the eligibility criteria. More context is expected for a staking 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?
The sole parameter 'action' is self-explanatory from its enum values, but the description adds no further meaning. Schema description coverage is 0%, yet the description fails to compensate.
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 the tool stakes/unstakes for dispute voting eligibility, distinguishing it from other staking tools like stake_stasis. However, lacks specificity about the asset being staked.
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 stake vs unstake, prerequisites, or alternatives to this tool. The description does not help the agent decide when to use it over sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sell a token for USDB. Checks balance first. Use percentage to scale out. NOTE: Floor+ tokens (multiplier 1-99) and prediction market tokens have 1.5% tax, other tokens have 0.5% — account for this in slippage.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token name or address | |
| amount | No | Token amount to sell | |
| percentage | No | 1-100, sell this % of balance | |
| slippage_percent | No | Max slippage % (default: 1) | |
| to_usdb | No | Swap all the way to USDB (default: true). False stops at MAINTOKEN. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses balance check, scaling via percentage, and tax effects. However, no annotations exist, and the description omits side effects, authorization requirements, rate limits, or transaction details like confirmation steps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with no wasted words: purpose, usage hint, and critical tax warning. Front-loaded 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?
Covers the main selling action, balance check, percentage, and tax, but misses context for the 'to_usdb' parameter (stopping at MAINTOKEN). No output schema exists, but a brief note on return values 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 baseline is 3. The description adds meaningful context for 'percentage' (scaling out) and 'slippage_percent' (accounting for tax differences), exceeding the schema's detail.
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's action ('Sell a token for USDB'), identifies the resource (token), and adds check-balance and percentage scaling hints, distinguishing it from sibling tools like buy_token or bet.
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?
Provides explicit guidance on using percentage to scale out and adjusting slippage based on token tax rates (1.5% vs 0.5%). Does not specify when not to use the tool or mention alternatives, but the advice is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update your agent's metadata URI.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_id | Yes | ||
| uri | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only says 'Update' without disclosing side effects, permissions, or what happens to the previous URI. The mutation nature is implied but not elaborated.
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 very short (one sentence), which is concise, but it sacrifices essential details. It is not well-structured for an agent to quickly grasp all necessary 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?
Given no annotations and no output schema, the description fails to cover return value, side effects, or prerequisites. It is incomplete for a 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 0%, yet the description adds no meaning beyond parameter names. It does not explain what 'agent_id' refers to or the format of 'uri'.
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 uses a specific verb ('Update') and a clear resource ('your agent's metadata URI'), effectively distinguishing it from siblings like 'register_agent' (create) and 'get_agent_uri' (read).
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, no prerequisites (e.g., agent must exist), and no mention of checking current URI via 'get_agent_uri' first.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload image and set as profile avatar in one step.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | Image URL to upload and set as avatar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully convey behavioral traits. It only states the action (upload and set avatar) but does not disclose whether it replaces the current avatar, size limits, reversibility, authentication requirements, or side effects.
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, front-loaded sentence that efficiently conveys the core action without 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?
For a low-complexity tool with one parameter and no output schema, the description covers the basic action but lacks context about side effects, prerequisites, or constraints like user authentication or avatar slot availability.
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% for the single parameter. The description adds no new meaning beyond the schema's 'Image URL to upload and set as avatar'. With high coverage, baseline is 3, and no extra context is provided.
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 uploads an image and sets it as profile avatar in one step, distinguishing it from sibling tools like upload_image_from_url (upload only) and update_my_profile (profile update without upload).
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 is provided on when to use this tool versus alternatives such as upload_image_from_url, update_my_profile, or other profile-related tools. The description does not specify prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Buy STASIS and/or wrap→wSTASIS→lock. Multi-step.
| Name | Required | Description | Default |
|---|---|---|---|
| amount_usdb | No | Buy STASIS with USDB first | |
| amount_stasis | No | Wrap STASIS into wSTASIS | |
| lock | No | Lock as collateral | |
| lock_existing_wstasis | No | Lock existing wSTASIS |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It mentions buying, wrapping, and locking but does not disclose side effects, authorization needs, or what happens to assets during steps. This is insufficient for a multi-step operation.
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 efficient sentence that conveys the core action without unnecessary words. It is front-loaded and earns its place.
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 complexity of a multi-step operation with 4 parameters and no output schema, the description is too minimal. It does not explain the order of steps, prerequisites, or what the lock entails, leaving the agent underinformed.
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 descriptive parameter names and descriptions. The tool description adds limited value beyond the schema, noting it's multi-step but not elaborating on parameter interactions. 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?
The description clearly states a multi-step operation: 'Buy STASIS and/or wrap→wSTASIS→lock.' It uses specific verbs and resources, and distinguishes from the sibling tool 'unstake_stasis'.
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 usage guidelines, such as when to use this tool versus alternatives or prerequisites. It only says 'Multi-step' without further context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start surge tax on your token (creator only).
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| start_rate | Yes | Start rate in basis points | |
| end_rate | Yes | End rate in basis points | |
| duration | Yes | Duration in seconds |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full transparency burden. It only mentions authorization ('creator only') but does not explain what happens when surge tax is started, such as changes to transaction fees, duration enforcement, or whether it can be restarted.
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 with no wasted words. It front-loads the action and includes a critical constraint in parentheses.
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 annotations and output schema, the description is inadequate. It does not explain what surge tax does, how parameters affect behavior, or expected outcomes after execution. The agent would need external knowledge to use it correctly.
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?
With 75% schema description coverage, the schema already documents most parameters. The description adds no extra meaning beyond repeating 'token' and 'surge tax', so it meets the baseline but does not compensate for the undocumented token parameter.
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 'Start', the resource 'surge tax', and the scope 'on your token', with an authorization qualifier '(creator only)'. It is distinct from the sibling tool 'end_surge_tax'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states that only the creator can use the tool, which is a key prerequisite. However, it provides no guidance on when to use this tool versus alternatives (e.g., before ending surge tax) or context-sensitive decisions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a bug report.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| description | Yes | ||
| severity | Yes | ||
| category | Yes | ||
| evidence | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description must fully disclose behavior. It only says 'submit', implying a write operation, but fails to describe side effects, permissions, or response format.
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 very brief (one sentence) but under-specified. It sacrifices completeness for brevity, failing to convey essential details for a tool with 5 parameters and no output schema.
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 annotations, no output schema, and 5 parameters, the description is severely incomplete. It lacks any context about errors, confirmation, or post-submission 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 description coverage is 0%, and the description provides no parameter info. The agent gets no help understanding what 'title', 'description', 'severity', 'category', or 'evidence' mean, despite enums being present.
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 ('Submit a bug report') and distinguishes it from sibling 'get_bug_reports' which reads reports. However, it lacks specifics about what the submission entails.
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 over alternatives or any prerequisites. There is no mention of context such as needing authentication or that this creates a record.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sync a loan transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'sync a loan transaction' without explaining side effects (e.g., writes to chain, requires specific permissions) 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?
The description is very short and front-loaded, but it sacrifices informativeness for brevity; slightly under-specified.
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 one parameter and no output schema, the description should provide more context about return values, error cases, or typical usage, but it does none of this.
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 0%, yet the description adds no meaning for the sole parameter 'tx_hash'—it does not explain its purpose or format.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states the action 'sync a loan transaction' with a verb and resource, but 'sync' is ambiguous (e.g., fetch, update, reconcile) and does not distinguish from sibling tools like sync_order or sync_transaction.
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, no prerequisites or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sync an order book transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. 'Sync' implies a write operation, but there is no information on side effects, idempotency, permissions, or whether it is destructive. Critical details are missing.
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 but insufficiently informative. It lacks structure and does not earn its place by adding value beyond the name.
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 annotations, no output schema, and a vague description, the tool definition is incomplete. An agent would have to guess the behavior and parameter meaning, risking incorrect 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?
The schema has one parameter (tx_hash) with 0% description coverage, and the description adds no meaning about the parameter. It fails to explain what tx_hash is or how to use it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Sync an order book transaction,' providing a verb and resource. However, it is vague and does not distinguish from similar sibling tools like 'sync_loan' or 'sync_transaction'.
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 is provided on when to use this tool versus alternatives (e.g., when to sync an order vs. a loan). There is no context for intended usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manually sync a transaction to the backend.
| Name | Required | Description | Default |
|---|---|---|---|
| tx_hash | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description is the sole source of behavioral info. It only says 'Manually sync a transaction to the backend,' which implies mutation but doesn't disclose idempotency, safety, permissions, or side effects. This is insufficient for informed invocation.
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 redundancy. It could incorporate more detail (e.g., about the parameter) without becoming verbose, but as a concise statement it works.
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 having a single parameter and no output schema, the description fails to mention the outcome of syncing (e.g., whether it returns a status, errors, or is destructive). For a mutation tool among many similar sync tools, the lack of differentiation and behavioral context makes it incomplete.
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 parameter 'tx_hash' has no description in the schema (0% coverage) and the description adds no explanation of what it represents or how to obtain it. The agent receives no extra meaning beyond the parameter name.
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 'sync' and the resource 'transaction', distinguishing it from sibling sync tools like sync_loan and sync_order. However, it lacks specifics on what 'sync' entails (e.g., updating backend state from blockchain).
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 is provided on when to use this tool versus alternatives (e.g., sync_loan). There is no mention of prerequisites, limitations, or scenarios where this tool is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Loan against any token. No price liquidation. For STASIS prefer vault_borrow.
| Name | Required | Description | Default |
|---|---|---|---|
| collateral_token | Yes | Token name or address | |
| amount | Yes | Collateral amount | |
| days | Yes | Duration (min 10) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears full responsibility for behavioral disclosure. It only mentions 'no price liquidation,' but omits critical details like interest rates, collateral locking, repayment process, or consequences after the loan duration. The tool's behavior is insufficiently documented.
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 extremely concise—two sentences, no wasted words. It states the purpose and a key guideline in an efficient, front-loaded manner.
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 tool's complexity (financial loan operation) and the absence of an output schema, the description is incomplete. It fails to explain return values, interest, repayment, or other behavioral aspects, leaving significant gaps for an agent to use it correctly.
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% description coverage, so the schema already explains all parameters. The description adds no additional semantic value for the parameters beyond what is 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 the tool's core function: taking a loan against any token. It highlights a distinctive feature ('no price liquidation') and explicitly distinguishes a sibling tool ('For STASIS prefer vault_borrow'). This meets the highest standard for purpose 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?
The description provides one specific usage guideline: for STASIS token, use vault_borrow instead. However, it lacks broader guidance on when to use this tool versus other loan-related siblings (e.g., increase_loan_collateral, repay_loan). The exclusion is helpful but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Take a loan against a vesting schedule.
| Name | Required | Description | Default |
|---|---|---|---|
| vesting_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must supply behavioral context. It only states 'Take a loan', implying a mutation, but omits details like permissions, costs, effects on vesting schedule, reversibility, or side effects. This is insufficient for safe use.
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?
At five words, the description is extremely concise but at the cost of completeness. It could include essential context without being verbose, so it is under-specified rather than efficiently 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?
Given the lack of annotations, output schema, and rich input schema, the description is critically incomplete. It fails to cover return values, prerequisites, side effects, error conditions, or relationship to other loan-related 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?
The sole parameter 'vesting_id' has 0% schema description coverage, and the description adds no meaning. It does not explain what vesting_id represents or how to obtain it, leaving the agent to guess.
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 'Take a loan against a vesting schedule' clearly states the action (take a loan) and the resource (vesting schedule). It distinguishes from siblings like 'take_loan' (general) and 'repay_loan_on_vesting' by specifying the context, but could be more explicit about what a vesting schedule is.
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 such as 'take_loan' or 'repay_loan_on_vesting'. The description does not mention prerequisites, exclusions, or context for appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Transfer vesting creator role.
| Name | Required | Description | Default |
|---|---|---|---|
| vesting_id | Yes | ||
| new_creator | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It only implies a mutation (transfer) without disclosing permissions, side effects, or reversibility.
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 short sentence, but under-specification makes it less useful; it needs more content to be effective.
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 description lacks details about output, behavior, and parameter semantics, making it incomplete for a mutation tool with no annotations or output schema.
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 0% description coverage, and the description does not explain the parameters 'vesting_id' and 'new_creator', leaving their purpose and format unclear.
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 'Transfer vesting creator role' clearly states the verb (transfer) and the resource (vesting creator role), distinguishing it from siblings like 'change_vesting_beneficiary'. However, it could be more specific about the action's effect.
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, no prerequisites, and no when-not conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open frozen token to public trading. Irreversible.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description highlights irreversibility, which is a critical behavioral trait. However, with no annotations provided, the description should disclose more details such as permission requirements, side effects, or state changes beyond the single mention of irreversibility.
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?
Extremely concise: two sentences with no superfluous words. Every sentence adds value (action and key warning).
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 simplicity (one parameter, no output schema, no annotations), the description is largely adequate. It covers the core action and a critical warning. However, it could mention that the token must be in a frozen state.
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 the parameter 'token' described as 'Token address'. The description adds the context of 'frozen token' but does not add new semantic meaning beyond what the schema already 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?
Clearly states the action (open) and resource (frozen token to public trading). The word 'unfreeze' in the name is reinforced. However, it does not explicitly distinguish from the sibling 'pm_disable_freeze', which might serve a similar purpose in a different context.
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 'pm_disable_freeze'. No prerequisites or conditions (e.g., token must be frozen) are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Unwrap/sell staked STASIS.
| Name | Required | Description | Default |
|---|---|---|---|
| unlock | No | Unlock from collateral first | |
| sell_to_usdb | No | Sell all the way to USDB | |
| shares | No | wSTASIS shares to unwrap |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states it is an unwrap/sell operation. It fails to disclose key behavioral traits such as whether this action is destructive, irreversible, requires authentication, or what happens to the collateral mentioned in the 'unlock' parameter. The minimal description leaves significant ambiguity.
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 short sentence, which is concise and front-loaded. However, it is arguably too sparse for a mutation tool, slightly detracting from optimal structure. A 4 reflects good conciseness but room for more useful content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the action (unwrapping/selling staked tokens with boolean flags), no annotations, and no output schema, the description is incomplete. It omits crucial context like the order of operations when both unlock and sell are true, any fees, slippage, or return value, leaving the agent underinformed.
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 for 'unlock', 'sell_to_usdb', and 'shares'. The tool description adds no additional meaning beyond what the schema already provides, resulting in a baseline score of 3.
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 'Unwrap/sell staked STASIS' uses a specific verb ('Unwrap/sell') and resource ('staked STASIS'), clearly distinguishing it from sibling tools like 'stake_stasis' and general sell tools. The purpose is immediately understandable.
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 'sell_token' or 'stake_stasis'. The description does not specify context prerequisites or conditions under which this tool should be chosen.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update your profile. One action per call.
| Name | Required | Description | Default |
|---|---|---|---|
| username | No | Set username (null to clear) | |
| avatar | No | Set avatar URL (IPFS/Pinata URL, or null to clear) | |
| social | No | Link a social account | |
| remove_social | No | Platform name to unlink | |
| toggle_social_public | No | Platform name to flip public/private |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description should disclose behavioral traits. It only states 'Update your profile' and the constraint, but does not mention authentication needs, whether fields are overwritten, or what happens on null inputs. The schema descriptions cover some of this, but the description adds no new 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?
The description is two sentences with no redundant information. It is front-loaded and efficient, earning high marks for 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?
Given 5 parameters (including a nested object), no output schema, and no annotations, the description is too sparse. It lacks information on return values, side effects, and behavior when multiple parameters are provided (contradicting the 'one action' rule).
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 detailed parameter descriptions (e.g., 'Set username (null to clear)'). The description adds no additional parameter meaning, so 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?
The description clearly states the tool updates the user's profile and adds a constraint ('One action per call'). However, it does not differentiate from sibling tools like 'set_avatar' or 'set_agent_uri' that also modify profile fields.
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 provides the constraint 'One action per call' but offers no guidance on when to use this tool versus alternatives. For example, it doesn't suggest using 'set_avatar' for avatar-only updates.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place a bullish or bearish bet on the current UPDOWN round. Auto-approves USDB and pre-checks balance + minBet client-side. Use slippage_percent for an optional minShares guard.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | Yes | ||
| side | Yes | ||
| amount | Yes | USDB amount (whole tokens) | |
| slippage_percent | No | Optional. If set, throws when projected shares would be > slippage_percent below quoteShares (default: no slippage check) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses key behaviors: auto-approves USDB, pre-checks balance/minBet client-side, and optional slippage guard. However, with no annotations, more detail on side effects (e.g., failure modes, atomicity) would improve 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?
Three sentences efficiently cover purpose, behavior, and optional parameter. No redundancy, though it could be slightly more compact.
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?
Fails to explain return values, how to identify the current round, prerequisites (wallet, USDB balance), or relation to siblings like 'updown_get_round'. A more complete description would tie these together.
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 low (40%), but the description only adds meaning for slippage_percent. Parameters like 'tf' (timeframe) and 'asset' are left unexplained, requiring the agent to infer from enums and tool name.
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 'Place a bullish or bearish bet on the current UPDOWN round,' specifying the action and resource. It distinguishes itself from sibling 'bet' by targeting the UPDOWN round specifically.
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 vs. alternatives like 'bet' or other updown tools. The mentions of auto-approval and pre-checks imply convenience but do not replace alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current bull probability for the active UPDOWN round (basis points 0-10000, also returned as percentage).
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | Yes | 0=5m, 1=15m, 2=1h, 3=4h, 4=24h |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. The description does not disclose whether the operation is read-only, requires authentication, or what happens if no active round exists. Very minimal 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?
The description is a single sentence with no unnecessary words, front-loading the key purpose and units.
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 lacks details on return format, error cases, and behavior when no active round exists. Incomplete for reliable agent 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?
The description adds no additional meaning to the parameters beyond the schema. The 'tf' parameter has a schema description, but the 'asset' parameter only has an enum; the tool does not explain how these affect the result.
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 returns the 'bull probability for the active UPDOWN round' with units clarified, distinguishing it from other round-related tools like updown_get_round.
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 (e.g., updown_get_round). No mention of prerequisites or scenarios where the tool is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public cancel of a stalled UPDOWN round (settle window expired). Anyone can call after endTime + FINALIZE_WINDOW.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses permissionlessness and timing, but does not explain side effects or post-cancel behavior, leaving some gaps for an agent.
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 front-loads the purpose with no redundant words, making it highly 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?
Despite the tool's complexity, the description is minimal. It misses important context about what a stalled round is, what endTime and FINALIZE_WINDOW refer to, and the outcome of cancellation.
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 0%, yet the description adds no meaning for the two parameters (asset and tf). The agent must infer their purpose from context, which may be insufficient.
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 cancels a stalled UPDOWN round, with the condition that the settle window has expired. This specific verb+resource distinguishes it from siblings like updown_settle or updown_claim.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly notes the condition for use (after endTime + FINALIZE_WINDOW) and that anyone can call, providing clear context. However, it does not mention when not to use or suggest alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim winnings or refund from a settled UPDOWN round. Pre-checks via quoteClaimPayout — refuses to send if 0.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | Yes | ||
| round_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses the key behavior of refusing to send if payout is 0, which is critical for an agent to understand. Without annotations, this description provides valuable behavioral context beyond the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with core purpose, no redundant information. Every word is necessary 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?
For a simple claim tool, the description covers the essential behavioral constraint (pre-check and refusal). Lacks details on parameter semantics and output, but overall sufficient given the tool's simplicity and the presence of related quote 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?
No parameter descriptions in the description, and schema coverage is 0%. While tool name and context suggest the purpose of asset, tf, and round_id, explicit documentation is missing, forcing the agent to infer meaning from enum values and tool name.
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 identifies the action (claim winnings or refund) and the resource (settled UPDOWN round), effectively distinguishing it from sibling tools like updown_bet and updown_quote_claim.
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?
Mentions a pre-check via quoteClaimPayout, implying when to use (after checking payout is non-zero), but lacks explicit guidance on when to use this tool versus alternatives like updown_quote_claim or updown_settle.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a specific UPDOWN round by id — or omit round_id to get the current round. Returns the full Round struct (startPrice/endPrice in 8-dec, pools/shares/seedBonus in 18-dec USDB, outcome enum 0=Pending,1=BullWins,2=BearWins,3=Canceled). Returns null if no rounds opened yet.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | Yes | Timeframe enum: 0=5m,1=15m,2=1h,3=4h,4=24h | |
| round_id | No | Optional — defaults to currentRoundId(tf) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations, so description carries full burden. Discloses return format with decimals, outcome enum, and null case for no rounds, but lacks info on error conditions or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, then return details. No fluff 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?
Covers both use cases and return struct details (decimals, enum, null), but does not address error scenarios or invalid round_id. Fairly complete for a simple getter.
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 2/3 params with descriptions (67%), and the description adds context by explaining the optional round_id default behavior, though it doesn't add new parameter-level details.
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 the verb 'Get' and resource 'UPDOWN round', with two distinct usage patterns: by id or current round. Differentiates from siblings like updown_list_rounds.
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?
Implies usage for getting a specific or current round, but does not explicitly state when not to use it or mention alternatives like updown_list_rounds for multiple rounds.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get your bet on a specific UPDOWN round. amount=0 means no bet placed.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | Yes | ||
| round_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It implies a read-only operation and clarifies a key behavior (amount=0 means no bet). However, it does not disclose whether the tool requires authentication, what happens for non-existent round_ids, or any side effects. The clarity on the zero amount is helpful but 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?
The description is extremely concise with only two sentences. It front-loads the main purpose and adds a useful clarification. While it could be more structured (e.g., listing parameters), its brevity avoids unnecessary content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 3 required parameters and no output schema. The description does not explain the return value format beyond the zero-bet case, nor does it describe any preconditions or error handling. For a simple read tool, it is missing enough detail for an agent to confidently interpret results.
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 0%, so the description must add meaning to parameters. It does not explain 'asset', 'tf', or 'round_id' beyond context from the tool name. While 'asset' is partially understood from the schema enum, 'tf' and 'round_id' lack units or format hints. The description mentions 'amount' but that is a return field, not an input parameter.
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 retrieves the user's bet for a specific UPDOWN round, with a single verb 'get' and clear resource. It also provides a useful note about the meaning of amount=0, which aids interpretation. The purpose is specific and distinct from sibling tools due to the 'updown' prefix and focus on a single bet.
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 is provided on when to use this tool versus alternatives like updown_my_history (which lists all bets) or updown_get_round (which gets round details). The description does not mention any prerequisites or context for using the tool effectively.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paginated UPDOWN round list for a token, newest-first. Optional tf and outcome filters.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | No | ||
| outcome | No | ||
| cursor | No | nextCursor from a prior page | |
| limit | No | default 20, max 200 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It mentions pagination and ordering but omits whether the operation is read-only (likely), any side effects, auth needs, or error conditions. The lack of behavioral depth is significant for a list operation.
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, front-loaded sentence with no redundant words. It efficiently conveys the core purpose, pagination order, and filter options.
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?
While it covers the essential listing and filtering behavior, it does not explain cursor usage (beyond mentioning it in schema), pagination defaults (limit default 20, max 200), or what happens when the token is invalid. Given no output schema, a bit more context on return shape would be helpful, but it is minimally 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 coverage is 40% (only cursor and limit described). The description adds that 'tf' and 'outcome' are filters, but does not explain 'tf' as a number (likely timestamp or duration) or detail the enum values for asset or outcome. Baseline 3 is adjusted slightly downward for missing semantics on the remaining 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 it lists paginated UPDOWN rounds for a token, newest-first, with optional filters. This specific verb+resource combination distinguishes it from siblings like updown_bet, updown_claim, or updown_my_history.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explains the pagination and optional filters, implying use when listing rounds. However, it does not specify when to prefer this over other round-related tools (e.g., updown_get_round, updown_my_history), nor does it list exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Minimum bet amount in USDB for an UPDOWN asset.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description does not disclose behavioral traits such as read-only nature, authentication requirements, error handling for invalid assets, or any side effects. The description only states what it returns.
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 with no unnecessary words. It front-loads the key information (minimum bet amount) and is efficiently 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?
Given there is no output schema, the description mentions the return is an amount in USDB, which is helpful. However, it could specify the type (e.g., number) and whether it is per round or per bet. The tool is one of many updown tools, but the description does not clarify its specific role.
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 0% and the description does not explain the 'asset' parameter beyond its existence. Although the schema includes an enum, the description adds no meaning about valid values or expected format.
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 returns the minimum bet amount for an UPDOWN asset, which aligns with the tool name. It distinguishes from sibling tools like updown_bet (which places bets) and updown_quote_shares (which quotes shares). However, it does not explicitly state it is a read operation.
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 is provided on when to use this tool versus alternatives such as updown_quote_current_payout or updown_slippage_threshold. There is no indication of prerequisites or context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Aggregate UPDOWN bet/claim summary for your wallet across every asset (BTC/ETH/BNB/CAKE/DOGE) and all timeframes — totals, win/loss tallies, and embedded activeBets[] / claimableBets[] arrays.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It discloses that the output includes totals, win/loss tallies, and arrays of active and claimable bets. However, it does not mention whether the operation is read-only, requires authentication, or any rate limits. It adequately describes the return structure but lacks safety 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?
The description is a single concise sentence that front-loads the verb 'Aggregate' and lists key output elements. No wasteful 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 0 parameters and no output schema, the description provides a good overview of the return structure. It could optionally mention if there is pagination or a limit on rounds, but for a summary tool, it is sufficiently 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?
The input schema has 0 parameters, so schema coverage is trivial. The description adds meaning by explaining that the tool aggregates across all assets and timeframes, which is not evident from the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool aggregates a summary of UPDOWN bets/claims for the user's wallet across multiple assets and timeframes, including specific output fields. It distinguishes from sibling tools like updown_get_user_bet which likely returns a single bet.
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 broad history view, but it does not explicitly state when to use this tool versus alternatives like updown_get_user_bet or updown_claim. 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.
Check if an UPDOWN asset is paused (writes will revert if true).
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes |
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 that the tool is a read-only check and warns that writes will revert if paused. This is good behavioral context, though it could mention error handling or return type.
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, well-structured sentence that immediately conveys the tool's purpose and a critical consequence. 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?
For a simple boolean check with one parameter and no output schema, the description provides essential behavioral context and distinguishes from siblings. However, it omits details like return format or what happens if the asset is not paused, but given the simplicity, it is largely 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?
The schema has one parameter with 0% description coverage. The description does not mention the 'asset' parameter or its allowed values (enum). Since the schema lacks descriptions, the description should compensate but fails to add any parameter context beyond the tool name.
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 uses a specific verb 'Check' and clearly identifies the resource 'UPDOWN asset paused'. It distinguishes itself from sibling tools like updown_bet or updown_claim by focusing solely on the pause 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?
The description explicitly states that 'writes will revert if true', which strongly implies using this tool before write operations. While it doesn't list alternative tools, it provides clear context for when to check this status.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Exact USDB you can claim from a settled round. 0 means nothing to claim (lost / already claimed / pending / no bet).
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | Yes | ||
| round_id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It tells the return value and conditions for 0, but fails to explicitly state that this is a read-only query with no side effects. The name 'quote' hints at non-mutation, but it's not explicit.
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 one concise sentence plus a clarifying phrase. It is front-loaded with the core purpose and contains no fluff.
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 query tool with three parameters and no output schema, the description adequately explains the return value. However, it lacks parameter documentation and could explicitly state read-only behavior. Sibling tools provide context but the description is mostly self-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?
The description does not explain any of the three parameters (asset, tf, round_id). Schema coverage is 0%, so the description should compensate but doesn't. The enum for asset is self-explanatory, but tf and round_id lack meaning.
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 returns the exact USDB claimable from a settled round, and explains what a 0 result means. It distinguishes this from siblings like updown_claim (which actually performs the claim).
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 for settled rounds but does not explicitly state when to use this tool versus alternatives like updown_claim or updown_get_user_bet. No when-not-to-use or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Estimate your payout if the active UPDOWN round settled now in your favor. Returns 0 if no bet placed.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It states 'estimate' and 'returns 0 if no bet', implying read-only behavior, but does not explicitly confirm no side effects or other behavioral traits.
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 concise with two sentences, front-loading key information. However, it could be more structured by incorporating parameter explanations without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has simple inputs and no output schema; the description gives a clear purpose but omits parameter details, leaving some gaps in understanding for an agent.
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 0%, and description provides no explanation of the required parameters 'asset' (enum) and 'tf' (number). The tool name and description do not clarify what 'tf' represents (likely time frame), leaving agents uninformed.
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 payout for an active UPDOWN round if settled in user's favor, and specifies return of 0 if no bet placed. This distinguishes it from sibling tools like updown_quote_claim or updown_quote_shares.
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 when you want to know potential payout, but lacks explicit guidance on when not to use it or alternatives. No comparison to siblings or conditions for non-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public settle of an UPDOWN round once it has ended and a valid Chainlink price is available. Anyone can call.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | Yes |
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 'public settle' and 'anyone can call', but does not describe side effects, success/failure conditions, or what happens if called prematurely. This is minimal disclosure 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 two concise sentences with no unnecessary words. It is front-loaded with the main purpose and additional context about public access and timing.
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 tool's role in a betting lifecycle, the description lacks contextual completeness. It does not mention return values (no output schema), preconditions beyond basic timing, or how this fits with other updown tools. More context on effects and usage flow is needed.
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 description does not explain the parameters beyond their names. 'asset' is an enum but not detailed; 'tf' (timeframe?) is not described. With 0% schema description coverage, the description adds no semantic value to the 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's purpose: settling an UPDOWN round after it ends and a valid Chainlink price is available. The verb 'settle' and resource 'UPDOWN round' are specific, and the description distinguishes it from siblings like updown_bet or updown_claim.
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 specifies when to use the tool (after round ends and valid price available) and that it is public. However, it does not provide explicit exclusions or mention alternative tools for similar tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current slippage threshold in BPS for the active round. Decays from 9500 (95%) at start to 5500 (55%) at end.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the decay from 9500 to 5500 BPS over the round. However, it does not explain how parameters 'asset' and 'tf' affect the threshold, nor the output format, despite no annotations being provided.
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 extremely concise with two sentences, no repetition, and front-loads the core purpose. Every word contributes value without unnecessary elaboration.
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 a simple purpose, the description omits critical context such as how the round is defined, whether the threshold depends on asset/timeframe, and the expected return value. Given no output schema and no annotations, the description leaves significant 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?
With 0% schema description coverage, the description fails to explain the meaning or role of the two required parameters (asset and tf). The user must rely solely on the schema enum for asset and the name 'tf'.
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 returns the current slippage threshold for the active round, with decay values. It distinguishes itself from sibling 'updown' tools by specifically mentioning the threshold decay, but lacks an explicit verb like 'get' or 'retrieve'.
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 such as 'updown_tf_duration' or 'updown_min_bet'. The description only explains behavior without contextualizing its place among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Round duration in seconds for a timeframe.
| Name | Required | Description | Default |
|---|---|---|---|
| asset | Yes | ||
| tf | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose any behavioral traits such as whether the tool is read-only, requires authentication, or has side effects. The agent cannot determine safety or prerequisites.
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 too brief and under-specified. While it is short, it fails to provide necessary information, making it more of an underspecification than concise clarity.
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 annotations, no output schema, and 0% schema description coverage, the description is severely incomplete. It does not address any context needed for an agent to correctly invoke the 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?
The input schema has 0% description coverage, so the description carries full burden. However, it adds no meaning to the parameters 'asset' (enum) or 'tf' (number). The agent cannot infer the units or allowed values for 'tf' 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 'Round duration in seconds for a timeframe.' is vague. It does not specify what 'round' refers to, nor does it clarify the role of the 'asset' and 'tf' parameters. Compared to sibling tools like updown_get_round, the purpose is not clearly differentiated.
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 usage guidelines provided. There is no indication of when to use this tool versus alternatives like updown_get_round or updown_bet.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload a local image file to Basis (Pinata/IPFS). For agents/Claude Code with local file access.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to image file | |
| purpose | No | Default: 'token' | |
| contract_address | No | Required for purpose='token' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden. It only states the basic upload action and destination, without disclosing behavioral traits like error handling, file size limits, permissions, or what happens on success. This is insufficient for a file upload 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 extremely concise with two sentences, no redundancy, and front-loads the action and destination. Every word adds value relative to the tool's simplicity.
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 tool has three parameters, no output schema, and no annotations, the description is too brief. It omits crucial context such as return values, error conditions, file format or size constraints, and any prerequisites for local file access. This incompleteness could hinder correct invocation by an AI agent.
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% coverage with descriptions for all parameters. The description adds no additional meaning beyond 'local image file' and the intended audience, so it meets the baseline but does not improve 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 the action ('Upload a local image file') and the destination ('Basis (Pinata/IPFS)'), and distinguishes from the sibling tool 'upload_image_from_url' by emphasizing 'local file access'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly targets 'agents/Claude Code with local file access', implying the tool is for local files rather than URLs, but it does not explicitly state when not to use it or provide alternatives beyond the sibling name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upload an image from URL to Basis (Pinata/IPFS). Use purpose='avatar' for profile pics, 'token' for token/market images (requires contract_address).
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | ||
| contract_address | No | Required for purpose='token' | |
| purpose | No | Default: 'token' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions destination and constraints, but lacks details on side effects, permissions, or rate limits. Adequate for a simple upload.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences: first describes the action, second gives usage guidance. No wasted words, front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Complete for a simple tool: covers purpose differentiation, parameter requirements, and destination. No output schema needed, no nested objects.
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?
Adds context beyond schema: clarifies purpose usage and that contract_address is required for 'token'. Compensates for schema's lack of description on image_url.
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 (upload), source (URL), destination (Basis/Pinata/IPFS), and distinguishes purposes ('avatar' vs 'token'), making it distinct from sibling tool 'upload_image_from_file'.
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 advises when to use each purpose and the required parameter for 'token'. Does not explicitly state when not to use, but the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Borrow USDB against locked wSTASIS. 2% + 0.005%/day.
| Name | Required | Description | Default |
|---|---|---|---|
| amount_stasis | Yes | STASIS amount to borrow against | |
| days | Yes | Loan duration |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It only reveals the interest rate (2% + 0.005%/day) but omits critical details like loan mechanics, repayment terms, or what happens in case of default. For a mutating financial tool, 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 extremely concise, using one sentence to convey the core function and a critical behavioral detail (interest). It is front-loaded with the verb and resource, earning its place without extraneous text.
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 absence of output schema and annotations, the description is incomplete. It fails to mention return values, side effects, or necessary context for a borrowing tool, such as the creation of a loan or repayment requirements.
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 ('STASIS amount to borrow against', 'Loan duration'). The description adds no additional meaning beyond what the schema provides, maintaining the baseline score.
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 ('Borrow USDB') and the resource ('locked wSTASIS'), including interest rate details. It effectively differentiates from sibling tools like 'vault_repay' by specifying borrowing as the core function.
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 provides no guidance on when to use this tool versus alternatives, such as 'take_loan' or 'vault_repay'. It also does not mention prerequisites (e.g., having locked wSTASIS) or typical scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Repay vault loan.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description must disclose behavioral traits. The description solely states 'Repay vault loan' with no details on effects, required conditions, or side effects. Key behaviors like whether debt is reduced, if funds are taken from an account, or any fees involved are omitted.
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 extremely concise at one sentence, but it sacrifices substance. While there is no wasted text, the brevity leaves out critical context that would make the description more useful. A longer description with more details would be warranted.
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 presence of many sibling loan-related tools (e.g., 'vault_borrow', 'repay_loan', 'take_loan'), the description is incomplete. It does not explain what a vault loan is, how it differs, or the effect of repayment. The lack of output schema further compounds the need for a richer description.
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 no parameters, so the description adds no parameter information. With 100% schema coverage (no params), the baseline of 4 is appropriate as there is nothing to add 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?
The description 'Repay vault loan' clearly states the action (repay) and the resource (vault loan). However, it does not distinguish between this tool and sibling tools like 'repay_loan' or 'repay_loan_on_vesting', leaving ambiguity about the specific context of a vault loan.
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 is provided on when to use this tool versus alternatives such as 'repay_loan' or 'take_loan'. The description lacks any situational context or prerequisites, making it difficult for an AI agent to select appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify the Moltbook challenge post to complete account linking.
| Name | Required | Description | Default |
|---|---|---|---|
| agent_name | Yes | ||
| post_id | Yes | Post UUID or URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It only mentions verification and account linking, without disclosing side effects, authentication needs, or whether the operation is destructive. This is insufficient for safe invocation.
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 directly states the tool's purpose with no wasted words. Structurally 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?
For a verification action with 2 parameters and no output schema, the description lacks prerequisite info, success/failure behavior, and return value details. It is too minimal to be fully useful to an AI agent.
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 50% (post_id has description, agent_name none), but the description adds no parameter context. It does not clarify agent_name purpose or post_id format beyond what schema already 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?
The description clearly states the tool verifies a Moltbook challenge post to complete account linking. It uses a specific verb and resource, but does not differentiate from a similarly named sibling 'verify_moltbook_post'.
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 is provided on when to use this tool versus alternatives like link_moltbook or verify_moltbook_post. Context of use is entirely implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a Moltbook post for verification (earns points, max 3/day, 7-day lock-in).
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | Post UUID or URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that submission is a write operation with earning points, daily cap, and 7-day lock-in. No annotations provided, so description carries the full burden; it is mostly sufficient. However, does not specify required permissions or reversibility.
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, 14 words, front-loaded with action, parenthetical adds key constraints. No redundant 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?
With one simple parameter and no output schema, description covers action and limits. Missing details: what 'verification' entails, return value, and prerequisites (e.g., linked Moltbook account). Still adequate for basic 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 coverage is 100% with param description 'Post UUID or URL'. Description adds no additional parameter meaning beyond the schema, earning baseline 3.
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 action 'Submit a Moltbook post for verification' and adds distinct context (earns points, daily cap, lock-in). Distinguishes from sibling 'verify_moltbook' which likely handles account-level verification.
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?
Implies usage through 'max 3/day, 7-day lock-in' but does not explicitly contrast with alternative verification tools like verify_moltbook, verify_social_tweet, or verify_twitter. Agent must infer when to use this specific tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Submit a tweet tagging @LaunchOnBasis for points. Max 3/day.
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must fully disclose behavior. It only mentions submission and a daily cap, omitting side effects (e.g., record creation), failure modes, or authorization needs. 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 very concise (two sentences) and front-loads the core purpose. While efficient, it lacks structural elements like bullet points that could improve scannability.
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 tool with no output schema, the description still misses critical context: what 'points' are, how to obtain the tweet URL, expected response, and differentiation from verify_twitter. The user is left with unanswered questions.
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 description adds context that the tweet must tag @LaunchOnBasis, which clarifies the purpose of the tweet_url parameter. However, it does not specify required format (e.g., full URL vs. ID) or other constraints, leaving ambiguity.
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 ('Submit a tweet tagging @LaunchOnBasis for points'), making the purpose evident. However, it does not distinguish from sibling tools like verify_twitter or verify_moltbook, which could cause confusion.
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 provides a rate limit ('Max 3/day') but offers no guidance on when to use this tool versus alternatives, no prerequisites, and no context for appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Verify a Twitter challenge tweet for account linking.
| Name | Required | Description | Default |
|---|---|---|---|
| tweet_url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so the description must disclose side effects. It does not state whether verification is read-only or mutates state, whether it makes external API calls, or what happens on success/failure.
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 concise, consisting of a single sentence. However, it sacrifices critical details, bringing it slightly below a perfect score.
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 no output schema, no annotations, and a single parameter, the description fails to explain the verification process, return values, or potential outcomes, leaving significant gaps for the agent.
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 only parameter 'tweet_url' has no description in the schema (0% coverage), and the tool description adds no details about expected format (full URL, ID, etc.) or constraints.
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 identifies the tool's action ('verify') and resource ('Twitter challenge tweet for account linking'). It distinguishes from sibling tools like 'request_twitter_challenge' and 'verify_social_tweet' by specifying 'challenge tweet' and 'account linking'.
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. For example, it does not mention that 'request_twitter_challenge' should be called first, nor does it clarify the relationship with 'verify_social_tweet'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Veto a proposed market outcome (admin).
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | ||
| outcome | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral traits like destructiveness, permission requirements, or side effects. The minimal description fails to inform the agent beyond the basic action.
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 extremely concise at 7 words, but it lacks structure and is too minimal. It earns its place by being short, but it sacrifices completeness.
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 an admin action with 2 parameters and no output schema. The description does not explain return values, prerequisites, or consequences. It is incomplete for safe and effective 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?
Input schema has 0% description coverage for parameters. The description adds no meaning to 'market' or 'outcome'. The agent must guess their formats or acceptable values.
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 'Veto', the resource 'proposed market outcome', and the context '(admin)'. It effectively distinguishes from sibling tools like dispute_outcome and propose_outcome.
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 such as dispute_outcome or finalize_market. The description lacks context on prerequisites or scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Vote during dispute. Requires resolver_stake first. 24h lock.
| Name | Required | Description | Default |
|---|---|---|---|
| market | Yes | Market token address | |
| outcome | Yes | Outcome to vote for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses that staking is required and that there is a 24-hour lock, but omits details like idempotency, permission requirements, or the effect of voting (e.g., resolution impact).
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 extremely concise with only three sentences, each providing essential information: purpose, prerequisite, and constraint. No fluff 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 and moderate complexity, the description covers key behavioral aspects (prerequisite and lock) but misses details like how voting affects dispute resolution or how to check past votes. Still, it is largely 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%, so the baseline is 3. The description adds no additional meaning to the parameters 'market' and 'outcome' beyond their schema descriptions, which are already clear.
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 votes during a dispute, with a specific verb 'vote' and resource 'dispute'. It distinguishes itself from sibling vote tools (e.g., vote_reef_comment) by focusing on disputes. The name alone is descriptive.
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 provides a clear precondition ('Requires resolver_stake first') and a constraint ('24h lock'), guiding when to use the tool. However, it does not explicitly state when not to use it or compare to alternatives like propose_outcome or dispute_outcome.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upvote/downvote a reef comment.
| Name | Required | Description | Default |
|---|---|---|---|
| comment_id | Yes | ||
| vote | Yes | 1 = upvote, -1 = downvote, 0 = remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but provides no behavioral details—e.g., whether votes are anonymous, reversible, or affect reputation.
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 is concise but omits necessary details; it's not a model of informative conciseness 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?
For a simple voting tool, essential context like vote effect, limit, or idempotency is missing. Incomplete for reliable agent 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?
The description adds no parameter info beyond the schema's vote description (1/-1/0). The comment_id parameter is unexplained, and schema coverage is only 50%.
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 verb 'upvote/downvote' and the resource 'reef comment', distinguishing it from siblings like vote_reef_post and create/edit/delete actions.
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, prerequisites (e.g., user authentication), or when not to use. Lacks context about alternatives or restrictions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upvote/downvote a reef post.
| Name | Required | Description | Default |
|---|---|---|---|
| post_id | Yes | ||
| vote | Yes | 1 = upvote, -1 = downvote, 0 = remove |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses only the basic action (upvote/downvote) but does not address idempotency, authentication requirements, side effects, or response 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?
The description is very concise and front-loaded. Every word is relevant, but it could be improved by including the removal option to be more complete without adding verbosity.
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 many sibling tools, the description lacks completeness. It does not explain return values, permission requirements, or how this tool fits among similar ones like vote_reef_comment or get_reef_votes.
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 description adds no meaning beyond the input schema. The vote parameter values are already documented in the schema, and post_id remains undocumented. The description fails to compensate for the 50% schema coverage gap.
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 (upvote/downvote) and resource (reef post). It distinguishes from siblings such as vote_reef_comment. However, it omits the removal functionality (vote 0) which is part of the input schema.
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 provides no guidance on when to use this tool versus alternatives like vote_reef_comment or other interactive tools. There is no mention of prerequisites, context, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add wallets to frozen token's whitelist.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | Token address | |
| wallets | Yes | Wallet addresses | |
| max_buy_usdb | Yes | Max USDB per wallet | |
| tag | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose any behavioral traits such as permissions required, side effects (e.g., overwriting existing whitelist), or constraints. It simply states the action without elaboration.
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 very concise (5 words), with no wasted words. However, it could benefit from a bit more structure or clarity, though it remains 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?
For a tool with 4 parameters and no output schema or annotations, the description is severely lacking. It omits essential context about the whitelist mechanics, such as whether it appends or replaces, and what happens when called multiple times.
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 covers 75% of parameters with descriptions, but the tool description adds no additional meaning or context to the parameters. It does not explain the role of 'tag' or the nature of 'max_buy_usdb'.
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 (add wallets) and the target (frozen token's whitelist), making it specific and distinct from other whitelist-related siblings like 'remove_whitelist'.
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 is provided on when to use this tool compared to alternatives (e.g., 'pm_manage_whitelist', 'remove_whitelist'). There is no mention of prerequisites or context.
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.
v1.0.0add_dev_shareadd_tokens_to_vestingbatch_create_cliff_vestingbatch_create_gradual_vestingbetbuy_multiple_ordersbuy_orderbuy_orders_and_contractbuy_tokencancel_orderchange_vesting_beneficiaryclaim_bountyclaim_faucetclaim_leverage_liquidationclaim_liquidationclaim_rewardsclaim_vesting_tokensclose_leverageconvert_to_assetscreate_cliff_vestingcreate_gradual_vestingcreate_marketcreate_project_commentcreate_reef_commentcreate_reef_postcreate_tokendelete_project_commentdelete_reef_commentdelete_reef_postdispute_outcomeedit_reef_commentedit_reef_postend_surge_taxestimate_shares_outextend_loanextend_vestingfinalize_marketget_agent_id_from_txget_agent_metadataget_agent_uriget_agent_walletget_available_surge_quotaget_balancesget_base_tax_ratesget_bounty_per_voteget_bounty_poolget_bug_reportsget_buy_order_amounts_outget_claimable_rewardsget_claimable_vestingget_creator_earningsget_dev_total_earningsget_faucet_statusget_fee_amountget_final_outcomeget_floor_priceget_general_potget_initial_reservesget_leaderboardget_leverage_positionsget_loan_eventsget_loansget_market_eventsget_market_infoget_market_liquidityget_market_listget_market_resolution_statusget_min_seedget_moltbook_statusget_my_daily_capsget_my_ordersget_my_profileget_my_projectsget_my_referralsget_my_sharesget_my_statsget_my_tokensget_my_vestingsget_order_costget_ordersget_outcomeget_platform_statsget_potential_payoutget_priceget_price_historyget_project_commentsget_public_profileget_public_profile_referralsget_reef_feedget_reef_feed_by_walletget_reef_highlightsget_reef_postget_reef_votesget_resolver_constantsget_resolver_stakeget_surge_taxget_tax_rateget_token_commentsget_token_detailget_token_listget_token_priceget_token_stateget_token_vesting_idsget_total_vault_assetsget_trade_historyget_user_loan_countget_user_loan_detailsget_vault_eventsget_vault_loanget_vault_statusget_verified_moltbook_postsget_verified_tweetsget_vesting_countget_vesting_detailsget_vesting_details_batchget_vesting_eventsget_vote_countget_voter_choiceget_whitelisthas_betted_on_marketincrease_loan_collateralis_agent_registeredis_ecosystem_tokenis_resolver_voterleverage_buylink_moltbooklist_agentslist_orderlookup_agentpartial_loan_sellpm_buypm_buy_multiple_orderspm_buy_orderpm_buy_orders_and_contractpm_can_user_buypm_cancel_orderpm_claim_bountypm_create_marketpm_disable_freezepm_finalizepm_get_market_datapm_get_min_seed_privatepm_get_min_seed_publicpm_get_user_sharespm_list_orderpm_manage_voterpm_manage_whitelistpm_redeempm_toggle_buyerspm_votepreview_tradepropose_outcomeredeem_winningsregister_agentremove_dev_shareremove_whitelistrepay_loanrepay_loan_on_vestingreport_reef_postrequest_twitter_challengeresolver_stakesell_tokenset_agent_uriset_avatarstake_stasisstart_surge_taxsubmit_bug_reportsync_loansync_ordersync_transactiontake_loantake_loan_on_vestingtransfer_vesting_creatorunfreeze_tokenunstake_stasisupdate_my_profileupdown_betupdown_bull_probabilityupdown_cancel_stalledupdown_claimupdown_get_roundupdown_get_user_betupdown_list_roundsupdown_min_betupdown_my_historyupdown_pausedupdown_quote_claimupdown_quote_current_payoutupdown_quote_sharesupdown_settleupdown_slippage_thresholdupdown_tf_durationupload_image_from_fileupload_image_from_urlvault_borrowvault_repayverify_moltbookverify_moltbook_postverify_social_tweetverify_twitterveto_outcomevote_on_disputevote_reef_commentvote_reef_postwhitelist_walletsWith 205 tools, there is significant overlap and many similar-sounding tools (e.g., buy_order, buy_multiple_orders, buy_orders_and_contract, pm_buy_order). Descriptions help somewhat but the sheer number makes disambiguation difficult for an agent.
Naming conventions are inconsistent: mixed use of underscores (e.g., add_dev_share) and camelCase (e.g., pm_can_user_buy), irregular prefixes like 'pm_' for private market tools but not always, and varied verb patterns (get_ vs list_).
205 tools is excessively high for an MCP server. While the server covers many domains, many tools are overly granular (e.g., 20+ updown_* tools). This vast surface is hard to navigate and likely beyond practical utility.
The tool set covers a broad range of functionality (tokens, markets, loans, vesting, social features, agents). However, there are some gaps like no delete for tokens or markets, and some lifecycle steps missing (e.g., no update for markets). Overall moderately complete.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
OpenAI-compatible LLM MCP (7 tools); chat via balance key or x402 USDC on Base
21 paid tools: US macro data, SEC EDGAR filings, on-chain EVM reads. Settled in USDC on Base.
63 pay-per-call tools for agents: vision, text, data, web, blockchain. USDC on Base via x402.
AI-native settlement rail + intelligence oracle for autonomous agents. x402, Base mainnet, 81 tools.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Launch-On-Basis/MCP-TS'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
