SwogeAgentic

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Descriptions add substantial behavioral detail beyond the annotations: it names SwogeAgentic (a Claude agent) as the executor, explains it reads numbers and answers in Markdown with sources and sample sizes, discloses the API-key-only requirement, real-cost billing, optional quote behavior, and expected latency. All consistent with readOnlyHint=true and openWorldHint=true, 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?

The description is compact yet information-dense. It front-loads the purpose, then covers the agent behavior, costing, and timing. No filler sentences; every clause adds operational or decision-relevant information. Length is appropriate for the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool that chains multiple other tools and produces a written answer, the description covers all critical aspects: when to use, how it operates, cost model, timeout expectations, and output format (Markdown with sources and sample sizes). With no output schema, the description compensates fully. An agent has enough 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?

Schema coverage is 100%, so each parameter is already documented. The description adds semantic value by explaining the 'quote' parameter in context (returns price without running) and framing the overall task as research. It goes beyond schema repetition by linking parameters to real-world usage and cost implications.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific purpose: chaining several tools together to produce a written answer, with concrete examples (comparing tokens, researching a launcher). It distinguishes itself from sibling tools by emphasizing the multi-tool orchestration and written response, leaving no ambiguity about its role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use it: when a question needs several tools chained and a written answer. Provides examples and practical constraints (API key required, 10-60 seconds latency, cost model). The description effectively implies that simple queries should use individual tools, and gives enough context to route the agent correctly.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint and openWorldHint already declared, the description adds valuable behavioral context: the data window is 'what SWOGE indexed on-chain' and it discloses a minimum threshold ('below 5 judged tokens it does not compare'). It does not mention authentication or rate limits, but the added provenance and comparison limitations are substantive.

Agents need to know what a tool does to the 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 usage condition and then details the return value. It is information-dense and every sentence contributes, though it is somewhat long and could be slightly more structured for scanning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 thoroughly explains what is returned (swaps in 1h/24h, price change, share traded with 95% interval) and caveats (data window, minimum sample). This is complete for an agent to correctly interpret the tool's output without additional output 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%, so the schema already documents both parameters (including the quote flag and address format). The description adds no parameter-specific meaning beyond what the schema provides, 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 states a specific verb and resource: 'track record of an address that launches tokens on Base (Clanker v4 or Zora)'. It explicitly lists the returned data—launches, swaps, price changes, share traded—making it clearly distinct from sibling tools like base_launches or wallet_intel.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 opening 'Use this when you need the track record of an address that launches tokens on Base' gives clear usage context. However, it does not name alternatives or state when not to use it, so it falls short of the 5-level criterion for explicit alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered; the description adds genuine value beyond that. It discloses data provenance (Uniswap v4 PoolManager, on-chain reads), the small-sample behavior ('Below 5 judged tokens the record says so instead of comparing'), and an explicit interpretation guard ('Measurements, never a buy or sell signal'). It omits cost/rate-limit behavior and how the 1-hour vs 24-hour windows are bounded.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded correctly: the when-to-use trigger comes first, mechanics second, caveat and disclaimer last. The single dense paragraph packs several ideas into long compound sentences, so it reads as slightly overloaded, though nearly every clause carries information rather than 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?

There is no output schema, so the description must carry the return shape — and it does, enumerating per-launch fields (platform, deployer, age, swaps in the first hour and 24 hours, price change) and per-deployer aggregates with their comparison baseline. Combined with the 1-25 limit and the caveat about thin samples, an agent has enough to call it 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?

Schema description coverage is 100%, including the non-obvious quote dry-run flag and the traded_only filter, so the schema carries the parameter burden. The description adds conceptual color around the swap windows but no syntactic or default detail beyond what the schema already states. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a precise resource and scope: newest memecoin launches on Base, restricted to Clanker v4 and Zora coins, read on-chain. That is a specific verb+resource with concrete platform boundaries. What it never does is differentiate itself from the sibling new_launches, so an agent has no textual basis for choosing between 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 opens with an explicit trigger condition ('Use this when you want the newest memecoin launches on Base'), which is clear context for invocation. However, it gives no exclusions and never names an alternative (e.g. new_launches, base_deployer, token_verdict), so the agent must infer when another tool is the better fit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnlyHint/openWorldHint annotations: it explains the simulation method (real holders attempt transfers, Uniswap quoting), enumerates verdict outcomes (sellable, costly, blocked, partial), and discloses billing behavior (only an answer is billed; unknown or untestable exits are free). It also frames the result as a simulation, not a signal. This is rich, non-obvious behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the usage trigger, then method, then output and billing caveats, so an agent reads the most important line first. Dense but nearly every sentence adds information; the closing 'never a buy or sell signal' disclaimer is useful but slightly padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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-shape burden and does so well: it lists the verdict, round-trip return and cost, transfer test, and LP-burn share. Combined with billing behavior and caveats, an agent has everything needed 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 100%, so both the address and quote parameters are already documented in the schema, and the description adds no format or syntax detail beyond it. The billing sentence loosely relates to the quote flag but comes from the behavioral angle rather than parameter semantics. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource: simulates a token exit on Robinhood Chain to determine whether the token can be sold back and at what cost. The scope (on-chain exit simulation, buy-then-sell round trip on Uniswap) clearly distinguishes it from siblings like scan_token or new_launches without needing to 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?

