Agent tool exchange: pump.fun tape, token risk, wallets, tx decode, Meteora DLMM. Pay per call.
Scored across 75 tools
With 75 tools, there is a high degree of separation, but some overlap exists between crypto-related tools (e.g., crypto_price vs price, pump_pulse vs pump_history). Descriptions are clear enough to differentiate most tools, but the sheer number creates potential for misselection without careful reading.
All tools use snake_case and follow a general verb_noun pattern (e.g., address_check, chain_tvl). A few are single nouns (price, wiki) or slightly vague (smart_money), but the overall naming is consistent and predictable.
75 tools is far beyond the typical scope for a coherent server. While the broad purpose of a general-purpose utility toolkit is clear, the count is excessive and dilutes focus, making it harder for agents to select the right tool.
The server covers a wide range of domains (crypto, web, utilities, data) with reasonable depth, including both real-time and historical data, security checks, and conversion tools. Minor gaps exist (e.g., no email-sending or transaction submission), but the surface is largely complete for its stated purpose.
Is this a valid address, and for which chain? EVM (with checksum fix), Solana (on-curve wallet vs PDA), Bitcoin (legacy/P2SH/SegWit/Taproot), Tron, Cosmos-style bech32. Pure checksum and format validation, no network calls. Catches the typo that would send funds to nowhere, and tells a Solana wallet (on curve) from a program-derived address. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark it read-only, idempotent, and non-destructive. The description adds genuinely useful behavior beyond the annotations: it is pure checksum/format validation with no network calls, detects several chain types, and distinguishes Solana wallets from PDAs. This gives agents a clear safety and behavior 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 core purpose is front-loaded in the opening question and the chain list is compact. The benefit phrases ('catches the typo...', 'price: free') are slightly promotional but not bloated; every sentence adds some orienting 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 single-parameter, read-only validator, the description covers what it validates, which chains it supports, and that it makes no network calls. It doesn't specify the exact return shape (e.g., boolean plus chain name), but the stated question 'and for which chain?' strongly implies the output. Given the low complexity, this is nearly 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 schema only says 'address' is a required string with no description (0% coverage). The description compensates by explaining that the address may be an EVM, Solana, Bitcoin, Tron, or Cosmos-style address and that validation is format-only. It doesn't give examples or formatting details, but for a single obvious string parameter this 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 states a clear purpose: validate an address and identify its chain, listing EVM, Solana, Bitcoin, Tron, and Cosmos formats. It distinguishes itself from chain-specific siblings by advertising 'any chain', though it never explicitly names an alternative such as evm_address.
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 when to use it—when you need offline format/checksum validation across multiple chains—and says 'no network calls'. However, it gives no explicit when-not-to-use guidance or named alternative for chain-specific or network-dependent checks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search arXiv research papers by keywords, author or category — newest or most relevant — with abstracts, authors, dates and PDF links. arXiv's official API. query supports arXiv syntax (ti:, au:, abs:, cat:cs.AI, AND/OR). Paced to arXiv's one-request-per-3-seconds policy and cached, so repeated queries are instant. Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | relevance | |
| limit | No | ||
| query | Yes | e.g. "tool use agents" or au:hinton or cat:cs.CL AND ti:reasoning |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint. The description adds valuable context: arXiv's official API, the one-request-per-3-seconds pacing, caching for instant repeats, and the $0.001 cost per call (10 free/day). This goes beyond the annotations and informs the agent about operational 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 compact and front-loaded with the core purpose, then adds essential details (syntax, rate limit, caching, price) in logical order. No redundant sentences; every clause 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 moderate complexity (3 params, no output schema), the description covers the return content (abstracts, authors, dates, PDF links), the query language, the API source, and the operational policies (rate limit, caching, cost). Nothing an agent needs to decide whether to use it or construct a valid query is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is only 33% (only query has a description), but the description compensates by explaining the query syntax (ti:, au:, abs:, cat:cs.AI, AND/OR) and mentioning the sort options (newest or most relevant). This adds meaning beyond the bare parameter names, even though it does not detail the limit 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?
States a specific verb+resource: 'Search arXiv research papers' with clear scoping to keywords, author, or category, and mentions the output includes abstracts, authors, dates, and PDF links. It clearly distinguishes itself from sibling search tools like book_search or web_read by targeting the arXiv corpus.
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 and mentions the arXiv syntax and rate limit, but does not explicitly say when to use it versus alternatives or when not to use it. It implies usage via the topic, but lacks an explicit exclusion or routing to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Bitcoin right now: fee rates, mempool size, block height, next difficulty adjustment (% and ETA), hashrate. From mempool.space public API. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description usefully adds that data comes from the mempool.space public API and that it is free, which are relevant operational details, though it does not disclose rate limits, freshness guarantees, or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it immediately names the delivered metrics, then the data source and pricing. Every sentence adds information, and there is no filler, repetition, or unnecessary 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?
For a zero-parameter, read-only status tool, the description gives the essential invocation context: what metrics are returned and where they come from. It does not specify exact units or output format, but that is not critical for correctly selecting and invoking 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 tool has zero parameters and the schema explicitly reflects that by declaring no properties. The description does not need to explain parameter semantics, and none are hidden or undocumented, so the baseline of 4 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 lists the exact data returned (fee rates, mempool size, block height, next difficulty adjustment, hashrate), making the tool's purpose unmistakable. The 'Bitcoin right now' framing plus the title 'Bitcoin network status' clearly identifies this as a current network status fetcher, distinct from price, fear/greed, or other crypto siblings.
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 explicit guidance about when to choose this tool over alternatives. It does not mention when not to use it, nor does it route an agent to a sibling for historical data, price data, or other related needs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find books by title, author, subject or ISBN: first published year, editions, ISBNs, page count, ratings, subjects and cover image. Open Library (Internet Archive) catalogue of 30M+ titles. Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | title, author or ISBN |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the safety profile is covered. The description goes beyond annotations by naming the source catalogue, the return fields, and the cost/free-tier limit, which adds useful context. However, it does not describe pagination, result format, or behavior on no matches, leaving some behavioral 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 compact and front-loaded: it leads with the core search capability and return fields, then gives the source and pricing in a second sentence. The pricing detail is not strictly necessary for invocation but is still concise and informative. No filler 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?
For a simple read-only search tool with no output schema, the description covers the essential operational context: what can be searched, what data is returned, the catalogue source, and cost. It falls slightly short on explaining the shape or multiplicity of results, but the listed return fields and simple parameter set make the tool reasonably complete 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 only 50%, so the description must compensate. It adds 'subject' as a valid query dimension that the schema's query description ('title, author or ISBN') omits, expanding parameter semantics. The 'limit' parameter is not explained in the description, though its role is partially inferable from the schema's default and bounds.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Find books by title, author, subject or ISBN'. It then enumerates concrete return fields and names the data source (Open Library/Internet Archive), making the tool's identity and scope unmistakable and clearly distinct from sibling search tools like arxiv_search or hn_search.
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?
While it does not explicitly name alternative tools or exclusion criteria, the description makes the intended use case clear: search the Open Library catalogue for book metadata. The '30M+ titles' scope and the list of searchable keys give sufficient context for an agent to know when this tool is appropriate, though it does not explicitly say 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.
Live bid/ask/last, 24 h change, volume and range for a pair on Kraken, Coinbase and OKX side by side — with the cross-venue spread. Queries each venue's public ticker in parallel. OKX quotes in USDT when USD is asked for. The cross-venue spread shows arbitrage gaps and which venue is off. Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| pair | Yes | BTC/USD, ETH-USDT, SOL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only/idempotent safety, and the description adds useful behavior beyond that: parallel venue queries, OKX quoting USDT when USD is requested, and the cross-venue spread semantics. It does not reveal error handling or unsupported-pair behavior, but those are minor for a read-only ticker.
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?
Every sentence earns its place: returned data, execution behavior, OKX quote nuance, arbitrage use case, and cost. It is front-loaded with the most important output fields and stays compact despite covering several behavioral 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?
For a single-parameter read-only tool with no output schema, the description is complete enough to invoke correctly: it lists all returned metric groups, venue behavior, the pair semantics, and cost. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema already covers pair with examples at 100% coverage. The description adds valuable parameter-related meaning by clarifying how 'USD' is interpreted on OKX (USDT) and by explaining that the pair is requested across three venues at once.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what it returns (bid/ask/last, 24h change, volume, range) for a pair, names the three venues, and adds the cross-venue spread as a distinguishing feature. The 'Queries each venue's public ticker' sentence reinforces the verb, so it is clearly separable from price/price_history siblings.
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 conveys when to use it: when you need side-by-side multi-venue prices or want to spot arbitrage gaps via the cross-venue spread. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Total value locked on every blockchain right now, ranked — or one chain's daily TVL history. DefiLlama chain TVL. Without "chain": ranking of all chains with token symbol. With "chain": daily TVL history for up to 365 days plus 7 d / 30 d / 90 d change. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| chain | No | e.g. Solana, Ethereum, Base (optional) | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond that: the 365-day history limit, the 7/30/90-day change stats, and the fact that the tool is free. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, information-dense sentences. The main purpose is front-loaded, followed by mode-specific details and pricing. No filler or redundant 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?
With no output schema, the description carries the return-value burden and does convey the two output shapes: ranking with token symbols, or daily history with change stats. It does not spell out the exact structure of history entries or the meaning of 'limit', but for an optional-parameter read-only tool this 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 coverage is only 33%, and the description compensates by explaining that 'chain' switches between ranking and history modes. It also restates the days bound. However, 'limit' is left semantically unexplained in both the schema and description, so one parameter remains opaque.
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 what the tool does: it returns TVL rankings for all blockchains or daily TVL history for a single chain. It explicitly differentiates the two modes by the 'chain' parameter and is distinguishable from sibling tools like crypto_price or defi_protocol.
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 gives clear context on when to include the 'chain' parameter versus when to omit it, effectively instructing the agent on mode selection. It does not explicitly name alternative sibling tools or state when not to use this tool, so it misses the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Would copying this wallet have made money? Replays its pump.fun entries and exits 0–25 slots late on the recorded curve and shows where the edge dies. Takes the wallet's pump.fun positions over the last 1–14 days and simulates a copier that buys the same token and sells when the leader sells, arriving 0, 1, 2, 5, 10 or 25 slots (0–10 s) late. Fills use the bonding-curve reserves our tape recorded at that moment, including curve fees and the copy's own price impact. Returns PnL, win rate and ROI per latency, the leader's own median ROI for contrast, and a verdict: copyable, latency-sensitive (edge gone by N slots), or not copyable. A wallet that looks great on its own PnL often loses money for anyone who follows it. Price: $0.03 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| exit | No | sell on the leader's first sell, or once it has sold 90% | first_sell |
| wallet | Yes | leader wallet to copy | |
| size_sol | No | SOL per copied entry | |
| max_positions | No | most recent positions to replay |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only and idempotent annotations, the description discloses the simulation mechanics: latency slots, bonding-curve fills, curve fees, price impact, and the exact outputs including PnL, win rate, ROI per latency, and the copyability verdict. It also states the price and free quota, which is useful operational 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 dense but well organized: question, mechanics, fill assumptions, outputs, caveat, and pricing. A few phrases are somewhat redundant with the opening question, but each sentence carries useful information and the most important behavior 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?
For a tool with five parameters and no output schema, the description is remarkably complete. It explains what is simulated, how fills are priced, what results are returned, how to interpret the verdict, and the cost. An agent has enough to select and 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 coverage is high, so the baseline is 3, but the description adds meaningful simulation context: the 1–14 day window, the latency values, the 'sells when the leader sells' behavior, and the use of most recent positions. It does not explicitly walk through each parameter, but it enriches the schema's 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 opens with a concrete question and then states a specific verb and resource: it replays a wallet's pump.fun entries and exits with simulated latency. This clearly distinguishes it from sibling wallet-analysis tools like pump_wallet or smart_money by focusing on copy-trade profitability.
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 gives clear context for when to use the tool: when you want to know whether copying a wallet would have been profitable, including the warning that a wallet's own PnL can be misleading. It does not explicitly name alternatives or state when not to use it, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One-call verdict on a Solana wallet before you deal with it: serial token launcher, fast dumper, trading bot, or clean. Combines the wallet's pump.fun launch history (graduation rate, how fast it sells its own launches) with its trading profile into a risk level and reasons. Price: $0.005 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: it is a paid call ($0.005 per call, 10 free/day), combines launch history with trading profile, and produces a risk level and reasons. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with no redundancy: purpose and verdict categories, method and data sources, and pricing. The most important information is front-loaded, and 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?
For a single-parameter, read-only tool with no output schema, the description covers purpose, trigger condition, data sources, output summary (risk level and reasons), and cost. It does not specify the exact response format, but that is acceptable given the tool's simplicity and the annotations already covering safety. Slight gap: no explicit comparison to overlapping siblings, though purpose clarity mitigates 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 100% and the parameter is already documented as a 'wallet address' with a validation pattern. The description adds that the wallet is Solana-specific, which is minor additional context, but provides no new format or constraints beyond the schema. Baseline 3 applies because the schema carries the parameter 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 opens with 'One-call verdict on a Solana wallet before you deal with it' and enumerates concrete verdict categories (serial token launcher, fast dumper, trading bot, or clean). It also names the two data sources (pump.fun launch history and trading profile), making the tool's purpose specific and distinguishing it from siblings like wallet_holdings or 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 phrase 'before you deal with it' gives a clear usage trigger and context. However, it does not explicitly name alternatives or exclusion conditions, such as when a simpler tool like price or pump_wallet would be more appropriate. This is clear context but lacks comparative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Any country's essentials: capital, population, GDP and GDP per capita (World Bank), currencies, languages, calling code, internet TLD, time zones, driving side, borders, flag. Static facts from the world-countries dataset (no rate limits) plus the latest World Bank population and GDP figures. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | name or ISO code |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive behavior. The description adds valuable context: the data comes from the world-countries dataset with no rate limits, plus latest World Bank figures, and the tool is free. This tells the agent about data provenance, freshness, and operational constraints beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, leading with the full list of returned attributes before briefly noting data sources, rate limits, and pricing. Every sentence adds useful information with no filler 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?
For a single-parameter read-only lookup with comprehensive annotations and no output schema, the description is complete: it enumerates the response fields, states data sources and limitations, and clarifies the tool is free. An agent has enough context to decide whether and how to invoke 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 already describes the single parameter as "name or ISO code" with 100% schema description coverage, so the baseline is 3. The description does not add further parameter-specific details such as accepted formats or examples, but it does imply the country must be a valid country name or ISO code through the phrase "Any country's essentials."
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 as returning comprehensive country facts, listing specific fields such as capital, population, GDP, currencies, languages, calling code, TLD, time zones, driving side, borders, and flag. This makes the tool's function explicit and distinguishes it from any sibling tool, none of which are country fact lookups.
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 phrase "Any country's essentials" provides a clear use case: fetch broad static and economic facts for any country. It implies when this tool should be chosen, though it does not explicitly state when not to use it or name alternative tools. Given the sibling list contains no comparable country-facts tool, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain a cron expression in plain English and list its next N run times in any time zone — catch a schedule mistake before it fires at 3 am. Supports 5-field and 6-field (seconds) cron, ranges, steps, L/W/#, and nicknames (@daily, @hourly…). Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | UTC | |
| count | No | ||
| expression | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly, openWorld, idempotent, and non-destructive behavior, so the description need not repeat those. It adds meaningful behavior: output includes a plain-English explanation plus next run times, with time-zone handling and supported syntax features. Edge-case behavior is not mentioned, but that is minor for a read-only utility.
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 front-loaded: purpose, use case, then supported features. The 'Price: free' sentence adds little, but the rest is tight and scannable 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?
For a simple read-only tool with three parameters and no output schema, this description supplies the purpose, output shape, supported syntax, and time-zone behavior. An agent has enough information to select and invoke cron_explain 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 0% schema description coverage, the description carries the parameter burden. It communicates that expression is a cron string, tz is 'any time zone', and count controls 'next N run times'. It does not document defaults, constraints, or IANA time-zone format, but the core parameter meanings are 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 opens with a concrete verb-object pair: 'Explain a cron expression in plain English and list its next N run times.' It also specifies supported cron variants and extensions, making the tool unmistakable among siblings like tx_explain or time_convert.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear practical context—'catch a schedule mistake before it fires at 3 am'—and states the core use case of validating and understanding cron schedules. It does not explicitly name alternatives or exclusions, but no sibling covers cron semantics, so the implied guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live USD price and 24 h change for up to 30 crypto assets on any chain — by symbol, CoinGecko id, contract or mint address. Resolves each asset (BTC, "coingecko:ethereum", "base:0x…", a bare 0x address with chain, or a Solana mint) and prices it from DefiLlama's aggregated oracle (confidence score included). Symbols resolve against the top 1,000 coins by market cap first, so "USDC" means the real one; ambiguous symbols list the alternatives. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | EVM chain: ethereum, base, arbitrum, optimism, polygon, bsc, avalanche, linea, blast, scroll, gnosis, sonic, unichain, mantle, berachain, hyperevm, monad | ethereum |
| assets | Yes | e.g. ["BTC","ETH","coingecko:solana","base:0x833589fcd6edb6e08f4c7c32d4f71b54bda02913"] |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, and non-destructive, which lowers the bar. The description adds substantial behavioral detail: how assets resolve (symbol, coingecko id, contract, mint), the use of DefiLlama's aggregated oracle, inclusion of a confidence score, and the top-1000 market cap symbol resolution with alternatives for ambiguous symbols. This is rich, non-redundant 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 compact yet information-dense. It front-loads the core purpose, then methodically details resolution logic, symbol handling, and pricing source, finishing with cost. Every sentence contributes new information without padding, and the structure flows logically from what to how.
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 read-only price tool with no output schema, the description adequately covers inputs and gives an impression of outputs (price, 24h change, confidence score, alternatives for ambiguous symbols). It does not specify the exact JSON return structure or behavior for unresolvable assets, but these are minor given the annotation safety and 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?
Schema descriptions are 100% covered, setting a baseline of 3. The description goes far beyond by explaining the exact string formats for assets (e.g., 'coingecko:ethereum', 'base:0x...', bare 0x with chain, Solana mint) and the chain parameter's role in disambiguating addresses. It also clarifies the max 30 limit and how symbols resolve, making both parameters intuitively 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 explicitly states the tool fetches live USD price and 24h change for up to 30 crypto assets, across any chain, using multiple identifier formats. It clearly distinguishes from sibling tools like 'price' and 'price_history' by emphasizing cross-chain capability and identifier resolution, 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 provides strong context for when to use it (any chain, multiple identifier types, ambiguous symbol handling) but does not explicitly name alternatives or state when not to use it. It implies use cases via the resolution logic and oracle mention, but lacks explicit exclusion guidance such as 'for single-chain simple quotes use X'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One DeFi protocol in depth: TVL by chain, TVL trend, fees and revenue (24 h/7 d/30 d), market cap, audits, links. Look up by name or DefiLlama slug ("aave", "Uniswap", "jupiter"). Combines DefiLlama's protocol list with its fees/revenue summaries. Fuzzy name matches return the best match plus close alternatives. Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| protocol | Yes | name or slug |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive. The description adds valuable context: fuzzy name matching returns best match plus close alternatives, and it discloses the price ($0.002 per call) and free tier. This goes beyond annotations and helps the agent assess cost.
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?
Concise five-sentence description. Front-loaded with the core purpose and data fields, then usage details, then pricing. 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 single-parameter read-only tool, this is quite complete. Lists what data is returned, how to input the parameter, and pricing. Does not specify output format or error cases, but the data fields and fuzzy matching cover most agent needs. With no output schema, it could benefit from a note on response structure, but it's 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 has 100% coverage with 'name or slug' for the protocol parameter. The description elaborates with examples ('aave', 'Uniswap', 'jupiter') and explains the slug concept (DefiLlama slug), adding practical guidance. Also explains fuzzy matching behavior for the 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?
States exactly what it does: 'One DeFi protocol in depth' and enumerates specific data points (TVL by chain, trend, fees/revenue, market cap, audits, links). Distinct from siblings like defi_rankings or chain_tvl by focusing on a single protocol.
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?
Clearly implies when to use: for a single protocol's comprehensive profile. Mentions lookup by name or slug and fuzzy matching, but does not explicitly exclude other tools or state alternatives. Still, the context is clear enough for an agent to choose this over broader tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Top DeFi protocols by TVL (or 1 d / 7 d TVL change), filterable by chain and category — lending, DEX, liquid staking, bridges, perps… From DefiLlama's full protocol list (~6,000 protocols). Each row: TVL, TVL on the requested chain, 1 h/1 d/7 d change, market cap, category, chains, site. Use for "biggest lending protocols on Base" or "fastest growing DEXes this week". Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | tvl | |
| chain | No | DefiLlama chain name, e.g. Ethereum, Solana, Base, Arbitrum (optional) | |
| limit | No | ||
| category | No | e.g. Lending, Dexs, Liquid Staking, Bridge, Derivatives, Yield, CDP, RWA (optional) | |
| min_tvl_usd | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only/idempotent and non-destructive, and the description adds useful context: the data source, protocol count, output row fields, and the fact that it is free. It stops short of describing pagination or response format details, but the annotations cover the safety profile well.
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?
Four tight sentences pack the core behavior, filtering options, output row fields, example uses, and cost into a compact description. It is front-loaded with the main purpose and contains no filler.
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 compensates by enumerating exactly which fields appear in each row and stating the data source and scope (~6,000 protocols). All parameters have defaults or enums, and the examples anchor correct usage, so an agent has enough to call this 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 clarifies sort semantics ('by TVL (or 1 d / 7 d TVL change)') and gives concrete chain/category examples, adding value beyond the schema. However, schema description coverage is only 40% and the description does not mention min_tvl_usd or limit, so the agent has to infer their behavior from names/defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource (Top DeFi protocols from DefiLlama) and a clear ranking/filtering action ('by TVL or 1 d / 7 d TVL change', 'filterable by chain and category'). It also gives concrete queries like 'biggest lending protocols on Base', which distinguishes this list-oriented tool from per-protocol or chain-level siblings.
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 provides explicit use-case examples ('biggest lending protocols on Base', 'fastest growing DEXes this week'), so an agent knows what kinds of questions this tool answers. It does not explicitly mention when to prefer a sibling tool like defi_protocol or chain_tvl, hence no exclusions/alternatives guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
DEX trading volume in the last 24 h / 7 d / 30 d — all chains or one — with the top DEXes and their share and change. DefiLlama DEX overview. Optionally scoped to one chain. Includes perps with type=perps (derivatives volume) or aggregators. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | dexs | |
| chain | No | e.g. Solana, Base (optional) | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Given the annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, the description adds useful behavioral context: it specifies the data source (DefiLlama), timeframes (24h/7d/30d), output characteristics (top DEXes, share, change), and pricing (free). It doesn't repeat annotation data, so this is valuable additional 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 compact and front-loaded with the core purpose. The extra details (source, price, optional scoping) are relevant, but the confusing phrasing around 'perps' and 'derivatives volume' slightly undermines clarity. Still, the overall structure is efficient and free of excess.
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 provides a good overview of what the tool returns (top DEXes, share, change, timeframes, chain scope), which is helpful given there is no output schema. However, it omits the limit parameter semantics and gives an inaccurate type value, leaving gaps in the information an agent needs to make a fully informed call.
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 some meaning for the type parameter (derivatives volume, aggregators) and chain (optional scoping), but it introduces a critical mismatch: it says 'type=perps' while the schema enum uses 'derivatives', which can mislead an agent into sending an invalid value. It also completely omits the 'limit' parameter, and with schema coverage at only 33%, the description fails to adequately compensate for the undocumented 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 retrieves DEX trading volume rankings with specific timeframes, chain scoping, and output details (top DEXes, share, change). It distinguishes itself from siblings like cex_ticker or price by naming the resource (DEX volume) and data source (DefiLlama), making it easy for an agent to tell apart.
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 gives clear context on when to use the tool (DEX volume queries) and how to scope it (by chain, type). It doesn't explicitly exclude alternatives or name neighboring tools, but the specificity of the purpose makes usage conditions reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
State of a Meteora DLMM pool: price, bin step, fees, TVL, volume and fees by window (30 m–24 h), 24 h fee yield and its annualized APR/APY. For LP agents choosing where to provide liquidity. Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| pool | Yes | DLMM pool (pair) address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful cost/rate-limit context ('$0.002 per call (10 free/day)') and details the snapshot-like 'State' nature of the returned data. No contradiction with annotations exists.
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 filler. The first sentence front-loads the most important content, the second provides usage context, and the third gives cost/free-tier information. 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?
For a simple one-parameter read-only tool with no output schema, the description is complete: it enumerates all the major returned metrics, states the intended use case, and mentions cost/rate limits. An agent has enough information to select and invoke it correctly without additional 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 100% and the single 'pool' parameter is already described as 'DLMM pool (pair) address' with a validating regex. The description does not add new parameter-level semantics, but with full schema coverage there is no meaningful gap to compensate for.
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 exactly what the tool provides ('State of a Meteora DLMM pool') and enumerates the specific data returned: price, bin step, fees, TVL, volume, fee yield, and APR/APY. It also signals the intended audience ('LP agents choosing where to provide liquidity'), which helps distinguish it from sibling tools like dlmm_positions or dlmm_whales.
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 phrase 'For LP agents choosing where to provide liquidity' gives a clear when-to-use context that differentiates this from position-tracking or whale-tracking tools. However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open Meteora DLMM positions of any wallet: value, unclaimed fees, PnL, in/out of range — or its closed-position history. Set history=true for closed positions with deposits, withdrawals, fees and PnL per pool. Price: $0.005 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| wallet | Yes | wallet address | |
| history | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, open-world, and non-destructive. The description adds cost per call and free tier, and lists the returned data fields (value, fees, PnL, range, history details), which goes beyond the annotations. It does not conflict with 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?
Two sentences, front-loaded with the main capability, followed by the history option and pricing. No fluff; each sentence provides 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 output schema, the description sufficiently explains what data is returned and how to request closed positions. Coverage of pricing and free tier adds operational context. The only minor gap is explicit pagination instructions, but schema defaults handle that.
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 only wallet with a description; description compensates by explaining history=true for closed positions, but does not elaborate on page beyond its schema default. It adds meaning for the history parameter, partially offsetting 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 retrieves Meteora DLMM positions for any wallet, listing specific data points (value, fees, PnL, range) and closed-position history. It distinguishes itself from siblings like dlmm_pool by focusing on wallet positions rather than pool-specific 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 implies usage for wallet position queries but does not explicitly state when to prefer this over dlmm_pool or dlmm_whales. It mentions history=true for closed positions, but does not provide exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Meteora DLMM liquidity providers ranked by measured on-chain edge: net USD, median multiple, win rate, hold time, size, recency. Produced by our own discovery engine, which decodes DLMM liquidity instructions across high-volume and high-yield pools every few hours and scores each wallet's completed round trips. These are the wallets our live copier watches. Price: $0.02 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the safety profile is clear. The description adds meaningful behavioral context: data is produced by a discovery engine running every few hours, it decodes DLMM liquidity instructions and scores completed round trips, and it includes pricing/rate-limit details (10 free/day). This goes beyond what annotations alone provide.
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 with no filler: the first front-loads the tool's purpose and ranking metrics, the second explains the data source and methodology, and the third conveys relevance and pricing. 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?
For a simple read-only ranked list with one optional parameter, the description is nearly sufficient: it specifies ranking dimensions, data provenance, freshness, and pricing, while annotations cover safety. It doesn't describe the output shape, but there is no output schema and the ranked metrics make the return intent clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'limit' parameter is well constrained in the schema (default 10, min 1, max 25), but the description never mentions it. With schema description coverage at 0%, the description does not compensate by explaining what the parameter controls or how to choose a 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 names the resource ('Meteora DLMM liquidity providers') and the primary behavior (ranked by measured on-chain edge) with an explicit list of ranking metrics. It lacks an explicit verb like 'list' or 'get' and doesn't name sibling tools to differentiate, but the ranking intent is unmistakable.
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 useful context about provenance and relevance ('These are the wallets our live copier watches'), but it never states when to use this tool versus siblings like dlmm_pool, dlmm_positions, or smart_money. No alternatives or exclusions are mentioned, so usage guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All DNS for a domain — A, AAAA, CNAME, MX, NS, TXT, CAA, SOA — plus SPF and DMARC parsed and graded, so an agent knows where a domain points and whether its email can be spoofed. Queried live against public resolvers (Cloudflare, Google, Quad9). Email grade: SPF present and ending in -all/~all, DMARC present with p=quarantine/reject. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only/idempotent, but the description adds meaningful behavioral detail: queries are made live against Cloudflare, Google, and Quad9, and the email grading logic is specified precisely. This goes well beyond what annotations provide.
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, each earning its place: what is returned, how it is queried, and the grading criteria. The most important information is front-loaded, and there is no redundancy with the schema or annotations.
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 one-parameter read-only tool with rich annotations and no output schema, the description fully covers input, record types returned, grading behavior, live resolution sources, and pricing. Nothing an agent needs to call it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema only says 'domain' is a required string with no description, so the description must compensate. It does by clarifying that the input is a domain whose DNS records are fetched. While it doesn't specify formatting examples, the single parameter is unambiguous enough 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 names the exact resource (all DNS record types plus SPF/DMARC) and the outcome the agent can expect: knowing where a domain points and whether email can be spoofed. This clearly distinguishes it from siblings like domain_whois or tls_check by scope and output.
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 gives clear context for when to call it: whenever domain infrastructure or email spoofability is in question. It does not explicitly name alternatives or state when not to use it, but the use cases are concrete enough for an agent to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Resolve a DOI — or search a paper title — to full citation metadata: title, authors, journal, year, citations count, publisher, license, and a ready-made APA/BibTeX citation. Crossref's open metadata (150M+ works). Search mode returns the top matches for a title/author query. Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| doi | No | e.g. 10.1038/nature14539 | |
| limit | No | ||
| query | No | title/author search instead of a DOI |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive behavior. The description adds valuable context beyond annotations: the Crossref open metadata source, search mode behavior, and pricing/free-tier details. No contradiction with annotations exists.
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 and front-loaded, with every sentence earning its place. It states the core action and output, then the search mode, and finally pricing. No redundant phrasing or filler.
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 largely complete for a simple read-only lookup tool: it lists return fields, explains the search mode, and covers cost. It does not explicitly describe the limit parameter's effect or error behavior, but these are minor given the schema and 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?
The schema already documents doi and query, including an example for doi. The description reinforces that query is a title/author search but adds little about the limit parameter, which lacks a schema description. With 67% schema coverage, the description partially supplements but does not fully clarify all 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 uses a specific verb and resource: 'Resolve a DOI — or search a paper title — to full citation metadata' and enumerates the exact output fields. It clearly differentiates from sibling tools like arxiv_search and book_search by focusing on DOI/citation resolution via Crossref.
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 clearly indicates when to use the tool: for DOI resolution or title/author search, with search mode returning top matches. It does not explicitly name alternatives or when-not-to-use cases, but the intended usage context is clear and not misleading.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Who registered a domain and when: registrar, creation/expiry dates, age, days to expiry, status locks, nameservers — or that it looks available to register. Uses RDAP, the registries' official successor to WHOIS (rdap.org bootstrap). A domain with no RDAP record and no DNS is reported as likely available. Young domains (< 30 days) are flagged: most phishing/scam sites are days old. Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| domain | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/openWorld/idempotent, and the description adds real behavioral detail: data source, availability heuristic, phishing/risk flag for domains under 30 days, and per-call cost. This is exactly the kind of added context the dimension is looking for, with no contradiction.
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?
Every sentence earns its place: output fields, data source, availability logic, risk heuristic, and pricing. The core answer is front-loaded and no structural information from the schema or annotations is repeated.
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, but the description lists the key returned data points and the availability verdict, plus important interpretation caveats and cost. For a single-parameter, read-only lookup, an agent has enough to call it correctly and interpret its 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?
Schema coverage is 0% and the description does not explicitly specify domain format (e.g., no protocol, no path). However, with a single required string parameter named 'domain', the intended input is fairly self-evident from the schema and the surrounding domain-focused prose, so it barely compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a clear verb-resource promise: report who registered a domain and when, with registrar, dates, age, expiry, status locks, nameservers, or availability. This distinguishes it from DNS/network siblings and goes well beyond merely restating the tool name.
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 concrete context: RDAP is the registries' official WHOIS successor, availability is inferred when no RDAP record and no DNS exist, and young domains are flagged as risky. It does not explicitly name alternative tools or exclusion conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Earthquakes worldwide from the last hour to 30 days, filtered by minimum magnitude and optionally within a radius of a place — with depth, tsunami flag and USGS alert level. USGS real-time earthquake feeds (updated every minute). Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| near | No | place or lat,lon (optional) | |
| limit | No | ||
| period | No | day | |
| radius_km | No | ||
| min_magnitude | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior, so the description doesn't need to repeat that. It adds valuable behavioral context: data is updated every minute and the service is free, which informs expectations about freshness and cost. No contradictions with 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 two sentences, concise and front-loaded with the main functionality. It includes the data source, update frequency, and cost without fluff. 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?
The description covers time range, filters, output fields, data source, and freshness. However, it does not explain the response format or pagination, and the time range phrasing 'last hour to 30 days' is not aligned with the actual period enum, which could mislead an agent. It also doesn't mention that limit defaults to 20 or caps at 100, though those are in the schema. Overall adequate but with notable 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 coverage is only 20%, so the description must compensate. It explains the purpose of 'near' (place or lat,lon), 'radius_km' (within a radius of a place), and 'min_magnitude' (minimum magnitude filter). It hints at 'period' via 'last hour to 30 days', but that wording is ambiguous and doesn't match the enum values (hour/day/week/month) precisely. 'limit' is not explained at all. It partially compensates but leaves 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 identifies the tool's purpose: it returns earthquake data worldwide, filtered by magnitude and optional location radius, with depth, tsunami flag, and alert level. The verb is implicit but the resource and scope are explicit, and there are no similar sibling tools to confuse it with.
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 provides clear context: the tool is for querying recent earthquake data from USGS, with time ranges from the last hour to a month. It implies usage for seismic activity lookups, and since no siblings are similar, explicit exclusions are unnecessary. The mention of 'USGS real-time feeds' and 'free' adds practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Will this email address work? Syntax, domain MX records, disposable/throwaway provider detection, role address (info@, admin@) and free-mail provider — without sending anything. No SMTP probing (that gets servers blacklisted); the verdict is from syntax, live MX lookup and a maintained list of ~100k disposable domains. Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnlyHint=true, idempotentHint=true), the description discloses critical operational behaviors: it performs no sending, uses a maintained list of ~100k disposable domains, does live MX lookup, and has a cost of $0.001 per call with 10 free/day. These details are not available in the annotations and materially affect invocation decisions, such as cost and safety.
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 sentences, each serving a distinct purpose: stating the core question and checks, explaining the no-SMTP behavior and rationale, and providing cost information. It is slightly longer than the minimal necessary but contains no filler; the primary purpose is front-loaded. It earns a 4 rather than 5 because the price detail, while useful, could be considered tangential to 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?
Given the tool has one simple parameter and no output schema, the description covers the essential context: what the tool does, how it operates, its limitations, and its cost. The only gap is that the description mentions a 'verdict' but does not describe the return format or whether detailed breakdowns are provided. This is a minor gap for a check tool but prevents a perfect score.
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 only a 'email' string with 0% description coverage. The description fully compensates by clarifying that the parameter is the email address to be evaluated, and it explains the semantics of the check (syntax, MX, disposable, role, free-mail). This gives an agent complete understanding of what the single parameter means.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear question, 'Will this email address work?', and enumerates exactly what is checked (syntax, MX records, disposable/throwaway providers, role addresses, free-mail providers). It also distinguishes the tool from others by explicitly stating it does not send anything and avoids SMTP probing, setting it apart from sibling tools like dns_lookup and domain_whois.
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: you would use this tool to assess if an email address is likely deliverable without sending mail. It also explains why SMTP probing is avoided (blacklist risk), implying this tool is safe for bulk validation. However, it does not explicitly name alternatives or state when not to use this tool, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ENS name → address and address → primary name, with avatar, twitter, github, url and email text records. Reads ENS on Ethereum mainnet (forward resolution verified; reverse lookup confirmed by forward-resolving the name). Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | vitalik.eth or 0x address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety. The description adds the mainnet scope, verification process, and price (free), which are useful but not extensive. No contradiction.
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 that front-loads the core functionality, then adds necessary details. 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 single-parameter tool with no output schema, the description is fully complete. It explains the operation, scope, verification method, and what records are returned. The annotations cover safety, so nothing is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a description for the single parameter, but the description adds specificity by giving examples (vitalik.eth or 0x address) and clarifying accepted formats, going beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it resolves ENS names to addresses and reverse, and includes text records. It uses a specific verb+resource and distinguishes from sibling tools like domain_whois and dns_lookup by focusing on ENS-specific 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?
While it doesn't explicitly name alternatives, it implies when to use this tool by specifying it reads ENS on Ethereum mainnet and describing the resolution logic. The context is clear, but 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.
Name, symbol, decimals, total supply and USD price of any ERC-20 — plus a wallet's balance of it — read on chain. Direct contract calls (name/symbol/decimals/totalSupply/balanceOf) on the chosen EVM chain, priced via DefiLlama. Works for any token, listed or not. Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | EVM chain: ethereum, base, arbitrum, optimism, polygon, bsc, avalanche, linea, blast, scroll, gnosis, sonic, unichain, mantle, berachain, hyperevm, monad | ethereum |
| token | Yes | ||
| wallet | No | optional holder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the read-only nature is covered. The description adds valuable behavioral context: it performs direct contract calls on the chosen EVM chain, prices via DefiLlama, works for any token (no whitelist), and discloses cost ($0.002 per call, 10 free/day). This exceeds annotation coverage without contradicting it.
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-load the outputs and wallet balance, then explain the mechanism and pricing. Every sentence earns its place; no fluff. The structure is efficient, though pricing details are placed secondarily rather than in a dedicated section. Still appropriately 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 read-only tool with 3 parameters and no output schema, the description covers purpose, method, scope, and cost. It does not specify return format (e.g., decimals vs raw balance) or potential errors, but these are minor given the clear list of outputs. Annotations cover safety, so the overall context is 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 67%: token has no description (only pattern), chain has enum description, wallet says 'optional holder'. The description clarifies that the wallet parameter provides a balance, and that chain determines the EVM network, but it does not elaborate on token semantics beyond the pattern. It adds some value but leaves token meaning implicit.
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 reads name, symbol, decimals, total supply, USD price, and optional wallet balance of any ERC-20 token. It specifies the verb 'read' and the resource, and lists the exact fields. This distinguishes it from siblings like crypto_price (price only) and wallet_holdings (all holdings), making its purpose unmistakable.
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 it works for any token, listed or not, and that it reads on chain with direct contract calls. However, it does not explicitly contrast with alternatives like crypto_price or wallet_holdings, nor does it state when NOT to use it. The context is clear but exclusionary guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Native balance (with USD), transaction count, contract or wallet, ENS name — for any address on 17 EVM chains at once or one chain. Reads straight from each chain's RPC. chain="all" checks every supported chain in parallel and returns only where the address has balance, transactions or code — the quick "where is this wallet active" answer. Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | all | |
| address | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, but the description adds valuable behavioral detail: it 'reads straight from each chain's RPC' (network access), performs parallel checks on all chains, and returns only active chains. It also discloses pricing ($0.002 per call, 10 free/day), which is a cost implication not covered by annotations. No contradictions with 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, information-dense sentence that front-loads the core purpose and data returned, then details the chain="all" behavior and pricing. It wastes no words but is slightly long; however, every clause adds value. The structure flows logically from function to usage nuance to cost.
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 clearly lists the return items (balance with USD, transaction count, contract/wallet status, ENS name). It also covers usage nuances (all vs. specific chain) and cost. It omits error handling or rate limits, but for a read-only lookup with strong annotations, this is adequate. The main missing piece is a note on address format validation, though the schema's pattern covers that.
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 parameters. It explains 'chain' thoroughly: '17 EVM chains at once or one chain' and the specific behavior of chain="all" (parallel checks, returns only active chains). The 'address' parameter is implicit from context (the target of the lookup) and the schema's regex pattern. It does not enumerate the chain list, but the enum covers that. This compensates well for the 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 tool's function: 'Native balance (with USD), transaction count, contract or wallet, ENS name — for any address on 17 EVM chains at once or one chain.' It names the specific data returned and the resource (EVM address), distinguishing it from siblings like ens_resolve (ENS-only), evm_tx (transactions), and evm_token_security (security checks). The scope (17 chains) and the dual mode (all or one) are 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 explains the key usage decision: 'chain="all" checks every supported chain in parallel and returns only where the address has balance, transactions or code — the quick "where is this wallet active" answer.' This clarifies when to use the default all-mode versus a specific chain. However, it does not explicitly mention alternatives (e.g., ens_resolve for ENS-only) or when NOT to use this tool, though the sibling context makes it inferable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Honeypot and scam check for any ERC-20 on 15+ EVM chains: buy/sell tax, can the owner mint, pause, blacklist or change taxes, proxy, holder concentration, LP lock. GoPlus Security token analysis plus a plain verdict. Flags are the ones that actually drain buyers: honeypot (cannot sell), sell tax above 10%, hidden owner, owner can modify balances or taxes, trading cooldown, blacklist, self-destruct. Top holders and LP holders with lock status included. Price: $0.005 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | EVM chain: ethereum, base, arbitrum, optimism, polygon, bsc, avalanche, linea, blast, scroll, gnosis, sonic, unichain, mantle, berachain, hyperevm, monad | ethereum |
| token | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive, and the description does not contradict those. It adds useful behavioral detail beyond annotations by enumerating the buyer-draining flags, the inclusion of top holders and LP lock status, and the per-call pricing. It stops short of describing edge cases like invalid tokens or chain mismatches, but the safety profile is fully covered by annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences front-load the core purpose, then give decision-relevant output details and cost, with no filler or repetition of schema content. The flag list is long but each item is meaningful for security triage, so every part of the description 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?
For a tool without an output schema, the description covers what is checked, what output artifacts are included (flags, top holders, LP lock status, verdict), and the operational cost. The main remaining gaps are the absence of explicit verdict value examples and error behavior, but the context is still strong enough for an agent to select and 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 schema already documents chain via a 17-value enum with a default and token via a strict address pattern. The description adds that the target is an ERC-20 contract on supported EVM chains, which helps frame the token parameter, but it does not meaningfully explain the relationship between token and chain or add per-parameter semantics beyond the schema. With 50% schema description coverage, the description only partially compensates.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a concrete verb-object pair ('Honeypot and scam check for any ERC-20') and then lists specific risk dimensions such as buy/sell tax, mint, pause, blacklist, and LP lock. It also names the upstream data source, GoPlus Security, and the 'plain verdict' feature, making the tool's purpose unambiguous and distinguishable from generic ERC-20 or price 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 clearly frames when this tool is relevant: security/honeypot analysis for any ERC-20 on supported EVM chains. It does not explicitly contrast with sibling tools like token_risk or erc20_info, so there is no when-not-to-use guidance, but the intended use context is strong and unmistakable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Any EVM transaction in plain terms: status, from/to, value, fee in native and USD, method called, every ERC-20 transfer decoded with symbols and amounts. Fetches the transaction and receipt from the chain, decodes ERC-20 Transfer events (token symbols/decimals read on chain), and prices the fee. Price: $0.003 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| hash | Yes | ||
| chain | No | EVM chain: ethereum, base, arbitrum, optimism, polygon, bsc, avalanche, linea, blast, scroll, gnosis, sonic, unichain, mantle, berachain, hyperevm, monad | ethereum |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes beyond the annotations, explaining that the tool fetches the transaction and receipt from the chain, decodes ERC-20 Transfer events using on-chain symbols/decimals, and prices fees. It also discloses the per-call cost. This is meaningful behavioral context not available from the readOnlyHint/idempotentHint annotations alone. It doesn't cover edge cases like failure modes, but the core behavior is well 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 compact and efficiently structured: it opens with the primary output summary, follows with the underlying mechanics, and closes with pricing. Every sentence adds useful information, and there is no filler or repetition of the tool title. The content is front-loaded so an agent can quickly determine what the tool returns.
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 only two parameters, robust annotations, and no output schema, this description is complete. It states the output contents, the chain-fetching behavior, ERC-20 decoding, fee pricing, and cost. An agent has enough context to select and invoke the tool correctly without additional 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?
The input schema already describes the chain parameter with an enum and default, and the hash parameter has a strict pattern. The description adds little direct parameter-level explanation: it implies the transaction is identified by hash but never names the parameter. With schema coverage at 50%, this is acceptable for two simple parameters, but the description does not substantially compensate for the undocumented hash parameter beyond the pattern.
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 and resource: it explains an EVM transaction, listing clearly what the output contains (status, from/to, value, fees in native/USD, method, and decoded ERC-20 transfers). This gives an agent a precise idea of what the tool does without needing to inspect sibling tools. While it does not explicitly name a sibling such as tx_explain, the detailed scope makes 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?
The description gives clear context for when to use the tool: for any EVM transaction that needs plain-language explanation and decoded ERC-20 transfers. It lacks explicit exclusions or named alternatives, but the phrase 'Any EVM transaction' combined with the detailed return content effectively establishes the intended use case. The cost disclosure also helps the agent decide whether to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The Crypto Fear & Greed Index (0–100) now and its history, with the 7 d / 30 d average and how extreme today is. alternative.me index, daily. Up to 365 days of history. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: it specifies the data scope (up to 365 days of history), the averages calculated (7d/30d), the extremity classification, and that the service is free. This goes beyond what annotations provide and helps the agent understand the returned data.
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 short, information-dense sentences with no redundancy. It front-loads the core function (index value and history), then adds source, frequency, and cost. Each sentence contributes new, non-overlapping information, and there is no filler.
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 one optional parameter and no output schema, the description adequately explains what the agent will receive: current index, historical values, 7/30-day averages, and extremity classification. It also notes the data source and update frequency. While it does not specify the exact response format (e.g., JSON structure), it covers the essential content an agent needs to decide and call 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 schema has zero description coverage for the single 'days' parameter, so the description must compensate. It mentions 'Up to 365 days of history', which implies the 'days' parameter controls the history length, but it does not explicitly state that 'days' is the number of days to include. This provides a helpful hint but leaves the mapping implicit, so it's not fully explicit.
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 explicitly names the resource (Crypto Fear & Greed Index), the value range (0–100), and the specific outputs (current value, history, 7/30-day averages, extremity classification). This clearly distinguishes it from any sibling tool by stating exactly what data is provided. The verb is implied ('provides' or 'retrieves'), but the purpose is 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 gives clear context about the tool's function, data source (alternative.me), and update frequency (daily). It does not explicitly mention when to use it vs alternatives or provide exclusions, but since no sibling tool serves the same index, the usage is well-implied. It lacks explicit 'when not to use' guidance, which prevents a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Which protocols and chains earn the most: fees or revenue over 24 h / 7 d / 30 d, filterable by chain — the cash-flow view of crypto. DefiLlama fees/revenue overview. "fees" = what users paid; "revenue" = what the protocol kept. Ranked, with day-over-day change. Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| chain | No | optional | |
| limit | No | ||
| metric | No | fees |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, covering safety. The description adds valuable behavioral details: pricing per call, a free daily quota, ranking with day-over-day change, and the semantics of fees vs revenue. These go beyond the annotations and inform the agent about cost and output 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?
The description is moderately sized and front-loaded with the core purpose. It defines key terms and includes cost info, all in a readable format. A minor redundancy is the metaphorical 'cash-flow view' but it adds flavor without bloat. Overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description should describe the response structure; it mentions 'Ranked, with day-over-day change' but not the exact shape. The time period selection is ambiguous since no parameter exists, and 'limit' is not explained. It covers the main query intent but leaves several operational details unclear for a tool with only 3 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 only 33% (chain just says 'optional'). The description explains 'chain' and 'metric' (fees/revenue) but does not explain 'limit' or clarify that time ranges (24h/7d/30d) are not parameters—this is ambiguous since no period field exists in the schema. The description partially compensates but leaves key parameters under-specified and introduces confusion about time selection.
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: reporting fees and revenue for protocols and chains, with time ranges and chain filtering. It defines key terms (fees vs revenue) and distinguishes the 'cash-flow view' from other data. While it doesn't name a sibling, the specificity makes the intent 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 gives context on what the tool does (fees/revenue, time periods, chain filter) but provides no guidance on when to choose this over alternative tools like defi_rankings or chain_tvl. No exclusions or comparisons are mentioned, so the agent must infer suitability from the purpose alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perpetual funding for a coin on Hyperliquid, OKX and Kraken Futures side by side — per-interval rate and annualized APR — plus open interest and mark price. Positive = longs pay shorts. Each venue's rate is normalized to an hourly figure and annualized so they compare directly (OKX settles every 1–8 h, Hyperliquid hourly, Kraken hourly). Use for basis/carry trades or crowding signals. Price: $0.003 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| coin | Yes | BTC, ETH, SOL… |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already mark it read-only and non-destructive, and the description adds meaningful context beyond that: rates are normalized to an hourly figure and annualized across venues, and positive funding means longs pay shorts. It also explains differing settlement cadences, which affects how an agent interprets the returned values.
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 informative and front-loaded, starting with the core function before use cases and cost. There is slight redundancy around 'hourly' and annualization, but no sentence is dead weight.
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 one-parameter, read-only data tool with no output schema, the description names every returned component, explains normalization for comparability, gives the sign convention, and states intended use cases. An agent has enough context to invoke it correctly and interpret 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 fully documents the only parameter, including a pattern and examples, so the description does not need to add much. The description only confirms that the tool is coin-specific, matching what the schema already states. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific resource and function: perpetual funding for a coin across Hyperliquid, OKX, and Kraken Futures. It also enumerates the exact outputs (per-interval rate, annualized APR, open interest, mark price), making the tool's role distinct among the many market-data siblings.
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 'Use for basis/carry trades or crowding signals,' giving an agent a clear selection criterion. It does not name alternatives or state when not to use it, so it misses the top score but is well above providing no guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Official exchange rates for 30 major currencies (European Central Bank reference rates): latest or any date since 1999, convert an amount, or a time series. Frankfurter API over ECB reference rates, published each working day ~16:00 CET. For crypto use crypto_price. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | targets (default: all) | |
| date | No | historical date (optional) | |
| from | No | USD | |
| amount | No | ||
| end_date | No | with date: returns a daily series |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false. The description adds valuable non-obvious behavior: the data source (Frankfurter API over ECB reference rates), publication time (~16:00 CET working days), currency coverage, and free pricing. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact sentences with no redundant wording. The core functionality is front-loaded, followed by source/schedule details and the crypto alternative. 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?
For a read-only lookup tool with no output schema, the description covers the essential context: data source, scope, date range, update schedule, pricing, and sibling routing. It lacks only an explicit return-shape explanation, but that is not critical given the straightforward API and the schema's parameter 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 coverage is 60%, and the description adds moderate operational context by describing the three modes (latest/historical, conversion, time series) that map to date, amount, and end_date. However, it does not explain how from/to/amount combine or clarify parameter format beyond what the schema already states, so it does not fully compensate for the undocumented 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 identifies a specific resource (ECB reference exchange rates for 30 major currencies) and three distinct operations: latest/historical rates, amount conversion, and time series. It also clearly differentiates from crypto-focused siblings by naming crypto_price as the alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: official fiat exchange rates from ECB, available since 1999, updated on working days, and free. It explicitly routes crypto requests to crypto_price, but it does not contrast against other potentially overlapping siblings like price or stablecoins, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What a transaction costs right now on 17 EVM chains, Solana and Bitcoin — gwei/priority fee and the USD cost of a transfer and a swap on each. EVM: base fee + priority fee from the latest block (eth_feeHistory), USD cost of a 21,000-gas transfer and a ~150,000-gas swap (L2s shown before their L1 data fee). Solana: recent prioritization-fee percentiles. Bitcoin: mempool.space recommended sat/vB with USD for a typical 140 vB transaction. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| chains | No | subset, e.g. ["ethereum","base","solana","bitcoin"] (default: all) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, and the description adds genuine value beyond them: data provenance (eth_feeHistory latest block, mempool.space), baked-in assumptions (21,000-gas transfer, ~150,000-gas swap, 140 vB), and how L2 costs are presented (before L1 data fee). It omits rate limits or staleness handling, but the methodology disclosure is substantial.
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 front-loads the core answer and then logically structures per-chain details (EVM, Solana, Bitcoin) with dense, informative clauses. It is slightly long and the trailing 'Price: free' adds marginal value, but every substantive sentence earns its place with source or assumption 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?
With no output schema, the description carries the burden of explaining the response, and it does so thoroughly for all three chain families, including specific fee units and USD figures. The main gap is that it never enumerates which 17 EVM chains are valid values for the chains parameter, and the response's structural shape is not described.
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 chains parameter already describing the subset format and default, so the baseline is 3. The description reinforces which chains are valid by naming EVM chains, Solana, and Bitcoin, but it does not enumerate the 17 EVM chains or add syntax details 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 names a specific resource (live gas/fee data) with a precise scope (17 EVM chains, Solana, Bitcoin) and the specific metrics returned (gwei/priority fee, USD transfer/swap cost). The detail on per-chain methodology makes it easy for an agent to distinguish this from siblings like fees_revenue or funding_rates.
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 phrasing 'right now' clearly implies this is the tool for current/real-time gas and fee queries, and the optional chains parameter implies filtering use. However, there is no explicit when-to-use vs. alternative guidance or mention of sibling tools (e.g., bitcoin_network, solana_network); the usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Place name or address → coordinates (with city, state, country, postcode), or lat,lon → the nearest address. Up to 10 candidates. OpenStreetMap data via Photon. Returns OSM links so results can be checked. Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | address/place, or "lat,lon" for reverse |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavior beyond annotations: the data source (OpenStreetMap via Photon), the 10-candidate limit, OSM verification links, and the explicit pricing model with free tier.
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?
Four tight sentences that front-load the core function, then layer candidate limits, data source, verification mechanism, and pricing. Every sentence earns its place; no filler or redundancy with annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple two-parameter tool with no output schema, the description covers function, both invocation modes, data provenance, candidate limits, output verification, and cost. It does not detail the exact response structure, but the mention of 'city, state, country, postcode' and OSM links gives sufficient shape to 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 50%: the query parameter is documented in the schema, and the description echoes its dual-purpose format. The 'limit' parameter lacks a schema description, but the description's 'Up to 10 candidates' partially compensates by indicating the cap. This is adequate but not exceptional.
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+resource: 'Place name or address → coordinates' and 'lat,lon → the nearest address', covering both geocode and reverse geocode modes. It clearly distinguishes itself from the sibling list, none of which offer geocoding 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 explains the two usage modes with a clear arrow notation that maps directly to the query parameter format. It implies when to use (address lookup or coordinate reversal) but does not explicitly state exclusions or name alternative tools, though no siblings are plausible alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A GitHub repository at a glance: stars, forks, open issues, last commit, latest release, license, languages, contributors, archived — is it alive and trustworthy? From the GitHub REST API. "activity" summarizes days since last push and last release so an agent can judge whether a project is maintained. Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| repo | Yes | owner/name or a github.com URL |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, and the description adds meaningful detail beyond that: it enumerates the GitHub API data points returned, explains how 'activity' is derived, and discloses pricing/free-tier usage. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the metric list and purpose appear immediately, followed by the derived activity explanation and pricing. Every sentence earns its place, and there is no redundant repetition of schema or annotation 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?
With one well-documented parameter, strong annotations, and no output schema, the high-level metric list and activity explanation give an agent enough to select and invoke the tool correctly. The only minor gap is that the exact response envelope/format is not specified, but the explicit metric enumeration mitigates that absence.
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%: the single 'repo' parameter is already described as 'owner/name or a github.com URL'. The description adds no additional parameter-level guidance, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (a GitHub repository) and the outcome (a health/activity snapshot with stars, forks, issues, commits, releases, license, languages, contributors, and archived state). The title and the explicit 'From the GitHub REST API' source make it easy to distinguish from the other mostly non-GitHub 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 gives explicit context: it is for judging whether a project is alive and trustworthy, and the 'activity' summary is described in terms of days since last push and last release. It does not list when-not-to-use cases or directly name alternative sibling tools, so it falls just short of the top tier.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Hash data (SHA-256/512, SHA3, Keccak-256, BLAKE2, MD5, SHA-1, RIPEMD-160, HMAC) and convert between utf8, hex, base64, base64url and base58 — exact, in one call. Useful for signatures, content addressing, EVM selectors (keccak of a function signature), and decoding blobs agents are handed. Input can itself be hex/base64/base58. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | ||
| hashes | No | sha256, sha512, sha3-256, sha3-512, keccak256, blake2b512, blake2s256, md5, sha1, ripemd160 | |
| hmac_key | No | if set, HMAC instead of plain hash (utf8 key) | |
| input_encoding | No | utf8 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already signal a safe, read-only, idempotent operation; the description adds determinism ('exact'), single-call batching, and the fact that input may itself be hex/base64/base58. It does not fully specify output representation, but the annotations carry the safety burden.
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 dense sentences with no filler; the capability is front-loaded, followed by use cases and the input caveat. 'Price: free' is a minimal and useful contextual note.
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 sufficient for choosing the tool and for basic invocation, but with no output schema it leaves the return format ambiguous and never says how to request one of the advertised encodings as output. The base64url/input_encoding inconsistency also creates a small completeness 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?
It lists algorithms and encodings and clarifies that input can be encoded, adding some meaning to `hashes` and `input_encoding`. But the mapping to parameters is implicit, base64url is mentioned without a corresponding enum/parameter, and output encoding is never explained, so the description only partially compensates for the 50% 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?
Opens with a specific action ('Hash data... and convert between...'), enumerates the algorithm families and encoding formats, and adds 'exact, in one call' so it is clearly distinct from sibling conversion/analysis 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?
Names concrete use cases (signatures, content addressing, EVM selectors, decoding blobs), which tells an agent when to reach for it. It doesn't explicitly state exclusions or alternatives, but no sibling directly overlaps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search Hacker News stories and comments by keyword, sorted by relevance or date, filtered by time window and minimum points — what developers are saying about anything. Algolia's official HN search. Returns title, url, points, comment count, author, date and the HN discussion link. Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| sort | No | relevance | |
| type | No | story | |
| limit | No | ||
| query | Yes | ||
| min_points | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare the tool as read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond the annotations: pricing per call, a free daily quota, the official Algolia source, and the exact fields returned. There is no contradiction with the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler. The search action, filters, and return fields are front-loaded, while the pricing and source details come at the end. Every sentence 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?
The description is quite complete for a tool with no output schema: it lists returned fields, pricing, rate limits, source, and key filtering options. Minor gaps remain around the limit parameter and full type enum, but an agent can invoke the tool confidently with this description plus the 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?
With 0% schema coverage, the description must compensate, and it does partially: it maps query, sort, days, min_points, and roughly type. However, it omits the limit parameter and the show_hn/ask_hn type variants, so not every parameter is semantically clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource ('Hacker News stories and comments') and the action ('search by keyword'), and it specifies sorting and filtering capabilities. This is specific enough to distinguish it from sibling search tools like arxiv_search or book_search, even though it doesn't explicitly name 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?
It gives a clear use case — finding what developers are saying on Hacker News — and identifies the underlying Algolia service. However, it does not explicitly state when not to use it or which alternative tool to choose, though no sibling appears to cover HN content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Public holidays for 100+ countries for any year, whether today is a holiday there, and the next upcoming ones — including regional (state) holidays. Nager.Date open holiday data. Use for scheduling, market-closure awareness or delivery estimates. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| year | No | ||
| country | Yes | ISO code or name, e.g. AU, United States |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, open-world, and non-destructive behavior. The description adds value beyond annotations by naming the Nager.Date data source, the kinds of outputs (yearly list, today flag, upcoming list), and regional holiday coverage, giving the agent a useful behavioral model.
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 four short sentences that front-load the core functionality, then add data source, use cases, and cost. Every sentence contributes useful selection information, with no redundant or filler wording.
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, read-only tool with no output schema, the description covers the query scope and the result categories: yearly holidays, today's status, upcoming holidays, and regional holidays. It does not specify exact return formatting, but the lack of an output schema is mitigated by this behavioral clarity.
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 country parameter already has schema-level description with ISO/name examples, and year has min/max bounds. The description adds context about 'any year' and today/upcoming behavior, but it does not explicitly clarify how omitting year changes the query or provide additional parameter-level detail. With 50% schema coverage, this only partially compensates.
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 clear resource (public holidays) and specific capabilities: coverage of 100+ countries, any year, today's holiday status, next upcoming holidays, and regional holidays. It is easily distinguished from sibling tools, none of which overlap with holiday 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 explicitly names target use cases: 'scheduling, market-closure awareness or delivery estimates.' It does not list alternative tools or exclusions, but no sibling tool directly competes, so the guidance is sufficient for an agent to decide when to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Is a site up and how is it served: status, full redirect chain, timings (DNS/TLS/first byte/total), server, CDN, caching, compression, and a graded security-header check (HSTS, CSP, frame, sniffing…). One real GET from our server. The security grade counts HSTS, Content-Security-Policy, X-Frame-Options/frame-ancestors, X-Content-Type-Options, Referrer-Policy and Permissions-Policy. Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, covering safety. The description adds valuable behavioral context: it states 'One real GET from our server,' which implies a network request with potential side effects on the target, and discloses pricing and free tier. This goes beyond annotations and helps the agent anticipate costs and external interaction.
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 reasonably concise given the breadth of information it conveys. It front-loads the core purpose with a question, then lists key outputs in a structured list, and includes pricing at the end. Every sentence contributes to the agent's understanding; no filler. It's slightly long but each detail is relevant.
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 main outputs (status, redirect chain, timings, server info, security grade) and includes cost details. With no output schema, it adequately describes the return content. It doesn't mention error handling (e.g., if the site is down or unreachable), which is a minor gap, but the overall coverage is strong for a single-parameter probe 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?
With schema coverage at 0%, the description must compensate for the single 'url' parameter. The description implies the input is a site URL ('Is a site up'), but it never explicitly mentions the parameter name or any constraints (e.g., must be http/https). The schema type is string, but no additional semantics are provided, so the description adds minimal value beyond the obvious.
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: checking if a site is up and how it's served, listing specific outputs (status, redirect chain, timings, server, CDN, caching, compression, security header grade). It distinguishes itself from siblings like web_read and web_meta by focusing on HTTP details and security headers, making it identifiable.
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 by describing what it does, but it does not explicitly compare to alternatives or state when not to use it. For example, it doesn't say 'use this instead of web_read if you need timing and security checks.' The context (making a real GET, pricing) gives some guidance, but the lack of explicit exclusions or alternative references keeps it at implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every Hyperliquid perpetual: mark/oracle price, 24 h change and volume, open interest, funding APR, premium — ranked by volume, OI, funding or movers. Live from Hyperliquid's public info API. Filter to one coin or rank the whole board. Funding is hourly on Hyperliquid; apr = hourly × 8,760. Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| coin | No | optional, e.g. BTC | |
| sort | No | volume | |
| limit | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile. The description adds valuable behavioral context beyond annotations: data is 'live from Hyperliquid's public info API' (no auth), there is a cost of '$0.002 per call (10 free/day)', and the funding APR formula is explained ('hourly × 8,760'). No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler. The first sentence front-loads the data fields and ranking capability, the second clarifies scope and live-source, the third explains the funding formula and pricing. Every sentence carries essential information that an agent needs before calling 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 read-only, idempotent annotations and the detailed description, an agent has everything needed to invoke the tool correctly: data fields, filter and sort options, the funding APR calculation, the live API source, and the per-call cost. There is no output schema, but the description enumerates the returned data, so return semantics are adequately covered. Minor omissions like the 'funding_negative' sort value are already present in the 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?
Schema description coverage is only 33% (just the coin field). The description compensates by explaining the coin parameter ('filter to one coin') and the sort parameter ('ranked by volume, OI, funding or movers'). It doesn't explicitly mention the 'funding_negative' enum value or the limit parameter, but the schema itself documents the enum values and the limit min/max/default, so the description adds meaningful meaning where coverage 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 states a specific resource ('Every Hyperliquid perpetual') and a comprehensive list of returned fields (mark/oracle price, 24h change and volume, open interest, funding APR, premium). It also clearly presents the core behaviors of ranking and filtering, making the tool's purpose unmistakable even without a verb.
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 for when to use the tool: whenever Hyperliquid perp market data is needed, 'filter to one coin or rank the whole board.' It does not name sibling alternatives or explicitly state exclusions, but the Hyperliquid-specific scope and the mention of the public info API imply appropriate usage without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Validate JSON data against a JSON Schema (draft-07/2019-09/2020-12, formats like email/uri/date-time) and get every error with its exact path — check tool I/O before acting on it. Ajv, strict about types, all errors reported. Pass data and schema as JSON values (or JSON strings). Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | any JSON value (or a JSON string with parse_strings=true) | |
| schema | Yes | ||
| parse_strings | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly, idempotent, non-destructive), the description discloses the underlying engine (Ajv), strict type checking, that all errors are reported, and the supported draft versions and formats. It also notes the input flexibility (JSON values or strings) and cost, giving the agent a complete behavioral model.
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 dense sentence that front-loads the primary purpose before the use-case hint and supporting details. No filler; each clause (draft versions, formats, path reporting, Ajv, strictness, input modes, price) adds decisionally relevant 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 validation tool with no output schema, the description is nearly complete: it covers accepted inputs, expected behaviors (strict types, all errors, exact paths), and the use case. The only minor omission is the precise shape of the success response, but the error-oriented phrasing provides enough guidance.
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 of three parameters has a schema description, so the description carries the burden. It clarifies that both data and schema can be passed as JSON values or JSON strings, which indirectly explains the parse_strings toggle, though it doesn't explicitly document parse_strings semantics or default. The core parameter meaning is adequately conveyed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States exactly what it does with a specific verb ('Validate') and resource ('JSON data against a JSON Schema'), including supported draft versions and that it returns every error with its exact path. This clearly differentiates it from validation-adjacent sibling tools like email_check or address_check, which validate specific domains rather than arbitrary JSON.
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 frames when to reach for it: 'check tool I/O before acting on it', which tells an agent to validate tool responses before taking consequential actions. It does not name alternatives, but there are no obvious siblings performing JSON Schema validation, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Decode a JSON Web Token's header and claims, show issued/expiry times in plain dates and whether it has expired — optionally verify an HS256/384/512 signature with a secret. Decoding does not need the key. Never paste production secrets into third-party tools you do not trust; verification here is local and nothing is stored or logged. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| token | Yes | ||
| secret | No | optional HMAC secret to verify HS* signatures |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds significant behavioral context: it states that decoding does not need the key, verification is local, nothing is stored or logged, and it shows issued/expiry times in plain dates and expiry status. It also mentions the price is free. This goes well beyond the annotations without contradicting them.
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 and front-loaded: it opens with the primary action, then details the optional verification, security note, and price. Every sentence adds value with no redundant phrases. It is well-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?
Despite lacking an output schema, the description clearly explains what the tool returns (header, claims, dates, expiry status) and its optional verification behavior. It also covers security considerations and pricing. For a read-only, idempotent tool with only two parameters, this is complete and sufficient 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 schema has 50% coverage: token has no description, secret has a brief description. The description clarifies the purpose of the secret parameter (optional HMAC secret for HS* verification) and explicitly states that decoding does not need it. This adds meaning beyond the schema. The token parameter is self-explanatory given the tool's purpose, so the description adequately compensates for the 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 tool decodes a JWT's header and claims, and optionally verifies an HS256/384/512 signature with a secret. It specifies the resource (JWT) and the actions (decode, verify, show dates, check expiry). This distinguishes it from sibling tools like hash_encode or json_schema_validate, which serve different purposes.
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 context on when to use the tool: for decoding JWTs and optionally verifying signatures locally. It notes that decoding does not require the key and that verification is local, which helps agents decide if this is appropriate. It does not explicitly name alternative tools or exclusion criteria, but the unique purpose among siblings makes the usage context clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
One call, one verdict on a pump.fun launch: 0-100 score with positives and risks, graduation odds, dev record, snipers, holders, flow. Runs pump_token + pump_dev + pump_odds together (cheaper than calling them separately) and folds them into a single score and verdict an agent can act on: strong / neutral / weak / avoid. Price: $0.025 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | pump.fun token mint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool read-only, idempotent, and non-destructive. The description adds valuable behavioral context beyond that: it runs three underlying analyses, returns an actionable verdict, and discloses pricing and the free tier. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core value proposition and output, the second explains composition and cost advantage, and the third gives pricing. Every sentence earns its place with no filler 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?
For a single-parameter, read-only tool with no output schema, this description is complete enough: it enumerates the returned dimensions (score, risks, graduation odds, dev record, snipers, holders, flow), the verdict scale, the bundled nature, and cost. An agent has sufficient information to decide when and how to call 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 already documents the only parameter, mint, with a description and a validation pattern, giving 100% schema coverage. The description reinforces that the target is a pump.fun launch but does not add new parameter-level meaning, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a composite action: it runs pump_token + pump_dev + pump_odds together and produces a single 0-100 score with positives, risks, and a categorical verdict. This distinguishes it from the sibling individual tools by framing it as the bundled, one-call option.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear usage context: use this when you want one integrated verdict across the bundled analyses, especially because it is 'cheaper than calling them separately.' It names the component alternatives but stops short of explicitly saying when to prefer the individual tools instead, so it lacks full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert Markdown to clean HTML (GitHub-flavoured: tables, task lists, fenced code) or HTML back to Markdown. marked for md→html, Turndown for html→md. Scripts/styles are dropped on html→md. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | html | |
| input | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and non-destructive, so the safety profile is covered. The description adds a key behavioral detail: 'Scripts/styles are dropped on html→md', which is not in the annotations and helps the agent anticipate output loss. No contradictions.
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 fluff. The core action is stated first, then flavor and behavior details follow. Every clause earns its place; the 'Price: free' is extra but harmless and short.
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 conversion tool, the description covers purpose, direction, Markdown flavor, a critical behavioral note (dropping scripts/styles), and even pricing. There is no output schema, so no return format is needed. An agent has enough to call 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 0%, so the description must compensate. It implies the 'to' parameter selects direction ('Convert Markdown... or HTML back to Markdown') and that 'input' holds the content, but it doesn't explicitly map these to parameter names. The enum values make 'to' self-explanatory, so the description adds marginal 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 converts between Markdown and HTML, specifies GitHub-flavoured Markdown features (tables, task lists, fenced code), and distinguishes it from any conversion siblings by naming both directions. It is 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 makes the intended use explicit: convert Markdown to HTML or HTML back to Markdown. It mentions the direction and the libraries used, which implies when to use it. There are no competing conversion tools among siblings, so no exclusions are needed, but it stops short of stating 'use this when you need X'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How much size a market can take: bid/ask depth within ±0.1/0.5/1/2/5%, spread, and the slippage of a $10k/$100k/$1M market order on Kraken, Coinbase or OKX. Pulls the full public L2 book and walks it. Use before sizing an order or comparing venue liquidity. slippage is vs. mid price, in basis points; null means the fetched book was too thin for that size. Price: $0.003 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| pair | Yes | ||
| venue | No | coinbase |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly/idempotent/non-destructive annotations, the description discloses the method ('Pulls the full public L2 book and walks it'), output units ('slippage is vs. mid price, in basis points'), null semantics for thin books, and cost per call. This is substantial behavioral context with no contradiction to 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?
Four focused sentences, front-loaded with the core question ('How much size a market can take'), followed by output details, use cases, and pricing. Every sentence adds useful information without repetition or 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?
The description covers output metrics, units, error/null behavior, venues, use cases, and cost, which is strong for a read-only tool with no output schema. It is incomplete mainly on pair-format convention and the units of the spread field, both of which an agent would need to fully trust the output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It names the venues, which loosely matches the enum, but it never explains the required pair parameter's expected format (e.g., 'BTC-USD' vs 'BTCUSD'). Since pair is the only required parameter, this is a significant gap for an agent trying to call the tool 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 what the tool computes: bid/ask depth at multiple percentages, spread, and slippage for market orders on three named venues. It uses a concrete resource ('full public L2 book') and explains the output in terms of market impact, making it easy to distinguish from price/ticker 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 gives explicit use cases: 'Use before sizing an order or comparing venue liquidity.' This is clear context, but it does not spell out when not to use the tool or name an alternative for simple price checks, so it stops short of a full routing guide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Any npm, PyPI or crates.io package: latest version and release date, license, downloads, maintainers, repo, dependency count, deprecation — to pick or vet a dependency. Straight from each registry (plus npm and pypistats download counts). Flags deprecated packages and ones with no release in 2+ years. Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| ecosystem | No | npm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this read-only, idempotent, and non-destructive. The description adds useful behavioral context beyond that: data is fetched 'straight from each registry', supplementary download counts come from npm and pypistats, and deprecated or stale packages are flagged. It does not contradict the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it starts with the package types and core output fields, then adds data-source and pricing context. The list of fields is long but every element carries relevant information; there is no filler.
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?
Since there is no output schema, the description carries the burden of describing the return surface, and it does so by listing the key fields and edge-case flags. It omits failure or not-found behavior, but for a simple two-parameter tool with openWorldHint, the remaining gap is minor.
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 compensate. It effectively defines the ecosystem parameter by listing npm, PyPI, and crates.io, and clarifies that the 'name' parameter refers to an installable package. It does not explicitly mention the npm default or format requirements, but the schema already provides those 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?
The description names a concrete resource ('Any npm, PyPI or crates.io package') and enumerates the exact data returned: latest version, release date, license, downloads, maintainers, repo, dependency count, and deprecation status. It also states the intended use case ('to pick or vet a dependency'), which clearly separates it from siblings like github_repo or arxiv_search.
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 gives clear context for when to use this tool: dependency selection or vetting. It does not explicitly name alternative tools or state when not to use it, so it falls short of the strongest possible guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
USD price, 24h change and liquidity for up to 100 Solana mints; flags illiquid (dead) tokens. Jupiter price data with a liquidity floor: anything under $1,000 of liquidity is flagged dead, because round-trip quotes on dead curves look fine and are not. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| mints | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, and non-destructive behavior. The description adds valuable context about the data source (Jupiter) and the liquidity floor of $1,000, explaining why dead tokens are flagged. This goes beyond the structured metadata and helps the agent set expectations.
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 and front-loaded with the main purpose. The rationale about liquidity is valuable, but the trailing 'Price: free.' feels extraneous and could be omitted without loss. Overall, it is efficient with only slight 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?
For a simple tool with one parameter and no output schema, the description covers the core outputs (price, change, liquidity, dead flag) and the threshold logic. It does not describe the response structure, but that may be acceptable given the absence of an output schema. It lacks edge-case handling (e.g., invalid mints) but is largely 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 coverage is 0%, so the description must compensate. It adds meaningful context about the input being Solana mints and a limit of 100, which helps interpret the 'mints' array. However, it does not describe the expected format (e.g., base58) or additional constraints, leaving some 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 returns USD price, 24h change, and liquidity for up to 100 Solana mints, and flags illiquid tokens. It specifies the resource (Solana mints) and the output fields, making its function unambiguous even among many siblings.
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 its use for checking token prices but does not explicitly address when to prefer this tool over siblings like token_risk or launch_scan. No alternative routing or exclusion conditions are given; the agent must infer applicability from the general context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Historical USD prices for any crypto asset (hourly or daily, up to 365 days) with return, high/low, max drawdown and annualized volatility. Same asset resolution as crypto_price. Returns the series plus stats computed from it: total return, high/low with dates, max drawdown, and annualized volatility from log returns. Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | ||
| asset | Yes | symbol, CoinGecko id, chain:address or address | |
| chain | No | EVM chain: ethereum, base, arbitrum, optimism, polygon, bsc, avalanche, linea, blast, scroll, gnosis, sonic, unichain, mantle, berachain, hyperevm, monad | ethereum |
| interval | No | hourly allowed up to 30 days | day |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly, idempotent, and non-destructive behavior, so the description adds useful context beyond them: per-call pricing, free daily quota, log-return methodology, and the exact computed stats. It does not need to restate safety traits, and it provides meaningful operational 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 compact and front-loaded, but the second sentence partially repeats the statistics already listed in the first sentence. It still earns its place by adding 'with dates' and 'from log returns,' so the redundancy is minor and the overall structure 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?
Given that this is a read-only data tool with no output schema, the description adequately covers what the agent will receive: the price series and the specific stats. It also includes cost and free-tier information. Exact output field names and chain resolution details are not fully specified, but the schema and the reference to crypto_price cover enough 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 high at 75%, so the baseline is 3 even without much parameter detail. The description adds useful semantics about asset resolution and the hour/day interval, but the phrase 'hourly or daily, up to 365 days' is ambiguous because the schema restricts hourly data to 30 days. This prevents the description from adding fully reliable parameter 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 identifies the resource (historical USD prices for any crypto asset), the output (price series plus statistical metrics), and the available granularity/horizon. It also distinguishes itself from the sibling crypto_price tool by noting the same asset resolution while focusing on history and volatility.
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 historical price data and derived volatility statistics, but it never explicitly says when to prefer it over alternatives such as crypto_price or price. The reference to 'same asset resolution as crypto_price' hints at a related tool but does not provide concrete when-to-use/when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A creator wallet's launch history: launches, graduation rate, launch cadence, how fast the dev sells, verdict. Looks up every token the wallet created since recording began and replays the dev's own trades on its 15 most recent launches. Price: $0.01 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| creator | Yes | creator (dev) wallet |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering safety. The description adds valuable behavioral context: it looks up every token the wallet created since recording began and replays the dev's own trades on the 15 most recent launches, plus pricing details. No contradiction with 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 two sentences plus pricing, front-loading the core purpose and then providing specific behavioral details. No redundant words or filler.
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 single-parameter read-only tool with no output schema, the description covers purpose, behavior, and pricing. It is sufficient for an agent to decide when to call it, though it could mention edge cases like a wallet with no launches, but that is a minor 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?
Schema coverage is 100%, so the parameter 'creator' is fully documented with pattern and description. The description only refers to the creator wallet without adding extra semantic detail beyond what the schema already provides. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a creator wallet's launch history with specific metrics (launches, graduation rate, launch cadence, how fast the dev sells, verdict). It describes the lookup and replay behavior, making it distinct from sibling tools like pump_launches which focus on individual token launches, and pump_wallet which likely shows wallet holdings.
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 dev's track record is needed, but does not explicitly state when to use this tool versus alternatives such as smart_money or pump_wallet. No exclusion conditions or alternative recommendations are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
pump.fun over time: launches, graduations, graduation rate, trades, SOL volume and unique wallets per day or hour since 2026-09-11 — with a compare window. The same tape as pump_pulse, sliced into UTC days or hours so an agent can compare the market over time instead of reading one snapshot. Pass compare_from/compare_to to get a second window and the per-period change (e.g. this week vs last week). Closed periods are precomputed from our own live recording of every bonding-curve trade; the open period is marked partial. Also reports the share of trades made by pump.fun's own mayhem agent, so it can be separated from real demand. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | UTC end, inclusive (default: now) | |
| from | No | UTC start, e.g. 2026-09-18 or 2026-09-18T06 (default: 14 days / 48 hours back) | |
| compare_to | No | end of the comparison window, inclusive | |
| granularity | No | day | |
| compare_from | No | start of a second window to compare against |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, so the bar is lower. The description adds valuable behavioral context: closed periods are precomputed from a live recording of every bonding-curve trade, the open period is marked partial, and the mayhem-agent trade share is reported so it can be separated from real demand.
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 dense and front-loaded: it opens with the metric list and time slicing, then adds comparison semantics and data caveats. Almost every sentence earns its place; 'Price: free' is minor noise but does not significantly hurt 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?
There is no output schema, so the description carries more responsibility for explaining what the agent will get. It lists the reported metrics, comparison-window behavior, partial-open-period caveat, and mayhem-agent share. It does not spell out the exact response shape or how 'partial' is flagged, but it is sufficient for correct 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 80%, so the schema already documents most parameter formats and defaults. The description nevertheless adds meaning beyond the schema by explaining that compare_from/compare_to produce a second window with per-period change, illustrated by 'this week vs last week,' and that granularity can be 'day or hour.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a clear object ('pump.fun over time') and enumerates concrete metrics: launches, graduations, graduation rate, trades, SOL volume, and unique wallets. It also explicitly contrasts with pump_pulse by saying it is 'the same tape... sliced into UTC days or hours,' so an agent can immediately distinguish this tool from its 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?
'The same tape as pump_pulse, sliced into UTC days or hours' gives a direct comparison to the main alternative, and 'compare the market over time instead of reading one snapshot' states when this tool should be used. It also explains how to request a second comparison window with compare_from/compare_to, making the selection and invocation path clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The newest pump.fun tokens with dev buy, early buyers/volume, curve progress, market cap and creator launch count. Returns up to 50 of the most recent launches (seconds old) with the first-N-seconds flow already aggregated, so an agent can shortlist without replaying the chain. Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| window_s | No | early-flow window after creation |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior. The description adds valuable context beyond those: results are limited to 50, launches are seconds old, early-flow is pre-aggregated to avoid chain replay, and there is a per-call price and free-tier allowance.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, each adding new value: what data is returned, how it is aggregated and why that matters, and the cost. The most decision-relevant information is front-loaded, with no fluff or repetition.
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-only list tool with optional parameters and no output schema, the description covers the purpose, the response fields, result limits, freshness, aggregation behavior, and pricing. An agent has enough information to select and invoke 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 only 50%, so the description must compensate for the undocumented 'limit' parameter and clarify window semantics. It does this by stating 'up to 50' launches and by referencing the first-N-seconds flow, which maps naturally to window_s. Some explicit parameter naming would improve it further.
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 operation and resource: returning the newest pump.fun token launches with a specific set of pre-aggregated metrics. It distinguishes itself from the sibling tools by targeting recency and early-flow data, so an agent can tell what this tool uniquely provides.
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 gives clear context: use this when you need the most recent launches and want to shortlist tokens without replaying chain data. It does not explicitly name alternatives or exclusion conditions, but the use case is specific enough that an agent can infer when to choose it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Probability a pump.fun launch graduates, from how comparable launches in our tape actually ended — with the lift over the ~3% base rate. Buckets the launch's first 60 seconds (unique buyers, buy SOL, dev buy) and returns the empirical graduation rate of thousands of comparable recent launches whose outcome is known, shrunk toward coarser buckets when samples are thin. Rebuilt every 6 hours. Price: $0.01 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | pump.fun token mint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior, so the description wisely doesn't repeat those. It adds substantial beyond-schema context: the empirical historical basis, the shrinkage toward coarser buckets when samples are thin, the 6-hour rebuild cadence, and pricing with a free tier. These are materially useful behavioral disclosures.
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?
Four dense sentences, each earning its place: the primary output, the methodology, the refresh cadence, and the cost. The most important information is front-loaded in the first sentence, and no filler or restatement of annotations appears.
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 one-parameter, read-only tool with no output schema, the description is complete. It states what the returned value is (empirical graduation rate), how it is computed, when it was last rebuilt, and what it costs. An agent has everything needed to select and invoke 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 schema already documents the sole parameter 'mint' with type, format, and description, giving 100% schema coverage. The tool description adds no additional parameter-specific semantics beyond referring implicitly to the launch's first 60 seconds. Baseline 3 is appropriate when the schema carries the full parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement: 'Probability a pump.fun launch graduates' — a specific resource and measurable outcome. It then distinguishes itself from sibling tools by focusing on empirical graduation odds, not listing, scanning, or pricing. The methodology detail (first 60 seconds, comparable launches) makes its scope unmistakable.
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 makes clear when this tool is relevant: any time an agent needs the statistical graduation probability for a pump.fun launch. It does not explicitly name alternative sibling tools or state exclusion conditions, but the specialized purpose is so well-defined that routing confusion is unlikely. This is 'clear context, no exclusions' rather than full explicit when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Live pump.fun heartbeat: trades/min, launches, graduations, graduation rate, hottest tokens in the last 15 min. Computed from our own live recording of every pump.fun bonding-curve trade. Use it to decide whether the launch market is hot or dead before scanning individual tokens. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, covering the safety profile. The description adds useful context beyond annotations by specifying the data source ('Computed from our own live recording of every pump.fun bonding-curve trade') and the 15-minute time window. It does not reveal potential latency or response format, but given the annotation coverage, this addition is sufficient for a 4.
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 (plus a price note) with zero filler. Key metrics and purpose are front-loaded, and every clause adds value: what it provides, how it is computed, and when to use it. The 'Price: free' note is brief and actionable. This is a model of 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 tool with no parameters and no output schema, the description fully covers what an agent needs: the exact metrics returned, the time window, the data source, and a clear usage suggestion. Given the annotations already handle safety, nothing essential is missing. It is complete for its 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?
The input schema is an empty object with zero parameters, so schema coverage is trivially 100%. The description correctly does not attempt to explain parameters. Per the rule for 0-parameter tools, the baseline is 4. No additional semantic explanation is needed or possible.
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 is a live market heartbeat for pump.fun, listing specific metrics (trades/min, launches, graduations, graduation rate, hottest tokens in 15 min). This distinguishes it from siblings like pump_launches (list of launches) and pump_token (individual token data). The verb 'heartbeat' plus resource 'pump.fun market' is 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 gives an explicit use case: 'Use it to decide whether the launch market is hot or dead before scanning individual tokens.' This tells the agent when to invoke it (before token-level analysis) and implicitly when not to (for individual token details). However, it does not explicitly name alternative tools or describe when to avoid it beyond that scenario, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full bonding-curve forensics for one pump.fun mint: flow, dev buys/sells, launch snipers, top curve holders, peak, graduation, red flags. Aggregates every recorded curve trade of the token: unique wallets, buy/sell SOL, first-60-second flow, whether the dev sold out, non-dev wallets that bought in the launch slots (bundles), top net holders on the curve, peak market cap and post-graduation liquidity. Price: $0.01 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | pump.fun token mint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so safety is covered. The description adds valuable behavioral context: it aggregates every recorded curve trade, computes specific metrics like first-60-second flow and top net holders, and flags red flags. It also discloses the cost and free tier, which is helpful for an agent deciding whether to invoke it. No contradiction with 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 front-loaded with the core purpose and then provides a detailed list of the aggregated data. It is longer than average but every sentence adds information about capabilities and pricing. It avoids fluff and maintains a logical flow from purpose to specifics to cost.
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 compensates by listing the key data categories returned (flow, dev actions, snipers, holders, peak, graduation, red flags). This gives an agent a solid expectation of the report. It could benefit from noting any error conditions or limitations, but for a single-mint forensic tool, it covers the essential inputs and outputs.
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 required parameter 'mint', which has a clear description and pattern. The description does not add additional syntax or format details beyond the schema, but it does explain how the mint is used (to retrieve forensics for that specific token). Since the schema already fully documents the parameter, a baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Full bonding-curve forensics for one pump.fun mint'. It enumerates the exact data points returned (flow, dev buys/sells, snipers, holders, peak, graduation, red flags), making it unambiguous what the tool does. It also implicitly distinguishes itself from sibling tools that focus on other aspects like dev behavior or launch listings.
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 does not explicitly state when to use it versus alternatives. There is no mention of 'use this when you need...' or exclusions. The single-mint focus is implied, but no guidance is given for choosing between this and tools like pump_dev or pump_launches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Any wallet's pump.fun trading record: realized PnL, win rate, hold time, frequency (bot or human), tokens it launched. Analyses up to the last 20,000 curve trades of the wallet. Use it to judge whether a wallet is smart money, a sniper bot, a serial dumper or a dev. Price: $0.01 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| wallet | Yes | wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context: it analyzes up to 20,000 curve trades and mentions pricing ($0.01 per call, 10 free/day). These details go beyond what annotations provide, giving the agent a fuller picture.
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: the first states the core purpose and metrics, the second provides usage guidance and cost. No filler words, and the most important info (what it does) is front-loaded. It earns its place with high information density.
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 two-parameter read-only tool with no output schema, the description provides sufficient context: it explains the resource, the scope of analysis, the decision-making use case, and cost. Although it doesn't specify the output format, that is not required given the simplicity and the annotations covering safety. The only minor gap is a lack of explicit differentiation from siblings, but the purpose is clear enough.
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 covers 50% of parameters (only 'wallet' has a description; 'limit' has no description but has default/min/max). The description indirectly explains 'limit' by mentioning '20,000 curve trades,' which maps to the maximum. It doesn't fully explain parameter semantics, but it adds some value beyond the schema, keeping it at the baseline for average 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 ('Any wallet's pump.fun trading record') and lists concrete metrics (realized PnL, win rate, hold time, frequency, tokens launched). It also names the judgment categories (smart money, sniper bot, serial dumper, dev), which clearly distinguishes its purpose from sibling tools like pump_launches or pump_dev.
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 'Use it to judge whether a wallet is smart money, a sniper bot, a serial dumper or a dev,' which provides clear when-to-use context. However, it does not mention alternatives or when not to use it, leaving some ambiguity for agents deciding among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Make a QR code for any text, URL, Solana Pay / wallet address or Wi-Fi login — as a PNG (base64 data URL) or SVG, with size, margin, colours and error correction. Rendered on our server. For Wi-Fi pass wifi_ssid + wifi_password; for Solana Pay pass a solana: URI as text. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| dark | No | #000000 | |
| size | No | ||
| text | No | ||
| light | No | #ffffff | |
| format | No | png | |
| margin | No | ||
| wifi_ssid | No | ||
| wifi_password | No | ||
| error_correction | No | M |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description needn't repeat that. It adds context: 'Rendered on our server' and 'Price: free', which are behavioral details not present in the schema. It doesn't disclose error handling or rate limits, but given the strong annotation coverage, this is a minor 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?
Two sentences, front-loaded with the core purpose, and packed with necessary details (formats, options, special cases, pricing). No filler 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?
For a 9-parameter tool with no output schema, the description covers the essential usage: it explains the primary inputs, special parameter combinations, and output format. It doesn't detail edge cases or error behavior, but for a simple generator tool this is adequate. The description is nearly complete for an agent to call 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 description coverage is 0%, so the description must compensate, and it does. It explains the meaning of text for Solana Pay, and the wifi_ssid/wifi_password pair for Wi-Fi. It also mentions size, margin, colours, and error correction, mapping to the schema parameters. This adds significant value beyond the bare 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 states a specific verb ('Make') and a specific resource ('QR code'), and enumerates supported content types (text, URL, Solana Pay/wallet address, Wi-Fi login) and output formats (PNG/SVG). It clearly distinguishes this tool from any sibling by focusing on QR generation, which none of the listed siblings handle.
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 gives explicit instructions for special cases: 'For Wi-Fi pass wifi_ssid + wifi_password; for Solana Pay pass a solana: URI as text.' This tells an agent exactly how to configure parameters for different use cases. It doesn't mention alternatives because there are no QR-specific siblings, but the guidance is sufficient for correct invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Cryptographically secure randomness: UUID v4/v7, passwords, API-key-style tokens, integers in a range, dice, coin flips, or a fair shuffle / pick from a list. Node's CSPRNG. Output is generated fresh per call and never stored or logged. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| max | No | ||
| min | No | ||
| kind | No | uuid4 | |
| count | No | ||
| items | No | ||
| length | No | ||
| symbols | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already confirm readOnlyHint=true and destructiveHint=false, but the description adds valuable behavioral context: it discloses that output is generated fresh per call (non-idempotent despite the idempotentHint annotation), never stored or logged, and that it is cryptographically secure and free. This goes beyond the annotations by explaining the freshness and privacy guarantees. However, there is a potential conflict: the description says 'generated fresh per call' which implies non-idempotence, while annotations set idempotentHint=true. This is a minor contradiction worth noting, but the description adds enough transparency to score high. I flag it in annotation_contradiction.
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, dense paragraph that lists the main capabilities up front, followed by the security and privacy notes. It is approximately two sentences, with no filler. Every word earns its place: the list of random types, the CSPRNG reference, and the 'never stored or logged' note. It is front-loaded with the most critical information and remains concise despite the breadth of functionality.
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 (7 parameters, 9 enum variants, no output schema), the description covers the main capabilities but does not delve into parameter-specific details like how to use min/max for integers, or that 'pick' requires items. For an agent to use it correctly, it would need to open the schema for parameter details. However, the description provides the conceptual model and operational context (secure, fresh, free) that is not in the schema. It is nearly complete for high-level understanding but lacks the per-operation parameter guidance that would make it fully 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?
Schema description coverage is 0%, so the description must compensate. The description explains that 'kind' can be one of many types, but it does not explain each parameter's meaning or how they interact (e.g., min/max for int, items for pick/shuffle, length/symbols for passwords). Given the tool has 7 parameters and an enum, the description provides a high-level overview but lacks per-parameter semantics. However, it does mention the kinds and the general purpose, which helps an agent infer parameter roles. For a tool with complex parameters, this is decent but not exhaustive.
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 ('generate') and a comprehensive resource list: UUIDs, passwords, tokens, integers, coins, dice, shuffle/pick. It names all kinds and gives a clear picture of the tool's domain. It also mentions the cryptographic security and backend (Node's CSPRNG), distinguishing it from typical random tools. Although sibling tools are mostly unrelated, the description makes the tool's unique value obvious. The verb is implied but the resource is explicit and rich, earning a top score.
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 clearly implies the tool is for generating random values, and it enumerates many use cases (UUIDs, passwords, tokens, etc.). It does not explicitly state when not to use it or list alternative tools, but given the sibling set is mostly unrelated (data lookup tools), the absence of exclusions is acceptable. The description implicitly tells an agent to use this tool for any random generation need, which is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
May I crawl this? Checks a URL against the site's robots.txt for any user-agent, lists sitemaps and crawl-delay, and reports which AI crawlers (GPTBot, ClaudeBot, PerplexityBot, Google-Extended…) the site blocks. Standard robots.txt matching (longest match wins, Allow beats Disallow on ties, * and $ wildcards). Missing robots.txt = everything allowed. Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | ||
| user_agent | No | MAD-Synapse |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses pricing, free-tier limits, robots.txt matching rules, and the AI crawler list. This adds meaningful behavioral and cost transparency that annotations do not 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?
Four sentences, each with a distinct role: use-case question, core functionality, matching rules/missing-robots behavior, and pricing. No redundant or filler 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 description lists what the tool reports (sitemaps, crawl-delay, AI crawlers) and explains edge cases (missing robots.txt, matching rules), which is sufficient given no output schema. The main gap is not describing the response format, but the listed data points give agents enough to know 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 schema coverage at 0%, the description carries the parameter burden. It explains that a URL is checked and that the check works for any user-agent, implicitly covering the user_agent parameter, but it never explicitly maps to the parameter names or notes the default value 'MAD-Synapse'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with the question 'May I crawl this?' which immediately states the tool's purpose: checking a URL against robots.txt. It enumerates specific outputs (sitemaps, crawl-delay, blocked AI crawlers) and names several AI crawlers, distinguishing this from generic web tools like web_read or http_probe.
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 question 'May I crawl this?' provides a clear usage context, and the note about missing robots.txt meaning everything allowed gives practical guidance. It does not explicitly name alternatives or state when not to use the tool, so it misses the full 'when-not' criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The pump.fun wallets with the best realized PnL in the last 24 h — and the tokens those wallets are buying right now. Leaderboard of wallets by realized profit on fully-closed curve positions (min 8 closed, rebuilt every 30 min), sortable by PnL, win rate or ROI, plus a live feed of what the top 50 bought in the last N minutes, ranked by how many of them piled in. Price: $0.02 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | pnl | |
| limit | No | ||
| window_min | No | look-back for buying_now | |
| exclude_bots | No | drop sub-20-second and high-frequency wallets |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is already covered. The description adds behavioral context beyond annotations: data is rebuilt every 30 minutes, requires min 8 closed positions, and includes pricing details ($0.02 per call, 10 free/day). This is valuable but not exhaustive.
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 paragraph but is information-dense with no filler. It front-loads the core purpose and includes pricing and refresh cadence. It is slightly long but each 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?
No output schema exists, so the description carries the burden of explaining the return structure. It does so by describing the leaderboard and live feed composition, including sorting and ranking criteria. It covers data freshness, cost, and filter constraints, making it sufficient for an agent to call 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 50% (window_min and exclude_bots have descriptions). The description explains sort options (PnL, win rate, ROI) and the 'last N minutes' for window_min, but does not clarify the 'limit' parameter beyond 'top 50' implicitly. It partially compensates for schema gaps but not fully.
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 clear verb (leaderboard and live feed) with a specific resource (pump.fun wallets with best realized PnL). It distinguishes itself from siblings by focusing on smart money tracking with realized profit and recent buys, which is unique among the listed 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 implies usage for tracking profitable pump.fun wallets and their recent token buys, but it does not explicitly mention when to use this tool versus alternatives like pump_pulse or pump_dev. No exclusion or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Solana right now: TPS (total and non-vote), slot and block height, epoch progress and ETA, priority-fee percentiles, cluster version. Read from mainnet RPC: recent performance samples, epoch info, prioritization fees. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds useful context by stating it reads from mainnet RPC and that it is free, which the annotations do not provide. No contradictions; missing return-shape details are minor given the zero-parameter read-only nature.
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 compact sentences with no filler. The first front-loads the key metrics, and the second adds source and cost information. It does not repeat annotation values or schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-input, read-only status tool with rich annotations, the metric enumeration plus source and price is complete. Although there is no output schema, the description lists the fields an agent can expect, so nothing needed to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and schema coverage is 100%, so the baseline is 4. The description correctly implies no input is needed, and its metric list tells the caller what information will be retrieved without needing parameter elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource (Solana mainnet) and enumerates the exact metrics returned: TPS, slot/block height, epoch progress/ETA, priority-fee percentiles, and cluster version. This clearly distinguishes it from sibling tools like bitcoin_network and chain_tvl.
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 whenever current Solana network status is needed, and the 'Solana right now' phrasing signals a real-time read. However, it never states when to prefer this tool over alternatives, when not to use it, or any exclusions relative to related Solana or network-status tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every stablecoin's circulating supply, 1 d/7 d/30 d supply change, current price and peg deviation — spot depegs and mint/burn flows. DefiLlama stablecoin data across all chains. Filter by symbol or peg type. peg_deviation_pct is measured against the peg (USD, EUR…) using DefiLlama's price. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| peg | No | any | |
| limit | No | ||
| symbol | No | e.g. USDC, USDe, PYUSD (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds value by explaining the peg deviation measurement methodology (against peg using DefiLlama's price) and noting the data is free. This gives useful context beyond the safe read-only hint.
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 front-loaded with the core data points in the first sentence, then adds source, filtering, and measurement details. No fluff; every sentence adds information about what the tool does or returns.
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 lists the expected data fields (supply, supply changes, price, peg deviation) and mentions filtering, which sets clear expectations. It omits details like pagination or sorting, but these are likely minor for this use case.
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 only 33%, so the description's 'Filter by symbol or peg type' compensates by clarifying the intent of two parameters. The limit parameter is self-explanatory. The description also mentions peg_deviation_pct, which appears in the output, helping agents understand the tool's response.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States 'Every stablecoin's circulating supply, 1 d/7 d/30 d supply change, current price and peg deviation' — a specific resource and data set. The mention of 'spot depegs and mint/burn flows' differentiates it from sibling price tools like crypto_price or price_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?
While it doesn't explicitly name alternatives, it provides clear context by describing filterable dimensions (symbol, peg type) and concrete use cases (spotting depegs, mint/burn flows). This is enough for an agent to recognize when to delegate to this tool over generic price or chain TVL tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Sunrise, sunset, golden hour, twilight, day length and solar noon for any place and date — plus moon phase, illumination, moonrise and moonset. Astronomical calculation (SunCalc), exact and instant. Pass tz for local times. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA zone for local times | |
| date | No | default today (UTC) | |
| place | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it's an 'astronomical calculation (SunCalc), exact and instant,' and notes the price is free. It also clarifies the date defaults to today (UTC) via the schema, and that tz affects local time output.
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 wasted words. It front-loads the core outputs, then adds the calculation method, the tz hint, and the price. 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?
For a read-only calculation tool with no output schema, the description covers the inputs (place, date, tz), the outputs (sun, moon, twilight values), and the behavioral traits (exact, instant, free). It doesn't specify the exact return format, but the absence of an output schema and the tool's simple nature make this a minor 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?
Schema description coverage is 67%: place has no description, while tz and date are described. The description compensates by explaining that tz is for local times and that date defaults to today (UTC), which adds meaning beyond the raw schema. The place parameter remains minimally documented, but its purpose is obvious from the tool's name and 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 names a specific verb ('Sunrise, sunset...') and enumerates the exact resources and computed values: sunrise, sunset, golden hour, twilight, day length, solar noon, moon phase, illumination, moonrise, and moonset. It clearly distinguishes itself from sibling tools like weather or time_convert by focusing on astronomical calculations for any place and date.
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 states the tool is for 'any place and date' and mentions passing tz for local times, which gives clear context for when to use it. It doesn't explicitly name alternatives or exclusions, but the sibling list contains no other astronomy tool, so the usage context is sufficiently clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Diff two texts: unified diff (patch format), a line/word-level change list, and similarity % — compare versions of a doc, config or code. jsdiff. mode=lines gives a unified patch; mode=words gives word-level changes for prose. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| a | Yes | ||
| b | Yes | ||
| mode | No | lines | |
| context | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and non-destructive behavior. The description adds useful behavioral detail beyond that: it names the underlying library (jsdiff) and explains what each mode produces. It stops short of describing the exact return shape, but for a pure read-only compute tool this is 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?
The description is compact and front-loaded: the core purpose and output types appear in the first sentence, followed by mode behavior and a cost note. Every sentence contributes useful information, with no fluff or repetition.
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 tool's main purpose and mode selection, but with no output schema it leaves some gaps: the meaning of context is not explained, and the exact shape of the returned change list or similarity percentage is not specified. For a moderate-complexity tool, this 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?
Schema description coverage is 0%, so the description must compensate. It clarifies that a and b are the two texts and explains mode semantics well, but it says nothing about the context parameter, which controls the number of context lines in the patch. That leaves one of four parameters semantically 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 states a specific verb and resource ('Diff two texts') and enumerates distinct outputs: unified diff/patch, line/word-level change list, and similarity percentage. It also gives concrete use cases (doc, config, or code), which separates it from siblings like text_stats or markdown_convert.
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 gives clear context for when to use the tool ('compare versions of a doc, config or code') and explains mode selection: mode=lines for a unified patch, mode=words for prose. It does not explicitly exclude alternatives, but no sibling tool provides diffing, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Count characters, words, sentences, lines and paragraphs, estimate LLM tokens, reading time and readability (Flesch), and pull out every URL, email, @handle, #tag, number and crypto address. Token count is an estimate (~4 characters per token for English; code and non-Latin scripts differ). Extraction uses strict patterns; EVM addresses are checksum-validated. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| extract | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the read-only, idempotent, non-destructive nature of the tool. The description adds valuable behavioral nuance: token count is approximate (~4 characters per token), extraction uses strict patterns, and EVM addresses are checksum-validated. This sets accurate expectations beyond what annotations provide.
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 dense but every clause adds an output category or an important caveat. Caveats are placed at the end, keeping the main capability list front-loaded. The trailing 'Price: free' is slightly tangential but not harmful.
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 produces many distinct output categories and has no output schema, yet the description does not explain the result shape or how the `extract` boolean alters the response. It is sufficient for selecting the tool, but leaves an agent without a clear expectation of the return structure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to explain both parameters. The `text` parameter is implied clearly by the prose, but the `extract` boolean is not mentioned at all; an agent cannot determine what setting it to false does or whether extraction is optional.
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 concrete verbs and resources: 'Count characters, words, sentences, lines and paragraphs', 'estimate LLM tokens', and 'pull out every URL, email, @handle, #tag, number and crypto address'. It is clear about the tool's function, but it does not explicitly differentiate from sibling tools such as text_diff or markdown_convert.
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 about when to use this tool versus alternatives, no named sibling tools, and no exclusion criteria. The phrase 'Price: free' is cost information, not usage guidance. An agent must infer appropriate usage from the feature list alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Current time in any time zones, convert a time between zones (DST-correct), and date arithmetic: add/subtract durations, days between dates, weekday, ISO week, Unix time. Computed locally from the IANA time-zone database — no rate limits, exact. Zones are IANA names (America/New_York, Asia/Tokyo, UTC). Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| add | No | e.g. "+3d 4h", "-90m", "+2w" | |
| time | No | ISO time, "now", or a Unix timestamp; naive times are read in from_tz | |
| to_tz | No | ||
| until | No | second ISO date: returns the difference | |
| from_tz | No | UTC |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so the description doesn't need to repeat those. It adds valuable behavioral context beyond annotations: 'Computed locally from the IANA time-zone database — no rate limits, exact' and 'DST-correct' and 'Price: free.' This informs the agent about reliability, performance, and cost without contradicting 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 three sentences with no fluff. It front-loads the primary functions, then adds reliability and cost details, and finishes with zone format examples. Every sentence earns its place, and the structure is logical 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?
The description covers the tool's capabilities and some operational details (local computation, no rate limits, free). However, it does not specify the output format or structure (e.g., returns a string, an array of converted times, or a diff object), and there is no output schema to compensate. It also doesn't mention behavior for invalid inputs or edge cases like overlapping DST transitions. For a tool with 5 parameters and no output schema, this is a noticeable gap, though the core purpose is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 60% (3 of 5 parameters have descriptions). The description compensates for the undocumented to_tz and from_tz by stating 'Zones are IANA names (America/New_York, Asia/Tokyo, UTC).' This clarifies the expected format. It also reinforces the 'add' parameter with 'add/subtract durations' and the 'until' parameter with 'days between dates,' adding context beyond the schema. The added value lifts it above the 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 the tool's capabilities with specific verbs: get current time, convert between zones (DST-correct), and perform date arithmetic (add/subtract durations, days between, weekday, ISO week, Unix time). It names the resource (time zones, dates) and distinguishes itself from the sibling unit_convert by focusing on time-specific operations. No ambiguity about what the tool does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case—time zone conversion and date math—but does not explicitly mention when to choose this over alternatives or when not to use it. It lacks exclusions or alternative tool references (e.g., 'For unit conversions, use unit_convert'). The context is clear enough for an agent to infer, but explicit guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A site's TLS certificate: issuer, validity, days until expiry, SANs, protocol, cipher, chain and whether browsers trust it. Live TLS handshake to the host. Flags expired, expiring (< 14 days), untrusted or name-mismatched certificates. Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| host | Yes | ||
| port | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it performs a live TLS handshake (network call with potential latency), flags certificates expiring within 14 days, and mentions pricing ($0.001 per call, 10 free/day), which is a cost-related behavioral trait an agent should know. It does not mention timeouts or failure behavior, but the live-handshake disclosure is meaningful.
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, all information-dense. The first sentence front-loads the core purpose and output fields. The second explains the mechanism. The third adds flags and pricing. No filler, no repetition of schema defaults, and 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?
For a read-only, idempotent tool with only two simple parameters, the description is nearly complete. It covers what the tool returns, how it works, what it flags, and cost. The only gaps are minor: no explicit statement about timeout/error behavior for unreachable hosts, and no mention of whether the port parameter accepts non-443 values (though the schema's min/max and default make that clear). Overall, an agent has enough to call 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 description coverage is 0%, so the description must compensate. It does: 'host' is clearly the target hostname for the TLS handshake, and the port is implied by the TLS context (default 443). The description doesn't explicitly say 'port defaults to 443', but the schema already provides that default, and the TLS framing makes the port's purpose obvious. The description adds meaning by explaining what the tool does with the host, which the bare schema 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 states a specific verb ('checks') and resource ('a site's TLS certificate'), and enumerates the exact data returned: issuer, validity, days until expiry, SANs, protocol, cipher, chain, and browser trust. It also names the live handshake mechanism and the specific flags (expired, expiring <14 days, untrusted, name-mismatched), which clearly distinguishes it from sibling tools like dns_lookup, domain_whois, or http_probe.
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 when to use it: when you need TLS certificate details, expiry warnings, or trust validation for a host. It does not explicitly name alternatives or state when not to use it, but the detailed scope (TLS-specific, not DNS or WHOIS) makes the context clear. A small gap: no explicit exclusion like 'for DNS records use dns_lookup instead'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
0-100 rug-risk score for any Solana token: mint/freeze authority, Token-2022 traps, holder concentration, liquidity depth — plus pump.fun curve flags. Contract state is read live from Solana (authorities, Token-2022 extensions such as transfer fees, hooks, permanent delegate, pausable), holders from the largest accounts, market from DexScreener. For pump.fun mints the curve forensics flags are merged in. Price: $0.005 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| mint | Yes | token mint |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the description need not repeat those. It adds valuable behavioral context: contract state is read live from Solana, holders from largest accounts, market from DexScreener, and pricing ($0.005 per call, 10 free/day). This is beyond annotations and informs the agent about cost and data freshness. No contradictions.
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 moderately long but efficient; each sentence adds detail about what the score covers and where data comes from. It is front-loaded with the core outcome (0-100 rug-risk score) and avoids fluff. Slightly dense but well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema, the description clearly explains what the tool returns (a score) and the data sources, which is sufficient for an agent to know what to expect. It does not detail the exact score interpretation or error cases, but given the complexity and annotations, it is reasonably 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 schema has 100% description coverage for the single parameter (mint) with a regex pattern. The description does not add further detail about the parameter beyond what the schema provides, but that is acceptable given full schema coverage. The baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource: computes a 0-100 rug-risk score for any Solana token. It enumerates the risk factors (mint/freeze authority, Token-2022 traps, holder concentration, liquidity depth, pump.fun curve flags) which clearly distinguishes it from siblings like price or wallet_holdings.
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 when to use it: for assessing rug risk on any Solana token, and it clarifies scope (any token, not just pump.fun). It does not explicitly name alternatives or exclusions, but the specificity of the purpose and the mention of pump.fun integration make usage clear. Missing explicit 'use X instead for Y' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Turns any Solana transaction signature into plain facts: status, fee, programs by name, SOL and token balance changes per owner, a one-line summary. Works for swaps, pump.fun trades, LP moves, transfers and failures (includes the error log lines). Price: $0.003 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| signature | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With annotations already covering readOnly, idempotent, open-world, and non-destructive behavior, the description adds meaningful context beyond them: the per-call price, free allowance, and the fact that failed transactions include error log lines. This gives the agent useful operational information without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler: the first sentence states the core behavior and output, the second defines coverage and pricing. The most important information is front-loaded, and every clause 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?
Despite lacking an output schema, the description lists the return fields in enough detail for an agent to know what to expect. The single required parameter is explained, the supported transaction categories are enumerated, and the cost is disclosed. Nothing critical is missing for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but there is only one parameter and the description explains that it is a Solana transaction signature. Combined with the schema's pattern and required flag, the agent knows exactly what to supply. The description does not add extra detail about signature formats, but the schema handles that constraint.
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 ('Turns') and a concrete resource ('Solana transaction signature'), then enumerates the exact output ('status, fee, programs by name, SOL and token balance changes per owner, a one-line summary'). It also scopes the tool to specific transaction types, which separates it from the sibling tools that target individual tokens, wallets, or pools.
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 clearly communicates context by listing supported cases: swaps, pump.fun trades, LP moves, transfers, and failures. It does not explicitly name alternatives or state when not to use this tool, but for a general-purpose transaction explainer the intended usage is clear and well-scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert between units of length, mass, volume, temperature, speed, area, time, data size, energy, power, pressure, frequency and more — or list every unit a value converts to. Exact conversion tables (convert-units). Use abbreviations: m, km, mi, ft, kg, lb, oz, l, gal, C, F, K, km/h, mph, knot, B, KB, MB, GB (binary, 1 GB = 1024 MB), J, kWh, W, Pa, bar, psi, Hz… Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | omit to get every compatible unit | |
| from | Yes | ||
| value | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare the tool read-only, idempotent, and non-destructive. The description adds useful behavior beyond that: exact conversion tables, a list-all mode when 'to' is omitted, and a binary data-size convention. This gives the agent a clear model of what the tool does without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main behavior before moving to examples and details. It avoids repeating the schema except for the beneficial 'omit to get every compatible unit' hint, though the trailing 'Price: free' and ellipsis are minor additions.
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 read-only converter with no output schema, the description gives the necessary unit vocabulary, the list behavior, exactness, and binary sizing. It stops short of describing response shape or error handling for unsupported units, but those are less critical given 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?
With only 33% schema description coverage, the description compensates by listing concrete accepted abbreviations for from/to and clarifying binary units. It does not map every abbreviation to its dimension, but it provides enough value to meaningfully supplement the sparse 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 clear verb and resource: it converts between named unit categories and can list all convertible units. The category list is specific, though the trailing 'and more' leaves scope slightly open and the description does not explicitly separate it from the sibling time_convert.
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 about when to use this tool instead of related siblings like time_convert, price, or fx_rates. The description covers time units among many categories but never states exclusions or when the specialized sibling tools should be preferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Known security vulnerabilities for a package version (npm, PyPI, crates, Go, Maven, NuGet, RubyGems, Packagist) with severity, CVE/GHSA ids, and the version that fixes each. Queries OSV.dev, the open vulnerability database that aggregates GitHub advisories, PyPA, RustSec, Go and more. Pass up to 50 packages at once as "ecosystem:name@version" to audit a lockfile. Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| version | No | ||
| packages | No | e.g. ["npm:lodash@4.17.15","pypi:requests@2.19.0"] | |
| ecosystem | No | npm |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds valuable context beyond that: it queries OSV.dev, aggregates multiple advisory sources, and discloses the cost and free-tier limit. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, all useful and front-loaded: purpose and output, data source, then usage pattern and cost. There is no fluff or repetition of schema/annotation 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?
The description covers the main invocation mode, output contents, external source, and rate/cost behavior even though there is no output schema. It does not explicitly address empty results, error behavior, or when to prefer name/version vs packages, but an agent has enough information to call 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 coverage is only 25%, so the description carries the burden, and it compensates well by defining the 'ecosystem:name@version' format, the 50-package max, and the supported ecosystems. The individual name/version/ecosystem fields remain implicit, but the single-package usage is inferable from the opening sentence.
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 operation: checking for known security vulnerabilities in a package version. It enumerates supported ecosystems and the exact output fields (severity, CVE/GHSA IDs, fixing version), clearly distinguishing this tool from sibling data tools like package_info or 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?
It explicitly explains the batch usage pattern: pass up to 50 packages as 'ecosystem:name@version' to audit a lockfile, and identifies the OSV.dev data source. It does not explicitly mention when not to use the tool or name a sibling alternative, so it misses the top score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything a Solana wallet holds — SOL, SPL and Token-2022 tokens — valued in USD and sorted by value. Reads token accounts from both token programs and prices them in one pass. Empty accounts are counted as reclaimable rent. Price: $0.003 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| wallet | Yes | wallet address |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructiveness. The description adds valuable behavioral detail beyond those: it reads token accounts from both token programs, prices them in one pass, counts empty accounts as reclaimable rent, and discloses the per-call price. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the first sentence states the core purpose, followed by useful operational details and pricing. Every sentence earns its place, and there is no fluff or repetition of schema 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 simple read-only tool with one parameter, complete annotations, and no output schema, this description covers everything an agent needs: input, scope of assets, valuation method, sorting, token-program coverage, rent handling, and cost. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage and a single wallet parameter, the schema already documents the only input. The description does not add parameter-level detail beyond confirming it is a Solana wallet address, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states exactly what the tool does: it enumerates everything a Solana wallet holds, specifically SOL, SPL tokens, and Token-2022 tokens, valued in USD and sorted by value. This is a specific verb-resource pair with clear scope, and it is distinct enough from siblings like pump_wallet or smart_money to avoid 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?
The description clearly implies when to use this tool: any time you need a complete, USD-valued snapshot of a Solana wallet's holdings across both token programs. It provides clear context, though it does not explicitly name sibling alternatives or state 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.
Current weather and hourly/daily forecast for any place name or lat,lon: temperature, feels-like, wind, gusts, rain, cloud, humidity, UV — up to 9 days. Forecast from the Norwegian Meteorological Institute (MET Norway), the same model data yr.no uses, worldwide. Place names are geocoded with OpenStreetMap. Times are UTC plus local time when tz is given (IANA, e.g. Australia/Sydney). Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| tz | No | IANA time zone for local times (optional) | |
| days | No | ||
| place | Yes | city/address or "lat,lon" |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnly/idempotent/non-destructive safety, so the description adds extra value by disclosing data provenance (MET Norway/yr.no), geocoding via OpenStreetMap, UTC/local time behavior with IANA tz, the 9-day limit, and per-call pricing. This goes well beyond structured annotations and helps the agent anticipate costs and output semantics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core function and data elements appear first, followed by source, geocoding, time, and pricing in a few sentences. Every sentence carries information and no words are wasted.
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 read-only data lookup with no output schema, the description provides a rich picture: metrics, forecast length, place format, time handling, provider, and cost. Minor gaps remain — units (Celsius/Fahrenheit) and error behavior for unknown places — but these do not prevent 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 coverage is 67% (place and tz are described, days is not). The description clarifies 'any place name or lat,lon' and explains how tz affects output, and implicitly adds meaning to days by tying it to the forecast length ('up to 9 days'). It effectively compensates for the undocumented days 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 states a specific function (current weather + hourly/daily forecast) for a resource (any place name or lat,lon) and enumerates the data fields. It clearly differentiates from siblings like geocode or sun_moon by specifying weather metrics and forecast range.
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 use case — obtain weather for a place — and adds useful context about data source and time handling. It does not explicitly name alternatives or exclusions, but no direct sibling weather tool exists, so the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Everything a page says about itself: title, description, OpenGraph/Twitter card, canonical, favicon, language, RSS/Atom feeds, JSON-LD schema types, headings — and link-preview problems. Use to build link previews, check SEO/social cards, find a site's feeds or structured data. Flags missing og:image, missing description and non-absolute image URLs (common reasons a link shows up bare on X/Telegram). Price: $0.001 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds value beyond these by detailing what it returns (JSON-LD types, headings, etc.) and flagging common link-preview issues (missing og:image, non-absolute URLs). It also discloses pricing. This goes beyond annotations and provides useful behavioral context, though it doesn't cover every edge case like redirect 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 informative but slightly long. It front-loads the core purpose and lists many data points, then gives use cases and pricing. Every sentence earns its place, and the structure is logical. It could be trimmed slightly, but 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?
With no output schema, the description carries the full burden of explaining return values. It lists what is extracted (title, description, OpenGraph, feeds, JSON-LD, headings) and flags common problems. It also includes pricing and free quota. For a single-parameter tool, this is complete and covers all needed information for an agent to call 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?
There is only one parameter, url, and schema description coverage is 0%. The description implies the URL is a page but does not explicitly state format requirements (e.g., http/https, valid URL). Since the parameter name is self-explanatory and the tool context makes it obvious, it adds minimal extra meaning beyond what the schema provides. A more explicit note on URL format would have improved 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 tool's purpose with a specific verb ('Everything a page says about itself') and enumerates the exact data it extracts (title, description, OpenGraph, etc.). It distinguishes itself from siblings like web_read by focusing on metadata and link-preview problems, leaving no ambiguity about what it does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit use cases: 'Use to build link previews, check SEO/social cards, find a site's feeds or structured data.' However, it does not explicitly state when not to use it or mention alternatives like web_read for full content, leaving some room for an agent to mis-select. The use cases are clear enough, but exclusionary guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Any public URL → clean readable markdown: the article/main content without nav, ads or boilerplate, plus title, author, date, word count and links. PDFs too. Fetches the page (redirects followed, public internet only), extracts the main content with Mozilla Readability and converts it to markdown. PDFs are converted to text. Use max_chars to bound the output. JavaScript-only pages return whatever the server sends (no headless browser). Price: $0.002 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | http(s) URL | |
| max_chars | No | ||
| include_links | No | keep hyperlinks (absolute) in the markdown and return a link list |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, covering safety. The description adds valuable context beyond annotations: it uses Mozilla Readability, handles PDFs by converting to text, follows redirects, and explicitly states the limitation on JS-only pages. It also discloses pricing. This fully rounds out the 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 front-loaded with the core promise, then explains mechanics, limitations, and pricing in a logical order. It is a bit long but every sentence adds value—no fluff. The structure is clean and readable.
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 specifies what the output contains (title, author, date, word count, links) and covers important edge cases (PDFs, JS-only pages, public internet only). It does not explicitly mention error handling or timeouts, but for a simple read tool the information is sufficient for an agent to call 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 schema covers url and include_links with descriptions; max_chars lacks a schema description but the tool description explains 'Use max_chars to bound the output', adding meaning. It also clarifies include_links behavior implicitly through the output description (links in markdown). With 67% schema coverage, the description compensates for the missing parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Read a web page' and 'Any public URL → clean readable markdown'. It clearly describes the main content extraction without nav/ads/boilerplate, includes PDF support, and is distinct from siblings like web_meta, http_probe, or markdown_convert. An agent can immediately tell what this tool does and what it is not.
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 clear context: public internet only, redirects followed, PDFs converted, and a critical limitation for JavaScript-only pages (returns server-sent content). It also advises using max_chars to bound output. It does not explicitly name alternatives, but the behavior described implicitly guides when to use it (static content, not dynamic pages).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Wikipedia in any language: search a topic and get the best article's summary, description, thumbnail and link — or the full article text. Search + REST summary from Wikipedia. full=true returns the article as plain text (sections kept), capped by max_chars. Disambiguation pages are flagged with alternatives. Price: free.
| Name | Required | Description | Default |
|---|---|---|---|
| full | No | ||
| lang | No | en | |
| query | Yes | ||
| max_chars | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, open-world, idempotent, and non-destructive behavior. The description adds value by explaining that full=true returns plain text capped by max_chars, that disambiguation pages are flagged with alternatives, and that the tool is free. It does not discuss error or no-result behavior, but the described behavior goes beyond what annotations provide.
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?
Four short sentences front-load the main purpose and then cover key behaviors (full-text cap, disambiguation, free cost) in decreasing importance. There is no filler; 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?
The description is complete for an agent to decide and invoke the tool: purpose, output types, language support, full-text behavior, character cap, and disambiguation are all covered. Given no output schema, it could be slightly stronger about no-result or error cases, but this is a minor 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?
With 0% schema description coverage, the description carries the burden of parameter meaning. It maps query to 'search a topic', lang to 'any language', full to 'full article text as plain text', and max_chars to the cap on that text. It does not restate schema defaults or min/max, but it adds meaningful usage semantics for all four parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States specifically that it searches Wikipedia in any language and returns the best article's summary, description, thumbnail, and link, or full text via full=true. This clearly identifies the tool's verb, resource, and output, and distinguishes it from sibling search tools like arxiv_search or web_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?
The description makes the intended context clear—Wikipedia lookup in any language with a choice between summary and full text—but it never explicitly names sibling alternatives or states when not to use this tool. It implies usage rather than giving explicit exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ~19,000 DeFi yield pools across all chains: filter by chain, protocol, token, stablecoin-only, min TVL; sort by APY or TVL. Base vs reward APY, 30 d mean, IL risk. DefiLlama yields data, refreshed every 15 minutes. Shows APY split into base (organic fees/interest) and reward (token emissions), the 30-day mean APY so an agent can spot unsustainable spikes, impermanent-loss risk, exposure (single/multi) and DefiLlama's up/down prediction. Price: $0.003 per call (10 free/day).
| Name | Required | Description | Default |
|---|---|---|---|
| sort | No | apy | |
| chain | No | e.g. Ethereum, Solana, Base, Arbitrum | |
| limit | No | ||
| token | No | token symbol that must appear in the pool, e.g. USDC, SOL | |
| max_apy | No | drop absurd APYs above this | |
| project | No | protocol slug, e.g. aave-v3, kamino-lend, uniswap-v3 | |
| min_tvl_usd | No | ||
| stablecoin_only | No | ||
| single_exposure_only | No | no LP pairs (no impermanent loss) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint, openWorldHint, idempotentHint, and destructiveHint, but the description adds meaningful behavior beyond them: 'refreshed every 15 minutes', '$0.003 per call (10 free/day)', and detailed output semantics like base vs reward APY, 30-day mean, IL risk, exposure, and DefiLlama's prediction. This gives the agent a clear picture of cost, freshness, and return richness.
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 dense but every clause earns its place: purpose, filters, data source, refresh rate, metric semantics, and pricing. It is front-loaded with the search action and key filters. The long first sentence is slightly crammed, but there is no fluff or repetition.
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 compensates by explaining the return content—APY split, 30-day mean, IL risk, exposure, and prediction—so the agent knows what results look like. Combined with annotations covering safety and idempotency, and defaults in the schema, the tool is fully specified 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 coverage is only 56%, so the description carries responsibility for clarifying parameters. It does this by grouping filters ('chain, protocol, token, stablecoin-only, min TVL') and explaining output fields that map to sort and single_exposure_only semantics. It doesn't explicitly define limit or max_apy, but those are simple and partly documented in the schema, so the compensation 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 opens with 'Search ~19,000 DeFi yield pools across all chains'—a specific verb and resource that immediately defines the tool's scope. It goes on to list concrete filters and returned metrics (APY split, 30-day mean, IL risk), which clearly distinguishes it from sibling tools like defi_protocol or defi_rankings.
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 makes the use case obvious—finding, filtering, and sorting yield pools from DefiLlama data—while noting specific capabilities like stablecoin-only filtering and IL risk. It does not explicitly name alternatives or state when not to use it, but the context is strong enough to guide selection among the large sibling list.
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.
address_checkarxiv_searchbitcoin_networkbook_searchcex_tickerchain_tvlcountry_infocron_explaincrypto_pricedefi_protocoldefi_rankingsdex_volumesdns_lookupdoi_lookupdomain_whoisearthquakesemail_checkens_resolveerc20_infoevm_addressevm_token_securityevm_txfear_greedfees_revenuefunding_ratesfx_ratesgas_nowgeocodegithub_repohash_encodehn_searchholidayshttp_probehyperliquid_marketsjson_schema_validatejwt_decodemarkdown_convertorderbook_depthpackage_infoprice_historyqr_coderandom_genrobots_checksolana_networkstablecoinssun_moontext_difftext_statstime_converttls_checkunit_convertvuln_checkweatherweb_metaweb_readwikiyield_poolscopy_backtestpump_historycounterparty_checkdlmm_pooldlmm_positionsdlmm_whaleslaunch_scanpricepump_devpump_launchespump_oddspump_pulsepump_tokenpump_walletsmart_moneytoken_risktx_explainwallet_holdingsSolana address risk grades and token scans for AI agents. Pay-per-call via x402 (USDC on Base).
Pay-per-call Solana data over x402 for AI agents: balances, tokens, txs, risk and MCP trust checks.
Pre-trade token safety checks for AI agents on Solana and Base. x402 USDC per call, no key.
Solana onchain intelligence for AI agents: wallet risk, due-diligence, perps funding, smart money.
Add one secure layer between your agents and this server.
