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

Annotations provide readOnlyHint and openWorldHint, but the description goes beyond by stating that every entry cites its documentation or program source and notes when observed behavior differs from documentation. This is a valuable behavioral disclosure about reliability and transparency, and it also hints at the depth and verification behind answers. No contradiction with annotations.

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

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

The description is a single dense paragraph but efficiently packs a broad scope into a few sentences. It front-loads the core purpose and then lists concrete coverage areas. It is not overly verbose given the complexity of the tool, and every sentence contributes information. Slightly more structured formatting could improve readability, but it remains concise.

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

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

For an explanation tool with no output schema, the description provides ample context: what it covers, what types of questions it answers, and its source-citation behavior. It does not explicitly state the output format (e.g., a text answer), but that is implied. Given the breadth of topics, the description is sufficiently complete for an agent to decide when 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?

There is only one parameter, 'topic', and the schema already provides a rich description with examples ('escrow', 'royalties on Tensor', 'permanent transfer delegate'). The tool description repeats those examples but adds no new information about the parameter. With 100% schema coverage, the description adds no extra semantic value beyond the schema, so 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 uses a specific verb ('explain') and a clear resource ('how a standard or a marketplace handles an asset'), then enumerates concrete scenarios (escrow, freeze, royalties, wash trades, standards migration). It distinguishes itself from sibling data-retrieval tools by focusing on conceptual explanation rather than raw facts, and even names the specific protocols and marketplaces covered.

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

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