Gives explicit timing context: 'Use this right before buying a Robinhood Chain token,' which frames a clear trigger. It does not name alternative tools or state when not to use it, but the intended usage moment is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only give readOnlyHint/openWorldHint, so the description carries the interesting burden and does so well: price is quoted from input + max_tokens at model rate plus margin, failed calls are not charged, and output is text-only. It omits rate limits, latency, and whether prompts are retained, and does not address the tension that a read-only-flagged tool still spends money.

Agents need to know what a tool does to the 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, front-loaded with the when-to-use clause, then the I/O contract, then billing behavior, then the capability limit. Every sentence adds information an agent needs before invoking.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 correctly names the return shape (choices, usage), covers the model families, cost mechanics, and text-only limitation, which is enough to call it correctly. Missing only operational context such as rate limits, latency expectations, and prompt data handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains model, quote, messages and max_tokens; the baseline is 3. The description reinforces the OpenAI message shape and the max_tokens→price linkage but adds no format or default detail the schema lacks.

Input schemas describe structure but not intent. Descriptions should explain 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 action and resource — get one answer from a frontier model (Claude/GPT-6/Grok) without an account or API key — and pins the interface contract (OpenAI-style messages in, chat.completion out). It is clearly distinguishable from siblings like web_search or ask_agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use this when you need an answer from a frontier AI model without an account or an API key" gives a clear triggering condition, and "text only, no tools" bounds the use case. It stops short of naming an alternative (e.g. ask_agent) or stating when-not to use it, so 4 rather than 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, lowering the burden on the description. The description adds meaningful behavioral context: the colony is autonomous and paper-trading, some trades are mirrored with real money, and the output includes a paper ledger with average result and share of winners. The caveat 'Paper trades are measurements, never advice' is a useful safety disclosure beyond the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is composed of four focused sentences, with the primary use case front-loaded in the first sentence. Every sentence contributes either scope, output details, or a clarifying caveat. It is slightly verbose but remains efficient 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?

With no output schema, the description appropriately enumerates the main return contents: open positions, latest buys and sells with results and reasons, paper ledger metrics, and mirror records. It also covers optional token filtering and adds a disclaimer. It does not mention pagination, rate limits, or the quote behavior in the description itself, but the schema covers quote and the scope is otherwise sufficiently complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters are already documented in the schema. The description reinforces the token parameter by mentioning filtering by symbol or address, and also references the quote concept indirectly through 'without running or paying for it' only in the schema rather than the description. Baseline 3 is appropriate because the description adds little beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action (know what the SWOGE AI colony holds or did recently), a clear resource, and a concrete output list (positions, buys/sells, ledger, mirror record). It does not explicitly differentiate from sibling tools like wallet_intel or swoge_economy, but the resource and scope are clear enough for an agent to recognize intent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 opening phrase 'Use this when you want to know what the SWOGE AI colony... holds or did recently' provides clear contextual guidance for when to invoke the tool. It does not name alternatives or state when not to use it, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover safety (readOnlyHint=false destructive risk) and open-world scope; the description adds the trust mechanism itself – the server cannot change the seed after publishing the hash – plus the returned fields to share. It omits persistence/lifetime of the commitment and whether the seed is later disclosed only via fair_draw/fair_verify, but the added context 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?

Three tight sentences: purpose/trigger first, mechanism second, required next call last. No filler and the sequencing 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?

There is no output schema, yet the description names the exact return values (commitment_id, server_seed_hash) and tells the caller to share them, which is what an agent needs to proceed correctly. The lone parameter is covered by the schema, so nothing material 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 description coverage is 100% and there is a single parameter (quote), which the schema fully documents. The description contributes nothing about quote, 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?

States a concrete action (publish a SHA-256 hash of a server-chosen secret seed before a draw) and what it produces (commitment_id, server_seed_hash). It clearly separates itself from the sibling fair_draw (which it defers to) and fair_verify by naming its role in the commit-reveal sequence.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with an explicit trigger condition – 'Use this before any draw other players must trust (a game between agents, a raffle, a giveaway)' – and ends by routing the agent to the next step, 'Then call fair_draw.' Both when-to-use and the follow-up alternative are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Goes well beyond the readOnly/openWorld annotations: discloses that the server seed is revealed with the draw, that a commitment draws exactly once (second call returns the original draw, i.e. idempotent), that the call is paid, that the response carries replayable verification code, and spells out the HMAC-SHA256/rejection-sampling algorithm. These are exactly the behavioral traits an agent needs and that the annotations do not supply.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the trigger condition ('Use this after fair_commit...') so the routing information comes first. The second sentence is dense with algorithm, idempotency, and verifiability details, but each clause earns its place for a fairness-critical tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists, and the description compensates by describing the return (uniform integers in [min, max], revealed server seed, embedded verification code). With 100% schema parameter coverage and annotations handling the safety profile, the definition is complete enough to call 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?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning: it explains that client_seed must be chosen after seeing the server_seed_hash, and that min/max bound a uniform, bias-free result. It adds relatively little beyond the schema for quote or count.

