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

No annotations are provided, so the description carries the disclosure burden. It adds a real constraint beyond the schema ('ONE token'), which prevents misuse across multiple mints, but it says nothing about auth requirements, rate limits, error behavior for an ambiguous symbol, or pagination/return shape. Adequate but with a notable gap for a read tool with zero annotation coverage.

Agents need to know what a tool does to the 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, zero waste, front-loaded with the resource and scope before the alternative routing. 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?

There is no output schema and no annotations, so the description must be self-sufficient; it covers resource, valid timeframes, size cap/default, and the nearest alternative. It omits symbol-ambiguity handling and any hint of the return structure, but for a simple read-only candle fetch it is largely complete.

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

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

Schema coverage is 0%, so the description must compensate. It does restate the timeframe enum values and the limit cap/default (which the schema already encodes) but adds one genuinely new fact: the required mint parameter also accepts a symbol. Partial compensation, hence the baseline 3.

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

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

States a specific verb+resource ('OHLC price candles'), scopes it precisely to 'ONE X1 token (mint or symbol)', and explicitly distinguishes itself from the sibling token_lookup. An agent can tell it apart from every other price-related sibling without opening the 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?

Gives one clear routing rule: 'For the current price alone use token_lookup.' That is a genuine when-to-use-this-vs-alternative statement. It stops short of guidance on choosing a timeframe or limit, so it is clear context but not full when/when-not coverage.

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 no annotations, the description carries full behavioral burden. It does disclose useful traits: the content is drawn from the spec and deployed contracts, is cost-free ('Free.'), and spans a named topic set. It does not describe the return format or how the guide is structured, which for a no-output-schema informational tool is a minor gap.

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

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

The purpose is front-loaded in the first clause ('How ERC-8004 works on Arc'), followed by a colon-delimited coverage list. It is a single dense sentence, slightly run-on, but every listed item conveys scope 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?

For a zero-param, no-output-schema informational tool, the description is nearly self-sufficient: it names the topic, the source of truth, and the coverage areas. The only shortfall is the absence of return-shape or usage-routing detail, which is acceptable given the tool's simplicity.

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

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

The tool takes zero parameters, so the baseline is 4. The description correctly implies no configuration is needed; there is nothing for the schema to document and nothing missing.

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

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

It clearly states a specific purpose: an explainer of how ERC-8004 works on Arc, including the X1 registry location, sourced from spec and deployed contracts. It enumerates its coverage areas (registration, registration file fields, domain proving, agentWallet payments, reputation), which distinguishes it as a reference/guide rather than an action tool. It does not, however, explicitly contrast itself with closely related siblings like arc_agent_reputation or arc_agent_market.

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

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

Usage is implied rather than stated — an agent can infer this is a documentation lookup to consult before doing ERC-8004 work, and 'Free' signals no cost. There is no explicit when-to-use vs alternatives guidance (e.g., 'call this before arc_agent_market'), leaving routing 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?

With no annotations the description carries the full burden and does so: it enumerates all verdict values per chain family, explains edge semantics (UNSUPPORTED_CHAIN is never reported as unsellable; NO_ROUTE is strong evidence, not proof; UNPRICED/UNKNOWN are non-judgements), and discloses the critical operational fact that over MCP this tool returns the price and x402 URL rather than the data, plus the $0.004 per-call cost.

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

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

Front-loaded with purpose, then mechanics, verdicts, pricing and integration caveat in a logical order; nearly every sentence carries information an agent needs. It is nonetheless very long and repeats the chain enumeration (the 'seven chains' claim is followed by the full list again), which is mild redundancy rather than waste.

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

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

For a complex multi-chain, no-annotation, no-output-schema tool, the description covers supported chains, address-format branching, default chain, error states, verdict taxonomies, cost, and the MCP-specific response limitation. Nothing an agent needs to call it correctly or interpret it seems missing.

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

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