The description makes the tool's use case obvious through the list of example questions ('what does frozen mean', 'can they burn my card', 'is Magic Eden custodial') and the explicit coverage of platforms and standards. It does not explicitly name sibling tools or state when not to use them, but the contrast with the data-lookup siblings is implicit and strong.

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 mark it readOnlyHint=true and openWorldHint=true, and nothing in the text contradicts those. The description adds concrete runtime behavior: batching costs ('each one costs a request or two'), pagination ('hands back a cursor for the rest'), and per-match fields ('its ask, that collection's floor and how far above floor'). This goes beyond the annotation hints.

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

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

The description front-loads the action ('Search MANY collections at once') and stays information-dense; every sentence adds either a use case, an output detail, or a grouping instruction. The examples and parameter context are compact rather than 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 eight parameters and no output schema, the description covers the key missing pieces: output shape ('Each match names its collection, its ask, that collection's floor'), pagination/cursor behavior, cost implications of batch, and source of groups. This is sufficient for an agent to construct a valid first call.

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

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

Schema description coverage is 100%, so the schema carries the parameter-level burden and the baseline is 3. The description adds cross-parameter meaning by mapping serials to edition numbers, linking startAt to the returned cursor, and explaining that collections can be named directly or sourced from search_collections. It does not repeat the schema's per-parameter details.

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

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

The description opens with the core verb and scope: 'Search MANY collections at once for a specific edition number.' It then gives concrete example questions and states what each match returns, making the resource and output unambiguous. This clearly differentiates it from single-collection tools without restating the tool name.

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

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

The description gives a clear trigger: questions like 'any #1 for sale across DC' that cannot be asked of one collection. It also directs agents to 'Use groups from search_collections, or name the collections yourself.' It does not explicitly say to use find_listings for single-collection lookups, so alternative exclusion is implicit rather than stated.

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?

Beyond the annotations (readOnlyHint, openWorldHint), the description discloses significant behavioral traits: 'cheapest first' ordering, 'lowest-serials mode that reads the whole book' (heavy operation), trait filter AND semantics ('Several trait filters mean all of them'), the conditional nature of rarity ranks, and the distinction between ask prices and sale prices. No contradiction with annotations exists.

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

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

The description is dense and front-loaded with the core purpose, followed by usage examples and important caveats. Every sentence earns its place, though it is a single stream-of-consciousness paragraph; a bulleted structure would improve scannability. Still, it is concise relative to the complexity of six parameters and multiple modes.

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

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

For a tool with six parameters and no output schema, the description covers the essential behavioral context: what it returns (listings cheapest first), filtering modes, the heavy read behavior of lowestSerials, rarity rank caveats, and pricing semantics. It does not describe pagination or output field details, but the schema documents parameters and the annotations cover safety. This is nearly complete for correct invocation.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining the semantics of 'lowestSerials' ('reads the whole book and sorts by edition number'), clarifying that multiple trait filters are ANDed, and providing concrete examples for 'nameContains' ('#1390' or 'Judge'). This extra context lifts it above 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?

The description opens with a precise statement of what the tool does: 'What is for sale in a collection right now, cheapest first' – a specific verb and resource with a clear scope. It then names concrete capabilities (trait filters, name filter, lowest-serials mode) and differentiates itself from a sibling by noting that prices are asks on Magic Eden and that get_collection_sales shows buyer-paid prices.

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

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

The description provides explicit when-to-use guidance through example user intents ('cheapest Rex', 'find #1390', 'is there a deal on a Judge card') that map directly to this tool's features. It also names an alternative (get_collection_sales) for a specific need (buyer-paid prices), giving clear when-not guidance. This is more than enough for an agent to route correctly.

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

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

Beyond the readOnlyHint and openWorldHint annotations, the description discloses that owner data comes from different sources depending on asset standard, that each reader's freshness is reported, and that the two owners are only treated as agreeing when both reads were live. This meaningfully warns agents about potential owner disagreement on stale reads.

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

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

The description is compact and front-loaded with the core lookup behavior. Both sentences add information about output contents or freshness behavior, with no filler or redundant restatement of the schema.

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

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

For a one-parameter read-only tool with no output schema, the description names the concrete fields and data sources returned, including freshness reporting and the owner-agreement caveat. This is sufficient for an agent to invoke the tool and interpret the result 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%: the only parameter, mint, is already described as 'Asset mint address.' The description simply restates 'by mint address' and adds no further format, validation, or encoding detail, so the baseline score applies.

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

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

The description clearly identifies a get-by-key lookup for a single asset: 'Everything known about one asset by mint address.' It enumerates the content groups returned, including marketplace metadata and the on-chain owner, which distinguishes it from wallet-level and collection-level sibling tools.

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

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

The phrase 'one asset by mint address' provides clear invocation context: use this when the caller already has a mint address and needs a full asset picture. It does not explicitly name alternatives or when-not-to-use conditions among the many siblings, but the single-asset scope is clear enough to avoid obvious confusion.

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, so the description carries the behavioral burden and does so thoroughly. It discloses the bounded walk, the at-most-depth limit, the dropping of the middle of the history, the unread_gap rows placed in order, the need not to read across gaps, and the meaning of skippedTransactions. This is exactly the behavioral context an agent needs beyond the annotation hints.

Agents need to know what a tool does to the 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 long but densely informative and front-loaded with the core promise before moving into operational warnings. Every sentence earns its place, and the repeated warnings—read historyComplete, don't read across gaps, don't lower depth for provenance—are correctness-critical rather than fluff. The structure leads from what it does to how to interpret results safely.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 must explain what comes back, and it does: mint, transfers with marketplace labels, current owner, historyComplete, skippedTransactions, events, and unread_gap rows. It also explains the empty-traits case and directs the agent to the right tools for traits. An agent can interpret the response safely and decide when depth is insufficient.

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

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

Schema coverage is 100%, so the baseline is 3. The description reinforces depth semantics with 'Raise depth to cover more' and warns that newer transactions are kept while the middle is dropped, but most depth details like RPC pacing, historyComplete, unread_gap, and lowering-only-for-speed already appear in the schema description. For mint, neither the schema nor the description goes beyond identifying a Core asset mint address, so the description adds only modest parameter-level 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 opening sentence names the exact operation and resource: 'BOUNDED on-chain ownership history of a Metaplex Core asset: mint -> transfers (with marketplace labels) -> current owner.' It further distinguishes the tool by noting it decodes from TransferV1 instruction accounts and that other APIs return empty for Core assets. Ownership-only scoping is explicit when it routes trait questions to get_asset and get_asset_trust.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 it is ideal for Candy Digital cards and any Core collectible, and it states what it is not for: 'Ownership events only: traits live in get_asset... and get_asset_trust.' It also gives concrete usage rules, such as always reading historyComplete before describing a trail as complete and never lowering depth to answer who-owned-it. This is strong when-to-use and when-not-to-use guidance with named 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?

Beyond the readOnlyHint and openWorldHint annotations, the description adds valuable behavioral detail: data is 'decoded from raw bytes, no indexer,' collection-level plugins are read and 'marked inherited,' and the read is purely read-only. This gives an agent accurate expectations about data sourcing and coverage without contradicting the annotations.

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

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

The description is dense but every sentence earns its place: purpose, concrete facts, collection inheritance nuance, marketplace contrast, use cases, and data-source caveat. The most important purpose statement is front-loaded, and there is no filler or repetition.

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

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

For a single-parameter read tool with no output schema, the description covers what the tool does, what questions it answers, how it handles collection-level plugins, when to use it, and the raw-bytes/no-indexer caveat. An agent has enough context to invoke it correctly and interpret its high-level purpose.

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

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

The schema already documents the only parameter, mint, as 'Metaplex Core asset address,' giving 100% schema description coverage. The tool description reinforces that the asset is a Metaplex Core asset but does not add meaningful syntactic or semantic details beyond the schema, so the baseline score of 3 is appropriate.

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

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

The description opens with a specific verb and resource: 'Decode the Metaplex Core plugins on an asset and translate them into custody facts.' It then enumerates concrete questions the tool answers (delegates, frozen state, royalties, metadata mutability, serial authenticity), and distinguishes itself from marketplaces that show only picture and price. This clearly differentiates it from siblings like get_asset and explain_mechanics.

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

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

The description gives explicit when-to-use triggers: 'Use before a purchase, when a listing "cannot transfer", or when someone asks whether a pack burns on open.' It also hints at a contrast with marketplaces, but does not name alternative sibling tools or provide explicit when-not-to-use exclusions, so it falls just 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?

The description goes well beyond the readOnlyHint and openWorldHint annotations. It discloses that listed items show the marketplace's escrow as owner rather than the seller, that holder rows carry a ROLE field with specific meanings (issuer, venue-escrow, wallet, unknown), and that the issuer role is read from the chain and says nothing about how an item got there. It also explains the 'unknown' role condition. This is rich behavioral context that an agent needs to interpret results correctly.

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

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

The description is dense but well-organized, front-loading the core purpose and key differentiator. Every sentence adds information, and the examples are useful. It is longer than average, but the length is justified by the behavioral nuances (roles, escrow ownership) that are essential for correct interpretation. Slight redundancy in the role explanation could be tightened, but overall it earns its length.

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

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

For a read-only census tool with 100% schema coverage and no output schema, the description is remarkably complete. It covers what the tool returns (rows plus holder count per address, largest first), how filtering works, how to interpret roles, and the escrow caveat. It even points to a sibling tool for follow-up provenance questions. There is no critical missing information an agent would need to invoke or interpret this tool correctly.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters. The description adds meaningful context beyond the schema: it explains the purpose of trait/value filtering with a concrete example ('Item Type = Pack') and namePrefix with an example ('Gold Series - Aces'). It also clarifies that collection is an ADDRESS and how to obtain one. This adds value beyond the schema, though the schema already carries most of the parameter documentation.

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

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

The description opens with a precise verb and resource: 'CENSUS of a Core collection: every asset grouped under it, with its current owner, straight from the chain's asset index.' It clearly distinguishes itself from sibling tools by stating it is the only tool that sees unlisted items, and it provides concrete example questions. This makes the tool's purpose unmistakable and differentiates it from collection-wide tools that read marketplace listing books.

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

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

The description explicitly states when to use this tool versus alternatives: it is the only tool that sees items nobody has listed, while other collection-wide tools read a marketplace's listing book. It also names a specific alternative, get_asset_provenance, for seeing who handed an item over when it is listed. This gives clear when-to-use and when-not-to-use guidance.

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

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

Even with readOnlyHint and openWorldHint annotations, the description adds substantial behavior: it reads the Magic Eden API feed only, never fills gaps with estimates, reports how far back the feed was read, indicates if older sales exist beyond the page budget, and clarifies that execution marketplace is recorded per row. This goes far beyond the annotations, disclosing pagination, completeness, and sourcing quirks.

Agents need to know what a tool does to the 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 long but information-dense: every clause adds functional or behavioral detail. It front-loads the core purpose and then provides examples and caveats. While it could be tightened, the length is justified by the tool's complexity and the absence of an output schema. It is structured logically and not redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 complex tool with no output schema, the description thoroughly covers return values (aggregates, per-day series, per-name breakdown, order book vs AMM split), limitations (feed only, no estimates, pagination), and inputs. An agent can understand exactly what the tool returns and how to interpret results, making it fully self-sufficient despite missing an output schema.

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

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

The schema already documents all parameters (100% coverage), so baseline is 3. The description adds value by giving concrete examples for nameContains ('Ohtani' or 'Batman') and explaining maxPages in context ('busy collections need more to cover long windows'), plus clarifying that names come from the chain's asset index. This helps an agent use the parameters effectively 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 starts with a specific verb-resource-scope ('Sales for a collection over the last N days') and enumerates what the tool returns (aggregates, series, breakdowns). It also lists concrete questions it answers, and its scope (collection-level, Magic Eden feed only) distinguishes it from siblings like get_recent_sales or get_collection_stats 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?

The description clearly states the use case: sales for a specific collection over a time window, with filtering/grouping. It gives example queries and notes the data source and limitations. It does not explicitly state when NOT to use it or name alternative tools, but the context is strong enough that an agent can infer applicability.

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 meaningful behavioral context beyond that: addresses are decoded straight from the chain, the OpenSea slug is checked against the collection before floors are ranked, and the OpenSea view is conditional on OPENSEA_API_KEY. This goes beyond what annotations alone convey.

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

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

The description is dense but well-structured: it front-loads the core purpose, then explains the chain-decoding behavior, then the optional OpenSea view, and ends with example questions. It earns its length by covering multiple important behaviors, though it could be slightly tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 stats tool with 2 parameters and no output schema, the description covers the key inputs, the conditional OpenSea behavior, and the kind of questions it answers. It doesn't describe the exact return shape, but with no output schema and a read-only annotation, the description is reasonably complete for an agent to select and invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds context about what the collection parameter can be (registry id, ME symbol, or Core address) and explains the openseaSlug behavior, but it doesn't add syntax or format details beyond the schema. Baseline 3 is appropriate.

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

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

The description opens with a clear verb+resource ('Market + supply stats for a collection') and then enumerates the three accepted identifier forms, which distinguishes it from sibling tools like get_floor_prices or get_collection_holders. It also explicitly names the OpenSea cross-marketplace extension, so an agent can tell exactly what this tool returns.

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

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

The description gives explicit when-to-use guidance: it works for collections that marketplace indexes may not cover (e.g., Candy Digital drops) and explains when the OpenSea view is added (if OPENSEA_API_KEY is set or openseaSlug is passed). It also answers concrete user questions ('is the floor up or down this week', 'who holds the most'), which helps an agent match the tool to a user intent.

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 provide readOnlyHint=true, so safety is covered. The description adds concrete behavioral constraints: Magic Eden symbols and rows only, no other marketplace or currency, and independence from an OpenSea key. It does not mention failure modes or data freshness, but those are minor for a simple read-only lookup.

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

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

The description is front-loaded with the core behavior and scope, then states exclusions, then routes to relevant sibling tools. It is dense but every sentence serves a purpose; the repeated 'Magic Eden only' emphasis is intentional and not 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?

For a one-parameter, read-only tool with fully documented schema, the description supplies all needed context: source marketplace, currency, input type, size limit, exclusions, and fallback tools. No output schema exists, but the description's 'returns Magic Eden rows' plus the stated floor-price-in-SOL behavior is enough for correct invocation.

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

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

Schema coverage is 100% and the single symbols parameter already has type, pattern, min/max length, min/max items, and a description. The description restates that it takes Magic Eden symbols and supports up to 10 collections, adding slight provenance context but not materially going beyond the schema.

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

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

The first sentence states a specific verb ('returns current floor price') with the resource (up to 10 collections) and a precise scope (Magic Eden only, in SOL). It also distinguishes itself from siblings like get_collection_stats and search_collections, so an agent can identify it without ambiguity.

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

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

The description explicitly says when to use this tool: for Magic Eden-only floor prices in SOL. It names get_collection_stats as the alternative for cross-marketplace comparison and explains why that tool is different, and also instructs agents to use search_collections first when only a human-readable collection name is known.

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, leaving the description to carry the behavioral burden. The description goes far beyond that, detailing the output components (endpoints, rate limits, skeleton, cost, checklist, pitfalls), including concrete failure examples from production incidents, and warning about silent failures. It fully discloses what the tool returns and why it matters, with no contradictions to annotations.

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

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

The description is front-loaded with the critical when-to-use clause, followed by a clear list of return contents and supporting evidence. Every sentence earns its place: it states usage, lists deliverables, provides a concrete failure anecdote, and gives timing guidance. It is appropriately sized for the tool's complexity and no words are wasted.

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

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

With no output schema, the description must explain return values — and it does thoroughly, listing all components of the recipe. It also covers the 'why' behind the tool (silent failure modes, cost traps) and the timing of use. For a tool with a single enum parameter, nothing essential is missing. The description is self-sufficient.

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

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

The schema covers the single parameter 'goal' with an enum and a brief description. The description adds value by listing concrete examples of goals ('a sales bot, a floor dashboard...') that map directly to the enum values, giving the agent a richer sense of what each goal might entail. This goes beyond the schema's minimal 'What the user is building', so it earns above 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?

The description states a specific action ('Returns the verified endpoints and their real rate limits, a runnable skeleton...') and clearly distinguishes the tool from siblings by saying 'rather than just look a number up'. It names the resource (a build recipe) and the scope (collectible data integrations). This is unambiguous and differentiates it from the lookup tools in the sibling list.

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

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

The description explicitly conditions usage: 'Use when the user wants to BUILD something... rather than just look a number up.' It provides a clear when-to-use rule, gives concrete example goals, and adds timing advice ('Read this BEFORE writing integration code, not after it breaks'). While it doesn't name specific sibling tools, the contrast with simple lookups is sufficient to route an 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?

Annotations already declare readOnlyHint and openWorldHint, so the description adds value by specifying the returned fields (price, buyer, seller, tx signature) and the conditional OpenSea inclusion behavior. No contradiction with annotations; it provides operational context 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 two sentences, front-loaded with the core purpose and then detailing the conditional OpenSea behavior. No wasted words; each clause adds relevant information.

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

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

Given the tool's read-only nature and presence of annotations, the description covers the essential details: return fields, collection identifier formats, and the optional OpenSea integration. It does not mention error cases or pagination behavior, but the limit parameter in the schema covers count. The lack of an output schema makes the field list valuable; overall it is sufficiently complete 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?

Schema coverage is only 33% (only limit has a description). The description compensates by explaining that collection accepts a registry id or Magic Eden symbol and that openseaSlug is used for OpenSea inclusion. It does not repeat limit's schema description but adds meaning for the other two parameters.

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

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

The description clearly states the tool returns the most recent completed sales for a collection, listing the included fields (price in SOL, buyer, seller, tx signature) and the accepted collection identifiers (registry id or Magic Eden symbol). This is specific and actionable, though it does not explicitly differentiate from sibling get_collection_sales, which may serve a similar function.

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

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

The description gives conditional guidance for including OpenSea sales (requires OPENSEA_API_KEY and openseaSlug) but does not state when to prefer this over other collection-related tools like get_collection_sales or find_listings. It implies usage for recent sales but lacks explicit exclusions or 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 and openWorldHint, and the description adds useful behavioral detail: it reports what sources cannot see, which require keys, and fallback order. This goes beyond the structured annotations without contradicting them.

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

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

The description is dense and front-loaded, with the core purpose in the first sentence, illustrative queries in the second, and a precise usage trigger in the third. Every sentence earns its place without redundancy.

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

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

Given zero parameters, no output schema, and read-only annotations, the description fully covers what the tool reports, how it can be phrased, and when to invoke it. Nothing essential is missing for correct selection and invocation.

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

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

The tool has no parameters, so the baseline is 4. The description appropriately focuses on what the report contains rather than parameter details, which are unnecessary here.

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

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

The description states the tool reports 'live health of every data source this server reads' and enumerates specific outputs such as tier, what each answers, what it cannot see, key requirements, and fallback order. This clearly distinguishes it from asset-oriented siblings like get_asset or get_floor_prices.

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

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

The description gives explicit usage context with 'Use it when a result came back partial' and provides concrete natural-language queries it can answer. It does not list excluded cases or alternatives, but the context is sufficiently clear for an agent to know when this tool applies.

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 mark it read-only, and the description adds useful behavioral context: the metric is Magic Eden's own fills all-time, volume from other marketplaces is excluded, and high volume may include market makers or wash traders. This goes beyond the annotation baseline, though it doesn't describe output format.

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

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

The description is three sentences with no fluff. It front-loads the core definition, then adds use cases, then a caveat with a sibling pointer. Every sentence earns its place.

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

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

For a simple two-parameter read-only tool with no output schema, the description provides enough context: what is returned (wallets), how it is ranked (volume), limitations, and a follow-up strategy. Nothing critical is missing for correct invocation.

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

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

Schema description coverage is 100%, so both parameters (symbol and limit) are already fully documented. The description adds no new parameter-specific detail, so the baseline score of 3 is appropriate.

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

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

The description clearly states the tool returns the wallets with the most volume in a collection, using a specific verb and resource. It also distinguishes itself from siblings by noting it reflects Magic Eden's own fills and contrasts with get_wallet_activity.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 tells when to use this tool (to identify top traders/whales) and when not to trust it alone, pointing to get_wallet_activity as the alternative for verifying a wallet's activity. This is direct, actionable 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?

Despite readOnlyHint and openWorldHint annotations, the description adds value by disclosing the empty-list behavior ('result says so rather than implying the market is quiet') and clarifying the ranking source (marketplace's own volume). These are behavioral details not captured in annotations, enhancing transparency.

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

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

The description is compact (two sentences), front-loaded with the core purpose, and adds behavioral context without redundancy. Every word contributes to clarity.

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

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

For a simple tool with one optional parameter and no output schema, the description covers purpose, usage, and behavioral quirks. Nothing necessary for correct invocation is missing.

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

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

The schema already provides 100% coverage with a description for timeRange including enum values and default. The description only says 'for a time range' without adding meaning about how each value affects results. It meets the baseline for high schema coverage but adds no extra semantic value.

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

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

The description clearly states the tool returns trending collections from Magic Eden for a given time range, and provides example queries ('what is hot', 'top collections today') that make the purpose unmistakable. It distinguishes from search_collections by focusing on rankings, and the verb 'get' plus resource specification is explicit.

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

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

The description gives concrete usage context through example questions it answers, which implies when to use it. However, it does not explicitly mention alternatives or when not to use it, such as 'use search_collections for name-based lookup'. This is a minor gap given the sibling tools.

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?

Beyond the readOnlyHint/openWorldHint annotations, the description discloses conditional key-dependent behavior (OpenSea only 'with a key', transfers only with OPENSEA_API_KEY set), states computed outputs (P&L before fees, behavior label with reason), and explicitly acknowledges data blind spots: 'Every figure says which feed it came from and what that feed cannot see.' This openly discloses limitations rather than hiding them, going well beyond what annotations already provide. No contradiction with annotations.

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

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

Three sentences with the core scope front-loaded before the detail enumeration. The first sentence is a long run-on listing eight output categories, which is dense but each item earns its place for a tool this complex. Sentences two and three are tight single-purpose statements covering the key condition and provenance/auth. Slightly heavy, but appropriately sized for the breadth of what the tool returns.

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

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

With no output schema, the description's enumeration carries the return-value spec, and it is impressively detailed: totals, flows, marketplace identification, flips with hold time and P&L, behavior labels with reasons, and per-figure feed provenance. The main gaps are the absence of edge-case behavior (empty wallet, no trades in window) and no sibling-routing guidance, but for a tool this broad the description is nearly self-sufficient.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds behavioral meaning beyond the schema: it explains includeOpenSea's purpose (answering 'was this airdropped, gifted or bought?' via plain transfers), ties it to the OPENSEA_API_KEY requirement, and connects the pages parameter to the 'window' containing the first purchase. These enrich the cold schema descriptions with rationale and dependencies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 'How a wallet trades' and enumerates the tool's specific outputs: SOL totals, net flow, listings and bids, marketplace identification (Magic Eden order book vs AMM pools), most-traded collections, flips with hold time and P&L, and a behavior label with reason. This unmistakably differentiates it from siblings like get_wallet_holdings (what a wallet owns) and get_wallet_profile (static profile), so an agent can separate it without opening the schema. The noun-phrase opening is the only minor weakness, but the scope is precise and comprehensive.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 invocation context: 'Read-only; needs no key' and a conditional behavior when OPENSEA_API_KEY is set (transfers included so airdrop/gift/purchase questions get evidence-based answers). However, it never names an alternative tool or states when NOT to use this one, leaving the agent to infer that get_wallet_holdings or get_wallet_profile cover adjacent questions. Guidance is implied but never explicit.

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?

Beyond the readOnlyHint annotation, the description adds meaningful behavioral detail: it uses two independent readers, compares counts, and explicitly states it never asks for keys and cannot move anything. This enriches the agent's understanding of safety and scope, though it could mention pagination or rate limits.

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

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

The description is concise but packs substantial information: purpose, dual-source behavior, question coverage, and a read-only guarantee. It is front-loaded with the main function and uses efficient phrasing, though it could be slightly tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 a simple two-parameter schema, the description covers the core semantics, return scope, and safety profile. The absence of an output schema is compensated by explaining what the result represents (holdings from two readers with a comparison), so the agent can anticipate the response shape reasonably well.

Complex tools with many parameters or behaviors need more documentation. 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 documented with clear descriptions and constraints. The description adds no additional parameter-level nuance beyond what the schema provides, so 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 ('get') with a clear resource ('wallet holdings') and explicitly answers common questions. It distinguishes itself from siblings by emphasizing the dual-reader approach and coverage of unlisted/compressed assets, which is not obvious from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 clearly indicates the intended use case ('what does this wallet hold') and sets expectations about read-only behavior. However, it does not explicitly mention alternatives or state when not to use it (e.g., when to prefer get_wallet_profile or get_wallet_activity), leaving some 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?

The description goes well beyond the annotations. It explicitly states 'Read-only; needs no key', aligning with readOnlyHint and openWorldHint. It discloses the 'CEILING (never called a value)' nuance, preventing misinterpretation of financial worth. It also transparently mentions pacing for external API requests ('one paced Magic Eden request each', 'up to 3 RPC calls'), informing the agent of potential latency or rate limits. This is rich behavioral disclosure beyond what annotations provide.

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

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

The description is a single, information-dense paragraph. It front-loads the core purpose ('What a wallet holds and what that means') and then enumerates specific outputs and answerable questions. While somewhat lengthy, every sentence contributes distinct information; there is no redundancy or filler. It is efficiently structured for an agent to scan and understand the scope.

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

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

Given there is no output schema, the description compensates by enumerating nearly all the data points returned: grouped items, counts, shares, dominant collection, listed/compressed counts, royalties, supply share, floor ceiling, wallet age, and transaction count. It also covers usage context (read-only, no key, pacing) and the intended questions. For a tool with 4 parameters and this complexity, the description fully equips an agent to understand what to expect and how to interpret results.

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

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

Schema description coverage is 100%, and each parameter (wallet, maxItems, priceTop, includeAge) has clear descriptions including defaults and constraints. The tool description itself does not add parameter-specific semantics; it focuses on outputs. However, it does provide context about why these parameters matter (e.g., priceTop controls how many collections are priced), but that is also in the schema. Thus the description adds no new parameter meaning beyond the schema, warranting the baseline score.

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

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

The description clearly states the tool's purpose: analyzing a wallet's holdings, grouped by collection, with counts, dominance, listed/compressed counts, royalties, supply share, and a floor-based ceiling. It explicitly lists the questions it answers, such as 'what do they collect' and 'how big a holder are they', distinguishing it from sibling tools like get_wallet_holdings which likely just returns raw items. The verb 'profile' plus the detailed explanation of outputs makes its function unambiguous.

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

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

The description implies usage for wallet profiling but does not explicitly state when to choose this tool over alternatives. It lists the kinds of insights it provides, which helps an agent infer its use case, but it never names sibling tools like get_wallet_holdings or get_collection_stats or provides exclusion criteria. The 'Read-only; needs no key' note gives some operational guidance but does not address selection among similar tools.

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 provide readOnlyHint and openWorldHint, but the description adds significant behavioral detail: it probes live sources rather than matching a hardcoded list, returns evidence including sources that found nothing, reports what was not checked and why, and warns against reporting 'does not exist' from empty results. These are valuable traits that go beyond the annotations and are not contradicted by them.

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

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

The description is front-loaded with the critical 'START HERE' directive, then efficiently covers scope, behavior, and return value. Every sentence adds value—there is no filler. It is appropriately sized for the complexity of the tool and well structured for quick comprehension.

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

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

Given there is no output schema, the description thoroughly explains what the tool returns (evidence, sources checked, confidence rating, what wasn't checked and why). It also covers edge cases like new collections and empty results. An agent has everything needed to decide when to call it and what to expect from the response.

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

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

The schema describes the query parameter as 'An address, marketplace symbol/slug, or collection name,' which is already high coverage. The description enriches this by specifying examples (Solana address, marketplace symbol or slug, plain collection name) and clarifying that it handles strings from any user paste, making the parameter's intent and acceptable inputs even clearer.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: to take any string and identify what it is, which marketplaces list it, and which tools to call next. It uses a specific verb ('identify') and resource (any identifier), and explicitly positions itself as the starting point for unknown identifiers, distinguishing it from siblings like search_collections or get_asset.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 'START HERE when you do not already know what an identifier is,' which is an explicit usage condition. It also mentions that it works on collections that launched today and probes live sources, implying it is the go-to for unknown or unregistered identifiers. It doesn't name specific alternatives, but it says it determines 'which tools to call next,' providing 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 indicate read-only and open-world behavior. The description adds valuable behavioral detail: it returns curated registry entries, and unregistered collections are still supported by passing identifiers directly to other tools. This goes beyond the annotations without contradicting them.

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

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

Three tightly packed sentences with no filler: the first states purpose and examples, the second explains what is returnedholistically, and the third covers the open-world fallback. Every sentence earns its place and important information is front-loaded.

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

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

For a single-parameter search tool with read-only and open-world annotations, the description is complete. It tells the agent what the tool returns, why that matters for downstream tools, and how to handle collections absent from the registry. No critical calling information is missing.

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

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

The schema already defines the query parameter well ('Free-text name search') with 100% coverage. The description adds helpful examples and clarifies the query expectation, but it does not substantially extend what the schema already communicates about the parameter.

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

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

The description opens with a specific verb and resource: 'Find digital-collectible collections by name', reinforced with concrete examples. It also distinguishes itself from sibling collection tools by stating it returns the identifiers (Magic Eden symbol, Core collection address) that other tools need.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 clearly states when to use the tool: when searching by name, not by structured identifiers. The fallback guidance for collections not in the registry is a useful alternative path, though it does not explicitly name sibling tools or say 'use this instead of X'.

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 goes beyond annotations: it states the tool returns 'confirmed, contradicted, or unverifiable', provides the exact numbers and instructions to reproduce the check independently, and explicitly says it returns UNVERIFIABLE rather than guessing. This adds critical behavioral context that annotations (readOnlyHint, openWorldHint) do not cover. It also emphasizes trust independence, which is a valuable behavioral trait.

Agents need to know what a tool does to the 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 detailed but not bloated. It front-loads the core purpose and usage, then explains return values and the tool's cautious behavior within the same paragraph. It is a single, dense paragraph that earns its length; could be slightly more scannable, but it's effective for the 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 with 4 parameters, 100% schema coverage, and no output schema, the description is complete. It explains what the tool returns, how to interpret results, and how to reproduce the check, which is critical for trust. Nothing essential is missing 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?

Although schema coverage is 100% (each parameter has a description), the tool description adds important context by tying the 'claim' types to the 'subject' and 'value' requirements. It clarifies that 'value' is required for supply and floor claims, and that 'wallet' is for ownership. This goes beyond the schema's individual descriptions but does not fully re-explain every parameter, so a 4 is appropriate.

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

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

The description clearly states the tool's purpose: verify a claim a user was told against on-chain reality. It enumerates concrete example claims (supply, never-traded, ownership, floor price), which also align with the claim enum. It distinguishes itself from data-fetching siblings (like get_collection_stats) by focusing on verification of external assertions, not just retrieving data.

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

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

The description explicitly says when to use: 'Use this whenever a claim about a collection or asset carries stakes' and provides examples. It does not explicitly name sibling alternatives to avoid, but it clearly implies that this is the go-to for validating assertions, while siblings (like get_floor_prices) are for direct queries. The guidance is strong enough for an agent to select correctly.

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