Input schemas describe structure but not intent. Descriptions should explain 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 (draw uniform random integers in [min, max] from a commitment) and explicitly positions itself relative to fair_commit and fair_verify in the workflow. An agent can distinguish it from fair_commit and fair_verify without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the prerequisite sibling and the exact timing condition: 'after fair_commit, once every player has seen the server_seed_hash'. It also notes the quote escape hatch for pricing without paying. It does not, however, name fair_verify as the alternative for auditing the result, so the alternative side of the 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, and the description usefully adds 'Pure computation: nothing is stored,' confirming no side effects or persistence. It also discloses which scheme requires the nonce, mildly going beyond the structured data, but says nothing about what a failed/mismatched verification looks like.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence opens with the purpose and then qualifies the two modes efficiently; nothing is wasted. It is dense, packing scheme names and parameters into one long clause list, but still 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?

For a 10-parameter tool with no output schema, the description covers both computation modes and the non-storage behavior but never describes the return value (validity verdict, recomputed numbers, comparison result against the supplied 'numbers'). For a verification tool the outcome shape matters, and that gap is left unaddressed.

Complex tools with many parameters or behaviors need more documentation. 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 every parameter already carries its own description (defaults, 'swoge-casino-shoe only: the hand number', the quote flag). The description's mention of the scheme/nonce pairing largely restates what the schema already encodes, 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 names a specific verb and resource ('check a draw independently: recomputes the SHA-256...') and even enumerates the two supported schemes and what gets recomputed for each. It is clearly a verification tool rather than a draw/commit tool, but it never names the obvious siblings fair_draw or fair_commit, so differentiation is inferred rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this to check a draw independently' gives clear context for invocation and scopes it to two named schemes. It stops short of saying when not to use it or pointing to the alternative tools for generating or committing a draw.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint, but the description adds substantial behavioral context: the lookup is free ('nothing is paid'), the results are data-only with no phone number, and the follow-on purchase flow (x402 request, USDC on Base or Solana, no account, eSIM provisioned before payment settles). This goes well 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 when-to-use clause is well front-loaded, but the final two sentences are entirely about the separate buy/payment flow, including an endpoint URL and wallet mechanics, which are tangential to a read-only search tool. That space is dense and arguably belongs to a purchasing tool's description.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully characterizes the return (plan list, prices in USD, ordered by cheapest per GB) and pairs it with readOnly/openWorld annotations. It doesn't mention result limits or pagination, but for a simple filtered lookup it 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?

Schema coverage is 100%, so the schema already documents all four parameters, making 3 the baseline. The description restates the country/region enumeration and the cheapest-per-GB ordering, but adds little syntax or format detail the schema doesn't already carry.

Input schemas describe structure but not intent. Descriptions should explain 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 ('find'/'plans' for data-only travel eSIMs) with scope qualifiers: no phone number, country name or 2-letter code, or named region. Sorting ('cheapest per GB first') and price currency are included, so an agent knows exactly what this returns and how it differs from any unrelated 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?

Front-loads a clear trigger ('Use this when someone needs mobile data abroad') and adds that the search is free while purchasing requires a separate POST to the buy endpoint. No sibling overlaps exist in the list, so it doesn't need explicit exclusions, but it also doesn't spell out 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds important non-obvious behavior beyond the annotations: return format (image URLs), provider defaults, image count, and especially the billing model with and without an API key. It does not contradict readOnlyHint; generating an image is not mutation of existing state, and the cost disclosure is a valuable side-effect warning.

Agents need to know what a tool does to the 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 usage trigger, and every clause contributes use cases, output, or pricing. The long sentence with nested clauses is slightly dense but not padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 6-parameter tool with no output schema, this description covers the essential invocation context: when to use it, what it returns, provider/count choices, and cost. The remaining parameters, such as aspect_ratio and quote, are already fully described 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?

With 100% schema coverage, the schema already documents all parameters. The description restates provider, quality, and count options but adds little new parameter-level meaning beyond the SWOGE prompt guidance and output-format note.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 action and object ('Use this when you need an image'), then enumerates concrete use cases: illustration, meme, post visual, and the SWOGE character. This clearly distinguishes it from the generate_video sibling without requiring schema inspection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this when you need an image' gives an explicit trigger condition, supported by relevant examples. It does not explicitly name alternatives or say when not to use it, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description states this is a paid operation that bills when the video arrives, while annotations declare readOnlyHint=true. This is a direct contradiction—the tool creates a resource and incurs cost, not a read-only operation. The description itself is transparent about billing and async behavior, but the contradiction with annotations is severe.