Schema coverage is 100%, so the baseline is 3 and the schema already documents mint, usd and chain. The description adds value beyond it by mapping raw chain ids to named networks (8453 Base default, 1 Ethereum, 42161 Arbitrum, 10 Optimism, 137 Polygon), which the schema does not spell 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 and outcome ('find out whether you can sell it', returns what you'd receive plus slippage and max position under 5%), and explicitly distinguishes itself from sibling exit tools (arc_exit_check, base_exit_check) and from safety-grade tools. An agent can identify resource and scope without opening the 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?

Gives an explicit when ('before you buy a token'), names the alternative for an executed sell test (arc_exit_check / base_exit_check), and explicitly says what this is NOT ('deliberately NOT a safety grade'), with the reasoning that safety and exitability measure different things. No inference required.

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 no annotations, the description carries the full burden and does meaningful work: it declares the paywall, says it returns x402 payment instructions for a specific endpoint, and specifies the ranking behavior ('ranked worst first') and the 25-mint batch cap. It doesn't state what happens to positions that fail mid-analysis or how partial results are returned, leaving some behavioral surface uncovered.

Agents need to know what a tool does to the 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 critical constraint (PAYWALLED) and the purpose, then layers scope, behavioral outcome, payment mechanics, and the sibling alternative. Four short sentences, no filler, each carrying distinct information.

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

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

With no annotations and no output schema, the description is nearly self-sufficient: purpose, batch limit, ranking, paywall mechanics, and alternative are all covered. It stops short of explaining the x402 payment flow end-to-end or error/partial-failure behavior, a modest gap for a mutation-ish analysis 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%, so both parameters are already documented (mints up to 25, optional usd position size). The description restates the 25-mint limit but adds no syntax, format, or defaulting detail for usd beyond what the schema provides, which is the expected 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 (portfolio exit analysis over up to 25 mints) and the exact question it answers ('of everything I hold, what am I trapped in?'). It explicitly distinguishes itself from the sibling exit_check by scope (one token vs portfolio), so an agent can route without opening either 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?

Names the alternative ('For one token use exit_check') and states the selecting condition (this one is for portfolios), covering both directions of the routing decision. The PAYWALLED prefix also signals the prerequisite before the agent commits to a call.

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?

No annotations are provided, so the description carries the full burden for behavioral disclosure. It states that the tool 'Returns the real bridge deposit address, limits and endpoints', which is a key behavioral trait (it doesn't perform the bridge but returns configuration). It also indicates it is a 'how to' guide, implying no state-changing actions, but doesn't explicitly say it's read-only. Given no annotations, the description does well to convey its advisory nature, though more clarity on side-effects would be ideal.

Agents need to know what a tool does to the 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 ('How to get onto the X1 chain and fund a wallet'), and immediately provides actionable steps (bridge or faucet) and key outcomes (returns real addresses). It saves the user call to action ('Start here if you have no X1 balance') for the end, which is effective. No wasted words.

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

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

Given the tool's simplicity (no parameters, no output schema), the description is quite complete. It explains the purpose, the methods (bridge/faucet), and what the response includes (deposit address, limits, endpoints). It doesn't detail the exact format of the response, but with no output schema, that might be fine. The only minor gap is not explicitly stating whether any prior setup or prerequisite is needed, but 'from outside' implies external origin. Overall, it's nearly complete for an informational tool.

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

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

The tool has 0 parameters, so parameter semantics are not applicable. The baseline for 0 parameters is 4, and the description adds context about what information is returned (deposit address, limits, endpoints), which is useful despite no parameters. Since there is nothing to clarify about inputs, 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: helping users get onto the X1 chain and fund a wallet, with specific actions (bridge from Solana or claim from faucet). It names the specific assets (APEX/XNT) and mentions the return of real deposit addresses and limits, distinguishing it from generic 'start here' tools. The phrase 'Start here if you have no X1 balance' further clarifies its unique role among siblings.

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

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

The description explicitly tells when to use this tool: 'from outside' and 'Start here if you have no X1 balance', setting clear context. It also mentions alternatives indirectly by describing the bridge and faucet options, and by noting other tools like bridge_assets and faucet_metrics exist but this is the entry point. No explicit 'when not to use' but the scoping is strong enough to guide selection.

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 no annotations, the description carries the full burden and does well: it declares the read is live from chain and, importantly, defines failure semantics ('if a read fails the answer says it is incomplete; it never reports an empty wallet it could not read'). It omits auth/permission requirements and rate-limit or pagination behavior, which keeps 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?

Three tight sentences, front-loaded with what is returned, then failure behavior, then the sibling routing. No filler and every clause carries information.

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

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

For a one-parameter read tool with no output schema and no annotations, the description supplies the return contents (native plus SPL/Token-2022 with symbols), freshness (live), and error semantics, plus a routing note. The remaining gap is the wallet parameter's expected format.

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

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

Schema coverage is 0% and the single required 'wallet' parameter is never described in the text. The description implies the wallet is an on-chain X1 wallet, but does not state the expected format (address vs. name/handle), leaving the parameter under-specified.

Input schemas describe structure but not intent. Descriptions should explain 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 resource and scope: every token balance of ONE X1 wallet, read live from the X1 chain, covering native XNT plus SPL and Token-2022 accounts with symbols. It also implicitly distinguishes itself from wallet_profile by pointing at that sibling for trading history.

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

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

Explicitly routes the agent: 'For trading history use wallet_profile.' That gives a clear when-to-use-elsewhere condition, though no other prerequisites or exclusions (e.g. multi-wallet batching) are mentioned.

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 no annotations, the description carries the full burden. It discloses the ranking criteria (pool liquidity, 24h volume, holders), warns about honeypot patterns (liquidity with zero holders/volume), and notes it's free. It doesn't detail the exact return format, but implies a recommendation among all matches. This is sufficient for the tool's complexity.

Agents need to know what a tool does to the 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 purpose is front-loaded and the ranking criteria are clearly stated. Some statistics (85 tickers, 7,965 tokens) are illustrative but slightly verbose; still, every sentence contributes to the tool's understanding. Overall efficient and well-structured.

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

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

For a single-parameter tool with no output schema, the description covers the core purpose, ranking logic, honeypot warning, and usage caution. It doesn't specify exact output format, but the intent is clear. Minor omission of return structure or limits, but not critical for effective use.

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

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

Schema coverage is 100% with a clear description for 'symbol' (Ticker to check, e.g. 'XNM'). The description adds crucial context that the parameter is a ticker symbol, not a mint address, and reinforces this with the guidance to resolve by mint instead. This meaningfully supplements the schema.

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

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

The description clearly states the action: given a ticker, find all tokens with that symbol and identify the most likely real one. It distinguishes itself from siblings like token_lookup by focusing on duplicate detection and ranking, and includes a concrete example (XNM) to clarify the input.

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

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

It provides explicit guidance to resolve tokens by mint address rather than ticker, implying when not to use this tool. It also explains that the tool exists to demonstrate why ticker-based resolution is unreliable. However, it doesn't explicitly name alternative tools or state precise conditions for use beyond the general purpose.

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 no annotations, the description carries the full burden and discharges it: it discloses that the tool is paid ($0.025/call over x402), the accepted payment rails, that no key or sign-up is needed, and — critically — that over MCP it returns the price and URL rather than the data. That last point is a behavioral trait an agent absolutely needs and could not infer elsewhere.

Agents need to know what a tool does to the 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, front-loaded with the core behavior, then routing alternatives, then the payment caveat. No filler; each sentence carries distinct, necessary information.

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

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

Given no output schema, no annotations, and a low-coverage input schema, the description supplies everything an agent needs to decide and call: scope, ordering, alternatives, cost, and the surprising MCP return-value caveat. 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 0%, so the description must compensate. It does clarify that 'mint' accepts a symbol as well as a mint address and reiterates the 100 cap, but it never explains the 'limit' default (20) or pagination semantics. Partial compensation for an undocumented two-parameter 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 ('latest on-chain trades of ONE X1 token'), the ordering ('newest first'), the key format ('mint or symbol') and the cap ('up to 100'). It also explicitly differentiates itself from the whale_ticker and firehose siblings, so an agent can route 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?

Names two alternatives with the exact conditions that select them: whale_ticker for whale-sized swaps across every token, firehose for the last 200 trades chain-wide. This is explicit when-to-use/when-not-to-use guidance rather than implied context.

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 no annotations, the description carries the full burden and does so richly: returns base64 signed by the caller, server never holds keys or signs, transaction is simulated against the wallet first, and a 0.1% XNT platform fee (>0.01 XNT) surfaces as platformFee. These are exactly the behavioral traits the agent needs beyond 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?

Core action and routing are front-loaded, followed by signing model and fees. Dense but each sentence (fee, simulation, signing) earns its place; only minor redundancy with the schema on the native/mint wording.

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

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

For a complex swap-builder with no annotations and no output schema, the description covers the return format, signing responsibility, fee behavior, and a pre-signing warning. Only marginal gaps (e.g., no explicit failure/error behavior) remain.

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

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

Schema coverage is 100%, so parameters are already documented; the description mostly repeats the schema (native for XNT, mint addresses) rather than extending it. The APEX mint address is a small value-add, but baseline 3 is warranted.

Input schemas describe structure but not intent. Descriptions should explain 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 (Build) and resource (UNSIGNED swap transaction on X1) and adds routing scope: best price across XDEX and APEX AMM, direct or two hops. No sibling tool builds swaps, so the agent can immediately distinguish it.

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

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

Gives clear usage context: build-then-self-sign flow, use mint addresses or "native", and 'Check priceImpact before signing — thin pools move hard.' Lacks an explicit when-not or named alternative, but the workflow guidance is 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?

With no annotations, the description carries the full disclosure burden. It does add valuable behavioral context: findings reflect observed on-chain facts, adjacency is explicitly excluded from accusations, and the free/paid feed distinction is stated. But it never discloses side effects, permissions, rate limits, or whether calling the tool is read-only, leaving important operational behavior 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?

The description is front-loaded with the core domain, and each sentence earns its place by explaining scope, pricing/feed behavior, evidence quality, and the adjacency caveat. It is slightly long for a one-parameter tool, but it is structured 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?

The tool has no output schema and no annotations, so the description must explain what a call returns and what happens with or without the wallet parameter. It does not state the response format beyond a vague mention of a JSON feed and blacklist, nor clarify whether invocation requires a subscription. This is a meaningful gap for an agent deciding how to call and interpret the tool.

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

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

Schema coverage is 100% and the single wallet parameter is already described as checking active subscription. The description adds some context by linking wallets to the paid push-alert tier, but it does not materially improve on the schema's parameter explanation.

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

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

The opening phrase 'Flux Threat Intel — scam wallet and token findings on X1' identifies the domain and resource, and later sentences clarify that it provides blacklist/finding data. However, the description never uses a concrete verb such as 'retrieves,' 'checks,' or 'lists,' and it blurs the tool's behavior with marketing about the paid subscription tier, so the agent must infer the actual operation.

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

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

No explicit when-to-use guidance is given, and no alternatives are named. The description implies the tool is for accessing scam findings and subscription alerts, but it does not tell the agent when to choose threat_intel over siblings like bulk_screener or token_lookup, nor any 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 no annotations, the description carries the full burden and does so: it discloses the paid model ($0.003/call, x402, USDC on Arc/Base/Solana or XNT on X1), that no key or sign-up is required, and — critically — that over MCP this tool returns the price and payment URL rather than the data. That last point is a non-obvious behavioral trait an agent could not infer from 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?

Front-loaded with the core action and return fields, then routing, then payment terms. Dense but every clause carries information. The parenthetical payment-method list is slightly heavy, keeping it from a 5.

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

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

No output schema exists, so the description must describe returns — and it does, listing price, holders, liquidity, volume and change. It also closes the biggest gap for a paid-over-MCP tool by stating that the MCP response contains a price and URL instead of data, so an agent is not surprised by the return shape.

Complex tools with many parameters or behaviors need more documentation. 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 parameter is already documented as 'Symbol (e.g. CAPY) or mint address.' The description nonetheless adds real meaning beyond the schema: that a symbol yields the best search match and that a mint address should be preferred when tickers collide.

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

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

Starts with a specific verb+resource ('Look up ONE X1 token by symbol or mint address') and enumerates exactly what is returned: price in XNT and USD, holders, liquidity, 24h volume and change. It explicitly distinguishes itself from sibling top_tokens, so an agent can route without opening a 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?

Gives explicit when-to-use guidance: symbol returns the best search match, and when several tokens share a ticker the agent should run impostor_check first and pass the mint. It also names the alternative (top_tokens) for ranked lists. This is a complete routing decision.

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 no annotations, the description carries the full burden and does so well: it discloses the $0.025 per-call cost, accepted payment rails, no-key/no-sign-up auth model, the x402 endpoint, and critically that over MCP it returns the price and URL rather than the data. That last point is a non-obvious behavioral trait an agent must know before calling.

Agents need to know what a tool does to the 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 purpose, then the sibling routing, then payment details last. Three sentences with little waste, though the payment clause is dense and packs several facts into one run-on sentence.

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

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

No output schema exists, so the description correctly enumerates the return fields (rank, symbol, name, liquidity, 24h change). Combined with the addressed n parameter, sibling routing, and payment/MCP behavior, an agent has everything needed to decide and call correctly.

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

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

The single parameter n has 0% schema description coverage, but the description compensates by stating the value semantics ('entries'), the range (3 to 25), and the default (8). It adds meaning beyond the bare min/max/default constraints, though it stops short of explaining ordering or truncation behavior.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Ranked list of X1 tokens by liquidity in XNT'), enumerates the returned fields, and explicitly distinguishes itself from the token_lookup sibling for single-token queries. An agent can identify the tool without opening the 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 routes the single-token case to token_lookup, which is clear sibling guidance. However, it does not say when to prefer this over other market tools like volume_check or xnt_price, and the paid nature is disclosed as a fact rather than as a decision criterion.

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 no annotations, the description carries the full burden and does so unusually well: it discloses the payment model ($0.004/call via x402, USDC or XNT, no key or sign-up), the audit caveat that no closed-position check is performed, and the surprising MCP behavior that the call returns the price and URL rather than the dataset. That last point alone prevents a serious misuse.

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

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

Three sentences, front-loaded with the metric definition before the caveat and the pricing/endpoint detail. The long parenthetical about payment rails is dense but each clause carries distinct information; only the hint at a nonexistent token parameter adds noise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 paid, one-parameter tool with no output schema, it covers the metric's meaning, its known limitation, the cost, and what the MCP response actually contains. The remaining gap is the undocumented `limit` behavior and any sense of response shape beyond "price and URL".

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

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

The single parameter `limit` has zero schema description coverage and is never mentioned in the description, so its default (10) and maximum (25) go unexplained. Worse, "per token" implies a token selector that does not exist in the schema, which could mislead an agent about what it can filter on.

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

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

Names a specific resource and metric: a leaderboard of X1 wallets ranked by net XNT flow. The negative definition ("NOT a profit and loss") plus the two illustrative cases pin down exactly what is being ranked, which separates it cleanly from siblings like top_tokens or x1_agents.

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

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

It gives strong interpretive guidance (what counts as a win vs a loss, no closed-position check) and a usage-critical caveat that over MCP the call returns a price and URL rather than data. However, it never states when to prefer this tool over siblings such as top_tokens or recent_trades, so the routing decision is left 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?

With no annotations provided, the description carries the full transparency burden. It discloses that the tool is paywalled, includes the cost ($0.004), explains the analysis approach, and indicates what output is provided (top round-trippers and pool liquidity). It lacks explicit mention of failure modes or rate limits, but the key behavioral aspects (paywall, analysis method, outputs) are covered without 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 about three sentences and packs a lot: purpose, method, output, and payment instructions. It is front-loaded with the core question and does not waste words. While not ultra-brief, every piece of information is valuable for an agent deciding to use this tool.

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

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

Given there is no output schema, the description does a good job of indicating what will be returned (top round-trippers and pool liquidity) and the payment requirement. It does not mention error handling or what happens for invalid mints, but for a simple single-parameter tool, this is reasonably complete. Sibling context is not needed.

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

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

Schema description coverage is 100% – the only parameter (mint) is described as 'Token mint address on X1.' The description does not add additional parameter meaning beyond what the schema states, so the baseline of 3 is appropriate. It does implicitly confirm the parameter is used in the endpoint path, but that is minor.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 question ('Is a token's volume real demand?') and clearly explains the analysis: round-trip analysis of the last 24h, distinguishing wash trading/arbitrage/market making from one-way trades, and returns top round-trippers and pool liquidity. It names the resource (token volume) and the method, making it distinct from siblings like recent_trades or top_traders.

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

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

The description implies when to use it: when assessing whether a token's volume is genuine demand. It sets the context (last 24h, round-trip analysis) and mentions the payment requirement. However, it does not explicitly contrast with alternative tools or state when not to use it, leaving some inference needed.

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?

No annotations exist, so the description carries the full burden and does so unusually well: it discloses the paid pricing model ($0.004/call via x402), accepted payment assets, that no key or sign-up is required, and critically that 'Over MCP this tool answers with that price and URL, not the data.' That last point is a non-obvious behavioral trait an agent could never infer from 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?

Front-loaded with the purpose, then alternatives, then payment mechanics — a logical order with no filler sentences. The payment parenthetical is dense but each clause is load-bearing; minor tightening is possible.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 paid tool with no annotations and no output schema, it covers purpose, alternatives, cost, payment routes, and the MCP-returns-price-not-data quirk. The one omission is what the returned 'reputation and trading profile' actually contains, which an agent would want to know.

Complex tools with many parameters or behaviors need more documentation. 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 one parameter with 0% schema description coverage, so the description must compensate. It clarifies the parameter identifies a single wallet ('ONE X1 wallet') sourced from indexed trades, but it never specifies the identifier format (address vs. name), leaving a real gap.

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

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

States a specific verb and resource — 'Reputation and trading profile of ONE X1 wallet' — and scopes it to 'trades our screener has indexed'. It explicitly names the sibling tools it is not (holdings for balances, top_traders for the leaderboard), so an agent can distinguish it 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?

Gives explicit routing: 'For its current balances use holdings; for the leaderboard across wallets use top_traders.' Both the alternatives and the conditions that select them are stated, leaving nothing 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?

With no annotations, the description carries the full burden and does so: it discloses paid access ($0.004/call), the accepted payment rails (USDC on Arc/Base/Solana or XNT on X1), no key/sign-up requirement, and critically that over MCP the response is the price and URL, not the data.

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

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

Three dense sentences, front-loaded with the data scope, then the sibling routing, then the payment/MCP caveat. No filler, and the most surprising constraint (paid + MCP returns no data) is stated plainly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 or annotations exist, and the description compensates by stating ordering, result cap, and the paid/MCP return behavior. An agent has enough to decide whether to call it and what to expect back in either transport.

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

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

Schema description coverage is 0% for the single `limit` parameter. The description only partially compensates by restating the cap ("up to 50"); it does not clarify the default of 20 or how limit interacts with the newest-first ordering.

Input schemas describe structure but not intent. Descriptions should explain 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+scope: "Whale-sized swaps across ALL X1 tokens, newest first (up to 50)." It explicitly contrasts with the sibling recent_trades ("For every trade of one token use recent_trades"), so an agent can route without opening either 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?

Names the alternative tool and the exact condition that selects it (single-token trade history → recent_trades), and flags that over MCP this tool returns pricing/URL rather than data, which is an effective when-not-to-use signal.

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 no annotations, the description carries the full burden and does well: it discloses the exact price ($0.003 per call), the accepted assets/chains (USDC on Arc/Base/Solana, XNT on X1), and the two-phase payment handshake. It omits failure modes and whether the live endpoint checks are cached, keeping it from 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?

Front-loaded with the data scope, then pricing, then the invocation flow, in three tight sentences. The first sentence is dense but every clause names a distinct returned field, so 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?

No output schema or annotations exist, so the description must supply everything, and it covers returned fields, cost, accepted payment rails, and the call sequence. A brief note on error/permission behavior would make it fully complete.

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

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

Schema coverage is 100% and the single `payment` param is documented there, but the description adds real value by explaining the workflow semantics: the first call omits it to fetch terms, and the second call passes the signed payload to complete the purchase in-call.

Input schemas describe structure but not intent. Descriptions should explain 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 resource (the X1 Agent Registry) and enumerates exactly what it returns: every registered agent, owner, registration file, live endpoint checks across MCP/A2A/x402/web, X1 payability, and feedback counts. This is far more specific than sibling registry-style tools and an agent can identify it immediately.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 concrete call pattern: 'Call once without `payment` for the terms, sign them with your own wallet, call again with `payment`,' plus the caveat that the registry is new and short. It does not name alternative tools or state when not to use it, so it stops just short of 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?

With no annotations, the description carries the full burden and does well: it discloses the paid nature, the payment mechanics (XNT to payTo, X-PAYMENT header), the write effect (register + mint NFT to the paying wallet), and the ownership semantics. Gaps remain around failure/retry behavior and settlement timing, but the core behavioral profile is disclosed.

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

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

Front-loaded with the identity and purpose, then the payment/POST mechanics. Dense parentheticals ('the Solana Agent Registry, deployed on X1 by APEX') add some clutter but every sentence carries actionable content.

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

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

No output schema exists, and the description compensates by stating what is returned (live XNT price, payTo, exact request). For a paid registration tool the agent has enough to act, with only minor omissions like confirmation/settlement expectations.

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

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

Zero declared parameters, so baseline is 4. The description usefully adds the effective payload shape {name, description, services?} sent via POST, which the empty schema does not convey, though it doesn't detail field constraints or required formats.

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

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

States a specific verb and resource: creating an ERC-8004 agent identity in the X1 Agent Registry, and scopes it as a paid done-for-you service. It also clarifies the odd 'Solana Agent Registry deployed on X1' framing, distinguishing it from the arc_passport_* siblings. It stops short of explicitly naming the sibling it is not, so not a full 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?

Gives concrete context for use and a stepwise flow: pay XNT to payTo, then POST your payload with the transfer signature in X-PAYMENT. It also names the alternative ('register yourself for network fees only'), though it defers to 'see page' rather than stating the trade-off explicitly.

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 no annotations, the description carries the burden well: it discloses pricing ($0.003/call), accepted payment rails, the x402 signature flow, and the important behavioral nuance that verification is by balance change so program-sent payments count. It omits what happens on a failed/landed-but-wrong response and whether results are cached.

Agents need to know what a tool does to the 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 core question and verification scope, then folds pricing and the call protocol into the same compact block. Dense and mostly waste-free, though the rhetorical opener and some phrasing lean promotional rather than operational.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 5-param, no-output-schema, no-annotation tool, the description covers the paid x402 handshake, the comparison inputs, and the verification basis. It stops short of describing the response shape (only hinting at confirmed/finalized, memos, fee), which leaves some guesswork about output.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds real meaning beyond the schema by framing `to` as 'the wallet you name', `mint`/native XNT selection, and `expect` as 'what you expected', plus clarifying that memos and fee are reported. It does not add syntax detail beyond that.

Input schemas describe structure but not intent. Descriptions should explain 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 (verify) and resource (an X1 payment) with concrete verification semantics: balance change, payer, recipient, confirmed vs finalized, memo and fee. It explicitly anchors on X1/XNT and SPL tokens, which separates it from the sibling arc_payment_check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 an explicit two-step invocation protocol: call without `payment` to get terms, sign with your own wallet, call again with `payment`. It also implies the expect/to/mint params are for comparing against expectations. It does not, however, explicitly say when to prefer it over arc_payment_check or other payment checks.

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?

No annotations are provided, so the description carries the full burden, and it does disclose the source of truth (the on-chain USDCx pool) plus what the reading contains (price, 24h and 1h change). It stops short of stating freshness/refresh cadence or failure behavior if the pool is unreachable.

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

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

Two short sentences with zero filler; the payload description comes first and the routing hint second. 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?

With no output schema, the description usefully enumerates the returned values (USD price, 24h change, 1h change), which is exactly what the agent needs. It leaves unstated the update frequency and behavior on missing pool data, which is a minor gap for a zero-argument 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?

The tool takes zero parameters, so there is nothing for the schema to describe and no parameter semantics to add; baseline is 4 under the scoring rules. The description correctly implies no input is needed.

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

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

States a specific resource (XNT price in USD) with concrete returned fields (24h and 1h change) and the data source (on-chain USDCx pool). It explicitly distinguishes itself from the sibling token_lookup, so an agent can route 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?

Names the alternative explicitly: 'For any other token use token_lookup.' That gives a clear when-not condition for non-XNT tokens, but there is no guidance on related cases such as historical prices (candles) or other quote assets.

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