Agents need to know what a tool does to the 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 purpose is front-loaded, followed by the async flow and billing caveat. 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 the essential usage: returns a video id, poll with video_status, and billing details. All parameters are in the schema. However, the annotation contradiction undermines trust and could mislead an agent about side effects, so completeness is slightly reduced from an ideal 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with all six parameters documented in the schema. The description only reiterates the duration (6 or 10 seconds) and does not add meaningful semantics beyond the schema. Baseline 3 applies because the schema carries the parameter detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: generating a short video clip (6 or 10 seconds) with Grok Imagine. It distinguishes itself from siblings by naming video_status for polling and implying generate_image for images, so an agent can easily differentiate.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It explicitly instructs to poll with video_status until done, providing a clear usage flow. It doesn't explicitly state when not to use it (e.g., for images) but the purpose is specific enough that alternatives are obvious.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so the description's 'Live reads, never advice' reinforces the safe read-only nature. The description adds useful behavioral context: it returns up to 30 fresh tokens, includes older watched tokens with verdicts, and mentions the GoPlus security check. It does not detail pagination or rate limits, but the added context is valuable 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 a single, information-dense paragraph that front-loads the core purpose and key details. It includes the GoPlus attribution and a disclaimer, which are useful but slightly tangential. Overall, it is concise and well-structured, with no wasted sentences.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 two optional parameters and no output schema, the description covers the essential context: what it returns, the data source, the security check, and the non-advice nature. It does not explain the exact format of the returned data, but the absence of an output schema and the tool's simplicity make this acceptable. The description is complete enough 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 100%, so the schema already documents both parameters (limit and quote). The description adds context about the default limit (15) and the quote behavior (price without running), but these are also in the schema. The description does not add significant new meaning beyond the schema, so baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: retrieving the newest tokens on Robinhood Chain shortly after pool opening, along with the SWOGE AI colony's verdicts. It distinguishes itself from siblings by specifying the unique data source (Robinhood Chain, fresh tokens, colony decisions) and explicitly notes it is a live read, not advice.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 ('when you want the newest tokens... minutes after their pool opens') and what it returns. It does not explicitly name alternative tools or exclusions, but the context is strong enough for an agent to select it appropriately among the listed siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true. The description adds valuable behavioral context: it is passive, returns specific data categories in a defined order, and refuses certain target types. It also clarifies that results are sourced. While it doesn't mention cost or rate limits, the presence of a quote parameter in the schema partially covers that. The description goes beyond annotations by detailing the passive nature and the refusal of PII.

Agents need to know what a tool does to the 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 filler. The primary use case and scope are front-loaded, and the exclusion of people data is clearly stated. Every clause earns its place, making it efficient and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given that there is no output schema, the description compensates by explaining the structure of the return (findings first, then DNS, cert, etc.) and the source attribution. It covers the passive limitation and refusal of PII. Cost is hinted at via the quote parameter in the schema. A minor gap is the lack of mention of error conditions or rate limits, but for a read-only reconnaissance tool, the description is complete enough 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 coverage is 100% and both parameters (target, quote) have descriptive text. The tool description does not add new meaning beyond the schema but reinforces the accepted target types (domain, IP, URL, AS number, CVE id). This matches the schema description. Since the schema already handles parameter semantics, 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 states a specific verb ('passive reconnaissance') and a clear resource class (domain, IP, URL, AS number, CVE id). It also lists the output categories (findings, DNS, certificate, registration, hosting, exposure facts) and explicitly excludes people-related data, making it unambiguous and distinct from the sibling tools, none of which target OSINT.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 opens with 'Use this when you need passive reconnaissance...' and later adds 'Passive only; people (e-mails, usernames, phone numbers, names) are refused.' This conveys when to use it and when not (people-related queries are out of scope). It doesn't explicitly name alternative tools, but the sibling list contains no obvious OSINT contender, and the scope constraints are clear enough.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context beyond that: the output is hash-chained audit lines with enumerated statuses, it reports whether the chain is intact, and it costs nothing ('Free'). It stops short of describing result volume for 'latest' or any rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single compact sentence that front-loads the action and then the returned data. Dense but every clause earns its place; slightly run-on, which costs a point.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 returns, and it does so well — statuses, price, transaction, chain integrity. Ample for a parameterless read tool, though the scope of 'latest' remains unspecified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero parameters, so the baseline is 4. Nothing in the schema needs compensating for, and the description correctly signals a no-argument 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?

States a specific verb and resource — 'check what this API key paid' — and enumerates the concrete artifacts returned (hash-chained audit lines with paid/free/refused status, price, transaction, and chain integrity). No sibling tool covers payment auditing, so it is unambiguous without needing to name alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening 'Use this to check what this API key paid' gives the use case, but it names no alternatives (e.g. pay_service) and no when-not-to-use condition. Usage is implied by the audit framing rather than explicitly guided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover only the coarse safety profile (openWorld, idempotent, non-read-only), while the description discloses the real behavioral traits: payments off by default, per-call cap up to $0.10, optional allowed sites, billing source (dollar credit vs $SWOGE), the 200-only billing rule, and the hash-chained audit entry per attempt. That is substantive context an agent cannot get from 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?

Front-loaded with the 'use this when' trigger and otherwise dense with operational constraints; every clause earns its place. It is on the long side as a single block, which slightly hurts scanability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 payment-mutation tool with no output schema and no schema for linked tools, the description covers the money flow, limits, idempotency, and audit trail well. It does not describe what the call returns (presumably the upstream service response), which is the one remaining 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 83%, so the fields are largely documented already. The description adds genuinely new semantics for idempotency_key ('the same key never pays twice') and ties max_usd to the owner cap, going beyond the schema's terse field notes.

Input schemas describe structure but not intent. Descriptions should explain 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: it pays a paid x402 service in USDC and bills the key owner. It clearly distinguishes itself from discovery siblings like search_x402_services and from payment_audit, which records the attempts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this when your task needs a paid x402 service (a data or AI API that answers 402)' gives a clear trigger condition, and it specifies the catalogue restriction and the owner-set limits that gate usage. It stops short of explicitly routing the agent to search_x402_services for services not yet known, leaving that inference to the agent.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint; the description adds substantial context beyond them: data sources (DexScreener pool, GoPlus contract checks, Go+ Security), the constraint that a red flag is repeated only when a check actually raised it, the return payload (roast, facts, 1200x630 PNG card with share-linked preview), and the 'never a buy or sell signal' disclaimer.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Usage guidance is front-loaded and each sentence carries new information (persona, sourcing, constraint, return shape, disclaimer). It is dense with parentheticals and could be trimmed, but nothing is pure 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?

There is no output schema, so the description correctly takes on the burden of describing returns (roast text, supporting facts, shareable PNG card). Combined with the data-source and red-flag-repetition disclosures, an agent has everything needed to call and interpret this tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters are documented there, so the baseline is 3. The description adds no syntax or format detail for address or quote beyond what the schema already gives.

Input schemas describe structure but not intent. Descriptions should explain 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 (roasts) and resource (an EVM token), names the persona (SWOGE the shiba inu), and explicitly anchors itself to the sibling token_verdict as the serious counterpart. An agent can distinguish it from token_verdict, scan_token, and robinhood_token without opening any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly frames the use case ('when you want a funny, shareable take ... for a post or a chat') and implicitly scopes it away from serious analysis by saying the facts match token_verdict. It never states a when-not explicitly, but the entertainment framing makes the boundary clear.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, and the description adds real substantive context beyond them: the closed allow-list of methods, the eth_getLogs caps (10,000 blocks, 500 logs), and the promise to return 'the node answer as is'. That is meaningful disclosure of scope and limits; only auth/cost behavior is left unstated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the use case and then the constraints, so an agent gets the key facts immediately. The verbose method enumeration largely duplicates the schema enum, which is the one place where text does not fully earn its space.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 covers the return behavior ('node answer as is'), scope, method allow-list and rate/size limits, which is sufficient for a passthrough RPC tool. Missing only the quote-mode interaction detail and any auth/error behavior, which are minor here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3, but the description genuinely adds meaning: it constrains which methods are permitted (matching the enum) and imposes behavioral limits on eth_getLogs that are not expressed anywhere in the schema. The 'quote' parameter's semantics are already carried by 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?

States a specific verb and resource ('one read-only JSON-RPC call' on 'Robinhood Chain (chain id 4663)') and scopes it tightly as a raw node passthrough. This clearly distinguishes it from siblings like robinhood_token, robinhood_tx, and robinhood_wallet, which are higher-level helpers.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this when you need a raw read ... without running a node' gives a clear use context and implicitly frames alternatives (running your own node, or the higher-level robinhood_* siblings). It stops short of explicitly naming which sibling to use instead for token/transaction data, so it is not a full when/when-not statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered; the description adds meaningful context beyond that — that the call is single-pass, that power flags are read 'in the implementation behind a proxy', and that part of the payload (price, liquidity, market cap) comes from an external DexScreener source. It stops short of describing failure modes for non-ERC-20 or non-contract addresses.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the use case and the 'one call, decoded' value proposition before the return-value enumeration, which is dense but every listed item is genuine payload. It is a single long sentence, readable but slightly list-heavy rather than 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?

There is no output schema, so the description correctly carries the full burden of describing return values, and it does so thoroughly across metadata, ownership, proxy implementation, code powers and market data. Minor gaps remain around edge cases (non-token contracts, renounced-owner representation) that an agent might want spelled out.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (address, quote) are already fully documented in the schema, including the quote flag's dry-run semantics. The description never touches parameter behavior, so the baseline of 3 applies with no added 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 states a specific verb+resource — 'know what a Robinhood Chain contract is... one call, decoded' — and enumerates the exact data returned (ERC-20 metadata, owner, EIP-1967 implementation, exposed powers, DexScreener market data). The chain-specific framing partially separates it from generic siblings like scan_token or token_verdict, but it never explicitly disambiguates from those.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this when you need to know what a Robinhood Chain contract is before touching it' is a recognizable use-case trigger and implies a pre-interaction audit context. However, it offers no when-not guidance and never routes the agent away from the obviously overlapping siblings (scan_token, token_verdict), leaving the choice to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare readOnlyHint=true and openWorldHint=true, so safety is covered, but with no output schema the description must disclose what comes back — and it does, itemizing status, gas/fee in both ETH and USD, decoded ERC-20 transfers and Uniswap v2/v3/v4 swaps. It adds no note on latency, chain coverage limits, or error behavior for unconfirmed hashes, keeping it short of a 5.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, no filler: the trigger clause is front-loaded and the return-field enumeration is packed into a single dense sentence. Every element 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?

With no output schema present, the description appropriately carries the return-value burden by listing fields. Minor gap: it does not explain the quote mode, and ambiguous hashes (wrong chain vs. unknown) are unaddressed.

Complex tools with many parameters or behaviors need more documentation. 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 both the hash format and the quote flag are already documented in the schema, establishing a baseline of 3. The description adds nothing about the quote parameter (a price-check-without-execution mode), which is a non-obvious flag worth calling out.

Input schemas describe structure but not intent. Descriptions should explain 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 (understand what a transaction did) and resource (Robinhood Chain transaction), and enumerates exactly what it returns: status, addresses, method, gas/fee, decoded ERC-20 transfers and Uniswap swaps. This is clearly distinguishable from token- or wallet-scoped siblings, though it never names them explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this when you need to understand what a Robinhood Chain transaction did' gives a clear trigger condition that maps to the transaction-inspection use case. It offers no when-not guidance and does not point to robinhood_rpc or robinhood_token as alternatives for related needs, so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful behavioral detail beyond that: reads happen on-chain in one Multicall3 call (single batched request), pricing comes from DexScreener, and unknown prices are explicitly null rather than zero - an error-semantics fact an agent cannot infer from structured fields.

Agents need to know what a tool does to the 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 tightly packed sentences that front-load the trigger condition and then enumerate the return shape. Nearly every clause carries information (units, symbol, decimals, price source, null handling, total); slightly dense but no wasted 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 carries the return-value burden and does so well: per-token balance in units with symbol and decimals, DexScreener price and USD value, null-when-unknown semantics, and a total. Only minor gaps remain, such as behavior when more than 20 tokens are supplied.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all three parameters including the quote dry-run flag and the 20-token default. The description reinforces the token limit and default holdings (ETH plus tokens) but adds no syntax or format guidance beyond the schema, so the 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 states a specific verb+resource and scope: fetch holdings (ETH plus up to 20 tokens) for a Robinhood Chain address. This clearly separates it from siblings like robinhood_token, robinhood_tx, and wallet_intel, though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use this when you need the holdings of a Robinhood Chain address" gives a clear triggering condition and the scope of what qualifies as a holdings query. It stops short of naming an alternative or stating when NOT to use it, so this is solid context without exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations readOnlyHint and openWorldHint already signal safety, and the description adds important behavioral context: 'Measurements, never a buy or sell signal; unknown stays unknown.' It also discloses coverage limits ('where GoPlus covers the chain') and the special Robinhood Chain behavior, going 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 first sentence front-loads the use case, and the final sentence is a crisp safety qualifier. The return-value description is dense and would benefit from a bulleted list, but every sentence carries substantive information with little 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?

With no output schema, the description properly takes on the burden of explaining what is returned: pool metrics, GoPlus checks, historical SWOGE observations, and a shareable scan card. It also covers limitations such as chain coverage and uncertainty, making the tool's behavior clear enough for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already describes both parameters fully: address format and the quote flag behavior. The description adds context about EVM scope and DexScreener chain coverage, but this is marginal beyond the schema. With 100% schema coverage, a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the operation ('scan'), the resource ('EVM token'), and the intended trigger ('before buying, listing or writing about') in the first sentence. It also distinguishes the tool by listing its distinct output categories: DexScreener market data, GoPlus security checks, and Robinhood Chain SWOGE observations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 states when to use the tool ('Use this before buying, listing or writing about an EVM token') and scopes it to chains DexScreener indexesable. However, it does not name an alternative tool or describe when not to use it, 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations cover read-only and open-world traits, and the description adds genuinely non-obvious behavior: the result set is built from measured probes and real paid calls, and no verdict is issued below 3 probes. That sampling-threshold caveat is important context an agent cannot get from the annotations, though pagination and completeness of the catalogue are unstated.

Agents need to know what a tool does to the 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 long sentence, but it is front-loaded with the trigger condition and then enumerates the returned fields compactly. The nested parenthetical about measured fields is dense yet every clause carries information; nothing is 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 usefully names the returned fields (probe count, answered share, median latency, last failure, real paid calls), which is the key missing piece. For a free, read-only, two-parameter search this is nearly complete; only the `limit` parameter's effect and result ordering are left to inference.

Complex tools with many parameters or behaviors need more documentation. 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%: `need` is documented in the schema as English keywords, but `limit` has no description beyond its 1-50 bounds. The description adds nothing about parameter semantics or query syntax, so it neither compensates for the gap nor repeats the schema — the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (searches the public x402 catalogue) and resource, and prefaces it with the exact trigger condition ('when you need a paid API an agent can pay per call'). It is clearly distinguishable from siblings like pay_service or can_i_sell because it describes a catalogue search rather than a payment or listing action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Use this when you need a paid API an agent can pay per call (x402)' gives an explicit use condition, and 'Free' implicitly contrasts with pay_service's cost. It stops short of naming the sibling to use for actually paying or for services outside the x402 catalogue, so the routing is clear but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered; the description adds the substantive behavioral context of what comes back (verdict, official address, ISIN, status, multiplier, pending corporate action, pool price/liquidity, premium vs Chainlink feed). The note that the Chainlink feed's value 'is not republished' is a genuinely useful disclosure about what the caller will and won't see. No rate limits or latency characteristics are mentioned.

Agents need to know what a tool does to the 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, both front-loaded: the first establishes when to use it and the verdict space, the second enumerates the return payload. Given that there is no output schema, the enumeration earns its length rather than padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 so fully: verdict options, official address, ISIN, status, multiplier, corporate action, pool depth and price, and premium relative to the Chainlink feed with its address and last-update caveat. An agent has everything needed to decide to call it and to 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?

Schema description coverage is 100%, so the schema already explains symbol, address and quote, including the ticker-vs-contract distinction and the quote dry-run flag. The description adds no parameter-level detail beyond referring to a contract and tickers in prose. Baseline 3 applies when the schema carries the 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 states a specific verb and resource: it determines whether a contract is the official Robinhood Stock Token or an impostor reusing the ticker, scoped to Robinhood Chain. It even enumerates the three possible verdicts, which pins the purpose down. It stops short of naming the sibling tools (scan_token, token_verdict, robinhood_token) it should be chosen over, so no explicit sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use this before touching a stock token" gives a clear trigger condition and places the tool in a pre-interaction verification workflow. There is no statement of when not to use it or which alternative tool handles adjacent cases, so the guidance is directional but not exhaustive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds real behavioral context: it only returns tokens with both a feed and a pool above a minimum liquidity, the sort key, and the interpretive caveat that a premium is a measurement and never a trade signal.

Agents need to know what a tool does to the 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: usage trigger first, return/shape second, interpretive caveat last. Front-loaded and free of 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?

There is no output schema, so the description carries the return burden and does describe the returned fields (pool price, liquidity, quote currency, feed freshness). It is complete for the call itself, though it omits any hint of ranking tie-breaks or pagination beyond the limit parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents limit, quote, and min_liquidity_usd; baseline is 3. The description restates the minimum-liquidity filter but adds no syntax or format detail 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 and ranking (Robinhood Chain stock tokens sorted by absolute premium vs their Chainlink feed), so the agent knows exactly what list it produces. It does not explicitly differentiate from the sibling stock_token_check, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use this when you want the ... stock tokens whose on-chain pools trade furthest from their Chainlink feed" gives a clear triggering condition. It offers no explicit when-not or named alternative (e.g. stock_token_check), 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.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint and openWorldHint, so the description does not need to cover safety. It adds useful behavioral context by stating data is read on-chain on Robinhood Chain and that the price comes from DexScreener, while also listing the returned metrics.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one efficient, front-loaded sentence that states the usage condition first, then packs in all return values and data sources with no filler. It does not waste words or restate the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 no output schema, the description provides a complete return contract: it lists each metric, notes shares of supply, and names both data sources. An agent has enough information to know what to expect without additional lookup.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the optional quote parameter is fully documented by the schema itself. The tool description adds no additional meaning about that parameter, which is acceptable at the baseline but not a differentiator.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: retrieving the current state of the $SWOGE token economy, and enumerates the exact data points returned (supply, burned amount, vault balance, staking APR/cap, price). It is specific about the resource and sources, though it does not explicitly differentiate itself from sibling tools like scan_token.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description opens with 'Use this when you need...' and gives a precise trigger condition. It does not mention when not to use it or name an alternative tool, but the condition is specific enough to guide an agent effectively.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only cover readOnlyHint and openWorldHint, so the description carries the semantic burden and does so well: it discloses the data sources (GoPlus, DeepScreener pool, SWOGE colony traits), that each flag carries its source, and explicitly warns that no_red_flag_found is not a buy signal and unknown stays unknown. It omits cost/latency behavior for the non-quote path.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the decision use-case and verdict values in the first clause, then adds sourcing and caveats. It is dense but every sentence is informative; minor redundancy in restating the data-source list.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description usefully describes the return shape (verdict plus reasons, per-flag source, per-colony observation counts). It is complete enough for correct invocation, though it does not describe failure modes for invalid or non-EVM addresses.

Complex tools with many parameters or behaviors need more documentation. 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 documented descriptions for both address and quote, so the schema already explains the parameters. The description only hints at the quote path ('without running or paying for it' appears in the schema, not the description), adding little beyond schema baseline.

Input schemas describe structure but not intent. Descriptions should explain 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 ('one verdict you can branch on') and enumerates the exact outcome values (red_flags, caution, unknown, no_red_flag_found). It also distinguishes itself from the sibling scan_token by framing itself as the verdict over the same underlying 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?

Gives a clear trigger ('Use this when you must decide fast whether an EVM token is worth a closer look') and names scan_token as the tool judging the same data, implying the alternative. It does not explicitly state when to prefer scan_token over this one, so it stops short of full when/when-not routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already set readOnlyHint=true and openWorldHint=true, so the description doesn't need to restate that this is a read-only operation. It adds useful behavioral details beyond annotations: it returns the current status (pending, done with URL, failed), notes that failure is not charged, and provides billing information. This gives the agent a clear picture of what to expect without over-explaining.

Agents need to know what a tool does to the 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, front-loaded with the usage condition ('Use this when you started a video with generate_video'), and every piece of information earns its place: the trigger, the return types, the billing info, and the cost. 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?

This is a simple status-check tool. The description covers the key return states and mentions billing behavior. It doesn't explicitly mention the quote parameter, but the schema fully describes it, so the description doesn't need to. Given the absence of an output schema, the description provides sufficient context for an agent to call the tool correctly. Not a 5 because it could have mentioned that a 'done' status includes the video URL, but that is implicitly stated.

Complex tools with many parameters or behaviors need more documentation. 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 both parameters (id, quote) have clear descriptions in the schema. The tool description does not add any new meaning about parameters; it simply refers to 'what was billed' which aligns with the quote parameter but doesn't elaborate. Per the baseline rule for high schema coverage, a score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: check whether a video started with generate_video is ready. It identifies the specific resource (video status) and the trigger condition (after starting a video with generate_video), which distinguishes it from sibling tools. It also mentions the types of returns (pending, done with URL, failed) so an agent knows what to expect.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 this when you started a video with generate_video,' which is direct usage context. It implicitly tells the agent when not to use it (if you didn't start a video with generate_video) and ties it to the sibling generate_video. The mention of 'Free' also conveys usage cost assumptions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description adds valuable behavioral context beyond the readOnlyHint annotation: it explicitly states the tool is passive ('the address is never contacted') and describes the return structure (findings first, then facts with sources). It also clarifies that the quote parameter returns a price without executing the call, which aligns with the annotation and adds 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 appropriately sized—three sentences—and front-loaded with the core purpose. It packs useful details (return order, passive nature) without fluff. The flow is logical: usage, output, behavior. A slight deduction for being slightly longer than strictly necessary, but each clause contributes.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one required param, optional quote, no output schema), the description covers the key aspects: what it returns (findings, facts, sources), how it behaves (passive), and when to use it. It does not mention pagination or rate limits, but these are not critical for a read-only lookup. The description is sufficient for an agent to 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 100%, so the schema already documents both address and quote. The description does not add any new meaning beyond the schema; it references 'address' contextually but does not elaborate on the quote parameter beyond what the schema states. This meets the baseline but adds no extra 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 opens with a clear, specific use case: identifying who is behind an EVM address, typically a token deployer, before trusting its launches. It names the resource (address) and the action (intel lookup) and distinguishes it from siblings like scan_token and osint_lookup by focusing on deployer history and colony measurements.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 concrete when-to-use scenario ('before trusting what it launches') and implicitly differentiates from scanning tools by focusing on the address's history. It does not explicitly name alternatives or when-not-to-use, but the context is clear enough for an agent to decide. A slight deduction for not listing exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With readOnlyHint=true and openWorldHint=true, annotations already cover safety and scope. The description adds useful behavioral detail: results are ranked, include title/URL/date/extract, and come from Perplexity Search. It does not mention the quote=true branch, where a price is returned instead of results, but that is covered by the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences front-load the use case and then give the essential return information. 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?

For a simple read-only search tool, the description covers trigger, scope, and return shape even without an output schema. The quote behavior is only in the schema, but it is not hidden, and no pagination or rate-limit details are essential here.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already explains both query and quote. The description adds minor query context with example topics but does not elaborate on how to use the quote flag or how query syntax should be formed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 trigger: use when the answer is outside SWOGE data, and it specifies the output as ranked results with title, URL, date and extract. It separates web search from internal-data tools, though it does not explicitly differentiate from sibling tools like osint_lookup or ask_agent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

"Use this when the answer is outside SWOGE data" is an explicit when-to-use condition and the examples (news, projects, teams, people) clarify scope. It does not name an alternative tool or an explicit when-not-to-use rule, so it stops short of full routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.