APEX Faucet

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

With no annotations, the description carries the full disclosure burden and does add real behavior: the call is 'Free', gas is sponsored ('gas on us'), and the reward is rate-limited ('one per tool family per 30-day season'). It does not state whether the call is purely read-only or whether invoking it mutates wallet state, leaving a meaningful gap for a no-annotation tool.

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

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

It is a single semicolon-chained sentence, so nothing is wasted in length, but the front-loaded clause is the least informative part and the metaphor-heavy phrasing forces parsing before the actual function ('Returns the rules...') surfaces. Adequate but not cleanly structured.

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

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

There is no output schema or annotations, and only one optional parameter, so the description must be self-sufficient. It does say what comes back (rules, season, plate), but undefined domain terms ('APEX tools', 'Chef's Special', how the meal is forged) leave an agent without the vocabulary needed to interpret the result. Minimally 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% for the single optional 'plate' parameter, so the schema already documents type and meaning. The description's clause 'if you pass a plate number, that plate' restates rather than extends that, adding no syntax, format, or validation detail 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 does name a verb and resource secondary ('Returns the rules, the current season and, if you pass a plate number, that plate'), so an agent can infer this is a status/query tool for a reward program. But the leading clause ('using APEX tools serves the paying wallet an on-chain meal NFT') describes the broader mechanic rather than what this tool itself does, and undefined jargon ('APEX tools', 'Chef's Special', 'dishes') obscures the purpose.

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

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

It implies eligibility context ('serves the paying wallet', using APEX tools) and shows how the optional plate parameter changes behavior, which is useful implied guidance. However, it never states when to call it versus the many sibling tool-status tools, nor any exclusions or prerequisites in explicit terms.

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. It does disclose useful traits: the call is FREE, takes no input, and returns a deterministic list of stations. It says nothing about authentication requirements, rate limits, or whether the list is cacheable/static, leaving some behavioral gaps for a zero-annotation tool.

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

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

Three compact sentences, with the most decision-relevant facts ('FREE' and the return shape) front-loaded. The radio-line-up flavor text costs little, and every sentence carries either purpose, output, or next-step 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 output schema and no annotations, the description steps in to supply the return payload shape and the follow-up call, which is the key missing structured context. A brief note on auth or list stability would make it fully self-sufficient, but nothing essential to invoking it is absent.

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

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

There are no parameters (baseline 4), and the description's 'No input' correctly reinforces the empty schema. No additional parameter meaning is needed or possible 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 a concrete verb+resource: it lists the named agents in the X1 city that have a song, and it names the exact return shape (stations with name/wallet/role). It also distinguishes itself by naming the downstream sibling agent_tune. The 'APEX city radio line-up' framing is colorful but doesn't obscure what the tool returns.

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

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

It gives an explicit workflow: 'Use it to pick a wallet, then call agent_tune with that wallet to get its tune as notes.' That tells the agent exactly when to reach for this tool and what to do next. It stops short of stating exclusions (e.g., when not to use it versus agent_meal or agent_welcome_how_to).

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 load and does well: it names the exact evidence sources (ERC-8004 operator, on-chain distinct payers, live x402 probe, uptime, Hyperliquid record, bond, OFAC), which tells the agent how trustworthy the verdict is. It also discloses cost ($0.005), a rate limit (5 free/day), and the faucet for free credits — genuinely useful behavioral context beyond the schema.

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

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

Front-loaded with the verdict/return shape before the data-source list, and the pricing detail is correctly relegated to the end. The evidence list is a dense run-on, but every element listed is a distinct signal an agent would want, 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 exists, and the description compensates by defining the return shape (verdict, two strongest reasons, numeric score). Cost, free quota, and source coverage are all present; only failure modes and response latency are unaddressed.

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

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

Schema coverage is 100% and each parameter already documents its meaning ('or its ERC-8004 agent id', 'or the seller payTo'). The description only restates the one-of constraint, adding little beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb+resource+output: 'Check before you pay another agent' returning pay/caution/avoid, two reasons, and a 0-100 trust score. It is clear what the tool does and roughly what it returns, but it never names the near-identical siblings (arc_trust_check, x402_seller_check, arc_counterparty, x402_payment_test) that an agent must choose between.

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

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

'Check before you pay another agent' gives a clear trigger condition, and 'Pass ONE of url / address / agent' supplies an operational rule. What is missing is explicit routing against alternatives — nothing says when to prefer x402_seller_check or arc_reputation instead.

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 tool FREE, states the operation is deterministic, and discloses the edge case (wallet with no transactions returns hasSong false). It omits any auth/rate-limit or read-only framing, but for a derived read-style computation these are minor gaps.

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

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

Front-loaded with the FREE marker and the core purpose in the first sentence, with determinism, return shape, and edge case following in priority order. The inline enumeration of return fields is long but earns its place since no output schema exists.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 annotations and no output schema, so the description must carry everything; it enumerates the return fields, flags determinism, covers the empty-history case, and points at agent_radio. Complete enough to invoke correctly, though it does not say what a caller should do with a hasSong=false result beyond that fact.

Complex tools with many parameters or behaviors need more documentation. 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 fully described there (base58 address). The description only adds 'for example one from agent_radio,' which lightly reinforces sourcing but adds no format or constraint detail beyond the schema. Baseline 3 applies.

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

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

Specific verb and resource: turns one X1 wallet's on-chain transaction history into a playable tune. The scope ('one X1 wallet', 'deterministic') and the payoff ('give an agent a recognisable sound') clearly separate it from siblings like agent_radio and agent_meal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 concrete use cases (agent identity sound, fun activity display) and routes the agent to the complementary tool: 'to find wallets that already have a song, call agent_radio first.' No explicit when-not-to-use or prerequisite statement, so not a full 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?

No annotations are provided, so the description carries the burden. It explains the vault mechanics (deposit XNT, profit lifting share price) but does not explicitly state that the tool is read-only, safe to call, or any side effects. For a status tool, this is adequate but not exhaustive; it lacks explicit statements about immutability or side effects beyond the data itself.

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

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

The description is two sentences with no fluff. The first sentence front-loads the key status fields, and the second adds explanatory context about how the vault works. Every word earns its place.

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

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

Given zero parameters and no output schema, the description lists the primary data points returned (pool balance, share price, performance fee, immutability). It also explains the deposit and profit mechanics. It may not enumerate every possible field, but it covers the essential information an agent needs to understand what to expect. A 4 is appropriate as it is mostly complete but could explicitly mention units or additional fields.

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

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

The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and it correctly focuses on what the tool returns rather than inputs. No parameter information is missing.

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

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

The description clearly states the tool provides live status of the APEX agent trading vault, listing specific data points (pool balance, share price, performance fee, immutability). It distinguishes itself as a status tool, though it does not explicitly name alternatives like vault_heartbeat. The verb 'status' and resource are specific.

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

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

The description implies usage by describing what it returns, but it does not provide explicit when-to-use guidance or exclusions. With sibling tools like vault_heartbeat and other status tools, an agent might need more direction on when to choose this tool over others. The context is implied but not 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?

With no annotations, the description carries the full burden, and it does disclose meaningful traits: the challenge signing needs no gas and no transaction, and the faucet claim needs no captcha. However, it says nothing about what the tool actually returns (a guide? steps? state?) or any prerequisites like wallet requirements, leaving real gaps for a no-annotation tool.

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

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

Two sentences, front-loaded with the value proposition and then the sequence of steps. Dense but every clause (no gas, no transaction, no captcha, zero-cost) earns its place; nothing is wasted.

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

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

For a zero-parameter instructional tool with no output schema or annotations, the description lays out the full onboarding path and its cost profile. What remains missing is the return format and any alternative routing, but the core context is covered.

Complex tools with many parameters or behaviors need more documentation. 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 to document and the baseline of 4 applies. No parameter-related guidance is needed or expected.

Input schemas describe structure but not intent. Descriptions should explain 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 multi-step flow (register, sign challenge, become verified, claim free APEX from faucet) with a clear resource and scope. It is easy to distinguish from most siblings, but it does not differentiate itself from closely related onboarding tools like start_here or get_onto_x1, which likely cover overlapping ground.

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

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

Gives a clear use condition: 'for an autonomous agent with no funds' and 'the zero-cost way to start on X1'. It signals the intended audience and cost profile well, but never names when NOT to use it or points to an alternative sibling (start_here, get_onto_x1) for agents who already have funds.

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 disclose useful traits: the operation is free, and the price component is read live from the paywall so it 'cannot drift' (a freshness/accuracy guarantee). It stops short of covering return shape or pagination, but the disclosed cost and freshness semantics are substantive.

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

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

Three short sentences, front-loaded with what is returned, then cost, then the alternative call. Every sentence carries distinct information with no 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 parameterless read tool with no output schema, the description usefully states what comes back (active cards plus live price) and that it is free, which compensates for the absent output schema. Return format details are the only remaining gap.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless schema applies. No filtering or pagination parameters exist that would need explaining.

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

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

The description names a concrete resource — active agent cards on the Citizens Agora — and adds a second return element (the live posting price). It also names the sibling it is not (agora_post_instructions), so an agent can distinguish read from write. The only weakness is that the listing verb is implied rather than stated explicitly.

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

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

It clearly signals the read path ('Free to read') and routes the write path to a named alternative ('To post a card, call agora_post_instructions'). No exclusions are needed for a zero-parameter listing tool, so the guidance is effectively complete.

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 at all, the description must disclose behavior, and it does provide meaningful details: the cost is $1, XNT conversion uses the live rate at read time, and it returns x402 payment details. However, it does not clarify side effects (if any), authentication/contact requirements, or what happens with the inputs, so transparency remains partial.

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

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

Three short sentences, front-loaded with purpose then pricing then return value. Every sentence adds information and there is no filler.

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

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

Although the purpose and pricing are stated, the description is incomplete for invoking the tool correctly: no parameter semantics, no output structure, no usage scenario, and no annotations. With 7 parameters, 0% schema coverage, no output schema, and no annotations, more context is needed for an agent to confidently call this tool.

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

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

Schema coverage is 0% and the description maps almost none of the 7 parameters. The mention of chains and USDC could imply 'chain' values, but agentName, contact, priceUsd, description, agentAddress, and capabilities are left entirely to naming inference. For a 7-parameter tool, this is a meaningful gap.

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

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

The description identifies a specific action ('Get instructions'), a specific resource ('posting your agent card to the Agora'), and the return content ('x402 payment details'), making the tool's function unambiguous. It is clearly distinct from adjacent Agora or how-to tools by naming the exact post-instructions purpose.

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

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

The description makes clear that this is the tool to consult for posting an agent card to the Agora and includes relevant costing context. It does not explicitly state when not to use it or name alternatives, but the context and tool name are sufficient to route an agent to it.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the return value (deposit address plus memo/tag where required), chain-dependent payout asset, that the swap is executed by SideShift or Exolix, that the service never holds user coins, and that the call is free. It omits operational limits an agent would want — address/quote expiry, minimum amounts, and what happens on a wrong-network send.

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

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

Purpose is front-loaded in the first clause and every sentence carries a distinct piece of information (assets, return shape, custody, cost, next step). The middle passage is dense and slightly run-on with inline URLs, which costs a point on readability but not on substance.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 multi-step funding tool with no annotations and no output schema, the description covers what is returned, who executes the swap, custody posture, cost, and the mandatory next step. Missing pieces are timing and failure semantics (deposit address validity window, minimums, error handling), which matter for an agent orchestrating the send.

Complex tools with many parameters or behaviors need more documentation. 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 coin/network/amount/arcAddress are already documented individually and the baseline is 3. The description adds marginal value by pointing to the /api/anycoin/coins endpoint for enumerating valid coin-network pairs (useful since no enums exist), but adds no syntax or format detail beyond the schema.

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

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

States a specific verb+resource pair ('Buy APEX with almost any coin') and enumerates the supported assets, so an agent can distinguish it from direct-swap or single-asset purchase siblings without opening the schema. The 'any coin' framing and the explicit follow-up swap step make the scope 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?

Explains the flow clearly: call this to get a deposit address, send the coin, receive USDC on Arc (or ETH on Base for Kaspa/Filecoin), then swap into APEX via the quoted endpoint. It effectively implies the alternative for agents already holding USDC on Arc, but never says explicitly 'if you already have USDC on Arc, skip this and use the swap quote' or names any sibling tool.

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 enumerates the terminal and intermediate states (waiting, pending, processing, settling, settled, expired, refunded) and notes that settled includes the arrived amount and transaction. It also discloses that the call is 'Free', which matters in a paid/x402-heavy sibling ecosystem. It doesn't explicitly state read-only-ness or latency, keeping it just under a 5.

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

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

Two short sentences, front-loaded with the purpose, with the state list and cost note packed efficiently and no filler.

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

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

With no output schema, the description must convey return values, and it does by enumerating the status vocabulary and what a settled result contains. Only minor gaps remain, such as how long states typically take to transition or whether statuses ever regress.

Complex tools with many parameters or behaviors need more documentation. 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 'the order id apex_buy_any_coin returned'. The description adds no format or sourcing detail beyond that, so the schema does the heavy lifting — 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 and resource: 'Status of an apex_buy_any_coin order'. It also names the sibling that creates the order, so an agent can immediately tell this apart from apex_buy_any_coin itself.

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

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

The description plus the param note ('the order id apex_buy_any_coin returned') makes clear this is the follow-up call after placing an order. It gives clear context but no explicit exclusions or alternatives for other order-related situations.

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 clearly indicates this is a paid operation with a specific payment flow, something an agent must know before invoking. It also implies a read-only nature but doesn't explicitly state it; however, the payment requirement is a critical behavioral disclosure.

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

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

The description is three sentences, front-loaded with the core purpose, then the cost and payment flow. It's efficient, but the payment flow explanation could be seen as slightly dense for a single 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?

For a tool with one optional parameter and no output schema, the description covers the what, the when, and the how-to-pay. It lacks details on the output format, but since there's no output schema, this is a minor gap. The description is comprehensive for an agent to use it correctly.

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

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

The schema has one parameter (payment) with 100% description coverage. The description adds significant context beyond the schema: it explains the payment parameter's role in the two-step flow, including the format (base64 payload) and how it completes the purchase. This enriches the schema's minimal description.

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

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

The description clearly states the tool maps the agent economy on Arc by listing agents in the ERC-8004 registry, including owner, services, and x402 acceptance. It distinguishes itself from siblings like arc_agent_search and arc_agent_status by focusing on the registry-wide mapping, though it doesn't explicitly name a sibling.

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

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

It explicitly explains the two-step payment flow: first call without payment to get terms, sign them, then call with payment. It also specifies the payment methods and cost, which is crucial for calling the tool 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?

No annotations are provided, so the description carries the full burden. It discloses the data returned (reputation entries, summary, uptime records) and the rate limit (200 calls/day), adding meaningful context. It does not explicitly state read-only nature, but it is clearly implied. It adds value beyond the schema by describing the output composition.

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

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

The description is a single sentence that efficiently packs the core purpose, the included data, and the rate limit. It is front-loaded with the main function and appends constraints. While dense, there is no redundancy or 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?

With no output schema, the description thoroughly explains what is returned: reputation entries with specific fields, registry summary, and uptime records. It also provides rate limit information. For a one-parameter tool, this is complete and leaves no critical gap for an agent to call it correctly.

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

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

Schema coverage is 100% and the single parameter agentId is clearly described in the schema as the agent ID in Arc's ERC-8004 registry. The description does not add further parameter semantics, so it meets the baseline expected given high schema coverage.

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

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

The description explicitly states the tool retrieves reputation data for an Arc agent: every ERC-8004 entry (who gave it, value, tags, revocation status), the registry's summary, and weekly uptime records. It clearly differentiates from siblings like arc_agent_status by focusing on reputation and includes a distinct data scope.

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

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

No explicit guidance on when to use this tool vs alternatives. It mentions free usage and a rate limit but does not state selection criteria relative to sibling tools such as arc_agent_status or arc_agent_search. The description implies a read-only data lookup but provides no contextual hints for choosing it.

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

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

With no annotations, the description carries the full behavioral burden and does a good job: it reveals the underlying registry, that it is updated hourly by APEX Watchtower, the exact return fields, the free tier with 200 calls/day, and what this tool is not (the full directory). It stops short of describing query matching behavior or result limits, but the disclosed information is substantial.

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

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

Two sentences contain the core action, search scope, return fields, rate limit, and a pointer to the sibling tool. Every clause earns its place, and the most important purpose 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 simple two-parameter search tool with no output schema, the description covers the essential fields returned and the data source. It also gives a helpful alternative for richer data. It could mention result ordering, pagination, or no-result behavior, but these are minor gaps 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?

Schema coverage is 100%, so the schema already fully documents query and payableOnly. The description adds context by mentioning search is by name/endpoint and that results include whether the agent can be paid on Arc, which aligns with the payableOnly parameter. However, it does not materially extend the parameter meaning beyond the schema.

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

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

The description states a specific verb and resource: 'Find an agent on Arc by what it is called or where it answers', then defines the search scope as Arc's ERC-8004 registry. It also differentiates itself from the sibling arc_agent_market by clarifying that this tool returns a subset of fields rather than the full directory with owners and every service.

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

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

The description makes the use case clear: searching across agents by name or endpoint. It points users to arc_agent_market when they need the full directory, owners, and every service. It does not give explicit exclusions for other related siblings like arc_agent_status or arc_agent_reputation, but the primary alternative is clearly named.

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

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

No annotations are provided, so the description carries the full burden. It discloses the mechanism (calls every endpoint hourly), the uptime calculation nuance (never counting unmeasured hours as down), the paid/free distinction, and the output fields. It doesn't mention side effects or auth, but as a status check it's implicitly read-only. The disclosure is strong but lacks explicit error-handling details.

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

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

The description is verbose and somewhat rambling, starting with a rhetorical question and then covering the watchtower mechanism, output details, usage guidance, and pricing in a single block. It's informative but could be structured more clearly with sections or bullet points. It earns a 3 because it's not overly terse but could be better organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 must explain the return value, and it does: it lists status categories, uptime, response time, payment info, and fixes. It also covers both invocation modes and mentions the paid endpoint for full history. However, it doesn't specify what happens if an agentId is invalid or the response format details, but for a status tool this is reasonably complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds significant value beyond the schema by explaining the effect of including vs. omitting agentId (specific status vs. whole-registry counts) and the exact meaning of the parameter. This goes beyond a simple description of the field.

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

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

The description clearly states it checks whether an Arc agent actually answers, providing status, uptime, response time, payment info, and fixes. It distinguishes between the with-agentId and without-agentId modes, and none of the sibling tools address agent health, so it's uniquely identifiable.

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

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

The description explicitly says 'Call it before you pay or hire an agent,' providing a clear use case. It also explains the two invocation modes (with and without agentId) and mentions the paid endpoint for full history. However, it doesn't explicitly state when not to use it or name alternatives, though no direct sibling competitors exist.

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: default token (USDC), refusal of non-tokens before payment, per-call price ($0.001), the payment rail options, the two-step sign/pay protocol, and the 'never guessed' accuracy guarantee on spender names. These are material behavioral facts an agent cannot get 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?

The purpose is front-loaded and every clause carries information, but the middle section is a dense run-on of comma-separated return fields that could be structured better. Overall efficient with little 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 paid read tool with no annotations and no output schema, the description covers the otherwise-missing return values, the pricing model, the refusal case, and the full payment protocol. An agent has everything needed to invoke it correctly across both phases.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that `token` defaults to USDC, and more importantly it describes how `payment` drives the two-phase purchase flow (pass it and the call completes). That goes beyond the schema's one-line gloss.

Input schemas describe structure but not intent. Descriptions should explain non-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 clause names a specific verb and resource ('Allowance check on Arc before an approval') and then enumerates precisely what is returned: approval amount, unlimited flag, USD value, owner balance, spender identity, risk signals. The 'on Arc' scoping and explicit output list let an agent distinguish it from the generic `evm_allowance` sibling 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?

'before an approval' establishes the intended moment of use, and the closing sentences describe the exact two-step x402 flow (call without `payment` for terms, sign, call again with `payment`). It stops short of naming the alternative tool (`evm_allowance`) or stating when NOT to use it.

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

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

No annotations exist, so the description carries the full burden. It discloses a lot: the data is a static public chain record rather than a live check, the exact evidence fields returned, the meaning of attested:false, and the $0.001 x402 cost per call. It does not say what happens on an unknown/unattested token beyond attested:false, or whether payment is mandatory, but the disclosure is above average for an annotation-free read tool.

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

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

Front-loaded with the identity and grade vocabulary before the usage guidance and cost. Dense but every clause carries information; the only mild cost is the long enumeration of grades inside the opening 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?

With no output schema, the description compensates by naming the returned fields (grade, sha256 evidence hash, block). Payment mechanics are covered jointly by the schema's payment description and the x402 cost note. Remaining gap is edge-case behavior for unknown tokens.

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

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

Schema coverage is 100%, so both parameters are already fully documented and the baseline is 3. The description adds the $0.001 x402 price context that motivates the payment parameter, but provides no extra format or semantics 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?

States a specific verb+resource: it reads the on-chain immune attestation (ImmuneAttestations) for an Arc token, naming the contract and chain. It enumerates the returned grades (A/B, C, D, F, ?) and explicitly contrasts itself with the sibling arc_immune, so an agent can distinguish the two without opening schemas.

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

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

Gives explicit guidance: 'Read it before you buy' establishes the use context, and 'not a fresh check (a fresh one is arc_immune)' names the alternative and the condition that picks it. It also warns that attested:false is not a clean bill of health, which prevents a likely misuse.

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 discloses that quotes are live, measured per source chain, refreshed every 10 minutes, and includes the X1 bridge minimum of 11 USDC. It also notes a CCTP mention. With no annotations provided, the description carries the burden and does a good job of setting expectations about data freshness and constraints, though it doesn't detail the exact output format or failure modes.

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

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

The description is a single, information-dense sentence that front-loads the core purpose (USDC onto Arc) and then adds specifics. It's slightly long but every clause adds value: source chains, LI.FI, what's measured, refresh rate, X1 minimum, and CCTP note. The usage guidance at the end is a bit tacked on but 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 zero-parameter tool with no output schema, the description covers the key context: what it does, how it works (LI.FI), what data it provides (cost, time, what arrives), freshness (10 minutes), and a usage scenario. It doesn't explain how to interpret the quote or what 'claim at the faucet' entails, but those are likely covered by sibling tools (arc_faucet_claim).

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

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

The tool has zero parameters, so the description doesn't need to explain parameter semantics. The baseline for 0 params is 4, and the description adds context about what the tool measures and returns, which is sufficient.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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: it provides live USDC bridge quotes to Arc (eip155:5042) from multiple source chains via LI.FI, including cost, time, and what arrives. It also mentions the X1 path and CCTP note, distinguishing it from generic bridge tools like bridge_assets or get_onto_x1.

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

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

The description explicitly says 'Use it to bring an agent or a person to Arc from wherever they are, then claim at the faucet,' giving clear context for when to use it. It doesn't explicitly state when not to use it or name alternatives, but the sibling list includes bridge_assets and get_onto_x1, and the description's specificity about Arc and USDC implies the alternative scenarios.

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 burden but adds significant behavioral context: the free-during-development aspect, the x402 payment flow with specific assets and chains, and the need to call twice (first for terms, then with payment). It doesn't cover potential rate limits, data freshness, or exactly what the transactions array includes, but it discloses the payment mechanics and analysis scope.

Agents need to know what a tool does to the 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 question and key details, then transitions to payment logistics. It's fairly dense but not overly verbose. Some sentences are long, but every part contributes useful information about what the tool does and how to invoke it.

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

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

Given no output schema and no annotations, the description does a good job covering what the tool returns (creator's buy, funded wallets buying early, transactions) and the payment process. It lacks explicit guidance on when to use it versus similar tools and doesn't detail data sources or limitations, but it's largely complete for an agent to understand and call 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% for the single 'payment' parameter, which is well-described in the schema. The description adds the two-step payment flow (call without payment for terms, then with signed payment) and mentions passing a token or pool (though that's not in the schema, it's likely implicit in the tool's operation). Baseline 3 is appropriate when the schema already documents 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 names a specific analysis verb ('bundled') and details exactly what it returns: creator's buy share of supply, funded wallets among first 60 swaps of first two minutes, and transactions. It distinguishes itself from siblings like arc_contract_check or arc_fresh_launches by focusing on launch bundling detection, though it doesn't explicitly contrast with 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?

Usage is implied by the description's focus on 'Arc launch' and the instruction 'Pass token or pool', which suggests it's for checking if a specific launch was bundled. However, there's no explicit when-to-use vs. alternatives, no when-not-to-use, and no mention of prerequisites beyond the payment process.

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, and it does well: it discloses the data source (Circle's x402 catalogue), freshness (refreshed daily), ordering (cheapest first), and that it includes 'our own products with their prices for comparison.' It also states it is free. It does not mention pagination or rate limits, but the schema's limit parameter covers pagination.

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

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

Three sentences, front-loaded with the core question, then the resource, ordering, fields, and use case. Every sentence earns its place; the final 'Free.' is a useful behavioral note, not 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 search tool with 4 optional params and no output schema, the description is nearly complete: it names the catalogue, the ordering, the fields returned, and the use case. It does not describe the output shape, but with no output schema and a simple search result, the description's field list (host, path, category, settlement) gives the agent enough to know what to expect.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds context for query ('keywords') and maxPrice ('optional price cap in USD') but does not add meaning beyond the schema for limit or network. The description's mention of 'cheapest first' and 'by keyword' reinforces query semantics but does not substantially exceed 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 opens with a concrete question ('Who sells this on Arc, and for how much?') and states the resource (Circle's x402 catalogue), the action (search by keyword, cheapest first), and the returned fields (host, path, category, settlement). It also distinguishes itself from the broader catalog_browse/catalog_product siblings by specifying it searches Circle's own x402 catalogue.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 the agent when to use it: 'Use it to price a service before you build or buy it.' It also frames the catalogue as what Circle CLI agents buy from, refreshed daily, which implies it is the authoritative pricing source. It does not name alternatives, but the use case is so specific that an agent can 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?

No annotations are provided, so the description carries the full burden. It discloses the payment flow (two-step: terms then payment), the cost, and the fact that passing `payment` completes the purchase inside the tool call. It doesn't detail what happens after payment or whether the call is idempotent, but the two-step flow is clearly explained.

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

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

The description is compact and information-dense. Every sentence earns its place: what the tool measures, the cost, the two-step usage pattern, and the parameter semantics. It front-loads the core purpose before explaining the payment flow.

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

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

For a tool with one optional parameter and no output schema, the description covers the essential context: purpose, cost, supported assets/networks, and the two-step payment flow. It doesn't describe the output format, but given the tool's simple interface and the absence of an output schema, this is a minor gap.

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

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

The schema has 100% coverage for the single `payment` parameter, describing it as a signed x402 payment (base64 payload for PAYMENT-SIGNATURE). The description adds context about when to pass it (second call after signing terms) and that it completes the purchase, which goes beyond the schema's basic type description.

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

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

The description clearly states the tool's purpose: measuring the real cost of bringing USDC into Arc via Circle CCTP, with specific details about what is measured (arrivals, amount credited, fee taken, observed fees by size). It distinguishes itself from sibling tools like arc_bridges, arc_fee_flow, and arc_stablecoins by focusing on CCTP cost measurement from arrivals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 usage guidance: call once without `payment` to get the terms, sign them with your own wallet, then call again with `payment`. It also states the cost ($0.004 per call over x402) and the supported networks (USDC on Arc, Base or Solana, or XNT on X1), which helps the agent decide when to use this tool.

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 burden of behavioral disclosure. It mentions 'Read live from the chain' (implies read-only) and discloses the tool is free with a 200-calls-per-day limit. It also enumerates exactly what it checks, giving the agent a clear picture of the tool's behavior. It doesn't describe the return format (since no output schema exists), but it gives enough context for an agent to understand side effects and constraints.

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

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

The description is a single, dense sentence that front-loads the use-case and enumerates checks. Every clause adds value: the trigger, the list of checks, the live-chain read, and the rate limit. No wasted words, well-structured for scanning.

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

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

For a tool with reasonable complexity (proxy, owner, token checks) and no output schema, the description gives enough for an agent to decide when to call it. It states the tool is Arc-specific, what it inspects, and its limits. The main gap is the absence of return-format details, but since no output schema exists, an agent can infer the output from the listed checks. It's sufficiently complete for 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 schema already describes the 'address' parameter as '0x contract address on Arc' with 100% coverage. The tool description refers to 'a contract on Arc' but adds no additional syntax, format, or constraints beyond what the schema provides. Since schema coverage is complete, the baseline of 3 is appropriate—the description doesn't meaningfully enrich the parameter semantics.

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

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

The description explicitly states the tool's purpose: verifying that an address is a real contract, checking for proxy upgradeability (EIP-1967 implementation, admin, beacon slots), identifying the owner, and determining the token it claims to be. This is a specific verb-resource combo that clearly distinguishes it from siblings like arc_impostors or arc_exit_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?

The description opens with 'Before you approve, pay or trust a contract on Arc', which gives a clear contextual trigger for when to use the tool. It doesn't explicitly name alternative tools or state when NOT to use it, but the context is sufficient for an agent to infer appropriate use cases. A slight improvement would be naming specific alternatives, but it's already clear.

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

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

With no annotations, the description carries the full burden and delivers: it states that reverts/non-contracts are refused before payment, discloses the exact price ($0.001 per call), the payment rail (x402 with USDC on Arc/Base/Solana or XNT on X1), and the two-phase call-once-then-sign flow.

Agents need to know what a tool does to the 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 purpose, then pricing, then usage flow. The parenthetical example list is slightly dense, but each sentence adds a distinct fact and none are filler.

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

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

With no output schema and no annotations, the description covers the critical behaviors an agent needs (scope, refusal rules, cost, payment flow) and hints at return content (decoded values plus block and time). It could say more about the decoded return shape, but nothing essential 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?

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning for the `payment` parameter by explaining its two-step lifecycle (call without it to get terms, sign, then call again with it). The remaining params (fn, args, block, address) add nothing 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?

States a specific verb+resource: a single decoded view call on any contract, returning block and time, with example outputs (owner, paused, allowance, balance). The 'view/pure only, decoded' framing meaningfully separates it from raw sibling call tools like evm_call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 when-to-use (view/pure functions) and an implicit when-not (non-view functions and reverts are refused), plus explicit multi-step invocation guidance for the payment handshake. It does not name a specific alternative tool for write calls, which keeps it just under 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?

With no annotations provided, the description carries full responsibility for behavioral disclosure. It transparently states the $0.004 per-call cost, the two-step payment process (terms first, then signed payment), and the data provenance guarantee ('Facts from the chain, never a label'). It omits rate limits or explicit read-only status, but the key behaviors are well covered.

Agents need to know what a tool does to the 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 purpose question, followed by a compact list of metrics, then cost and payment steps. Every sentence contributes value—purpose, outputs, provenance, pricing, and invocation flow—with no filler. The metric list makes it slightly longer than strictly necessary, but each item sharpens the tool's 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 no output schema, the description provides a solid overview of the return content (trading metrics and flags) and fully explains the required input and payment workflow. It doesn't specify the exact response structure or define 'flags', but the description gives enough for an agent to understand what to expect and how to execute the two-step 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 coverage is 100%, so the baseline is 3. The description adds meaningful workflow context beyond the schema: it explains that calling without `payment` returns terms and that passing the signed `payment` completes the purchase. It also ties the `address` parameter to the trading-profile purpose, enhancing the schema's dry field description.

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

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

The description opens with a specific question—'Who is this Arc address as a trader?'—and then enumerates concrete outputs: first-buyer frequency, entry speed, USDC in/out, stuck positions, and flags. This is a clear, specific purpose that distinguishes it from generic wallet or reputation tools, even without naming siblings.

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

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

The description implies the use case (profiling a single Arc address's trading behavior) and gives detailed invocation steps for the x402 payment flow: call without payment for terms, sign, call again with payment. However, it never explicitly contrasts with sibling tools or states when not to use this tool, leaving alternatives unaddressed.

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 of behavioral disclosure. It transparently reveals the paid nature, the two-step payment flow, and the data returned (creators, launches, swap fees). However, it does not explicitly state whether the tool is read-only or has any side effects beyond payment. Given the context of a data-retrieval tool, this is a minor gap but the description is still highly transparent.

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

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

The description is compact and front-loaded with the core purpose before diving into payment mechanics. It uses three sentences to convey purpose, cost, and usage steps without redundancy. The structure is efficient, though the payment details are dense and could potentially be broken out, but it remains appropriately sized 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?

Given no output schema and one parameter, the description covers the essential aspects: what data is returned (creators, launches, fees), the payment flow, and the cost. It does not detail the exact output format, but the nature of the data is described. For a paid tool with a two-step process, the description is sufficiently complete for an agent to call it correctly, though a note on expected response structure would enhance it.

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

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

The single parameter `payment` is well-documented in the schema ('a signed x402 payment (the base64 payload you would put in PAYMENT-SIGNATURE)'). The description adds crucial context on when to pass it ('Call once without `payment` for the terms... call again with `payment`'), which goes beyond the schema's static definition. This helps the agent understand the temporal dependency, making it more than a simple parameter description.

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

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

The description clearly states the tool's function: 'Who launched what on Arc and whether any of it ever traded: every repeat creator with their launches and the swap fees those launches earned.' This specific verb+resource distinguishes it from siblings like arc_fresh_launches (which likely focuses on fresh launches) and arc_agent_market (agents rather than creators). The purpose is unambiguous and not a tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 usage instructions: 'Call once without `payment` for the terms, sign them with your own wallet, call again with `payment`.' It also specifies the cost and payment methods ($0.004 per call over x402 on USDC/XNT). This is a clear when-to-use and how-to-use guide, and it differentiates the two-step payment process from typical one-shot calls.

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 cost ($0.01/call), payment rails (x402 USDC on Arc/Base/Solana, XNT on X1), a two-step auth flow, the return content, and a 'Not advice' disclaimer. It omits rate limits and error/failure behavior, so not 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?

Dense but front-loaded: the signal rule and returns come first, then pricing, then the payment flow. Every sentence carries actionable information, though the single wall of text is slightly heavy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 paidsignal tool with no output schema and no annotations, the description covers purpose, return contents, pricing, and the payment protocol. It leaves only minor gaps around failure handling and rate limits.

Complex tools with many parameters or behaviors need more documentation. 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 `payment` param is fully covered by the schema, and the description adds real meaning by explaining what passing it does ('the purchase completes inside this tool call') and how to obtain/sign the terms. This exceeds the schema baseline.

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

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

States a specific resource (Arc dip signals) plus the exact strategy rules (BUY at 18%+ below 2-hour high, SELL at +10%, WARN at -60%). An agent can immediately distinguish it from arc_smart_signals and bnb_dip_signals based on the Arc scope and rule set.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 operational context, including the two-step purchase flow ('call once without payment for the terms, sign them with your own wallet, call again with payment'). Does not name an explicit when-not or alternative sibling, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden and does so thoroughly: it discloses the simulation method (buy-then-sell round trip inside one eth_call via the pool hook, nothing spent), the ERC-20-USDC fallback (both legs quoted), and what gets returned. It also reveals the critical pricing behavior — $0.025/call over x402 and, crucially, that over MCP the tool returns the price/URL rather than 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?

Front-loads the core purpose and the exclusion ('not a score') before alternatives and payment details. Dense and information-rich, though the conversational framing ('If I put in this much, can I get out?') and 'The answer names its method' add slight redundancy.

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

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

No output schema exists, so the description must describe returns — and it does, enumerating pass/fail, round-trip cost, depth, liquidity-pull risk, and flags with reasons. Combined with the payment/MCP-return caveat, an agent has everything needed to call and 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 both parameters (usdc, query) are already fully documented with types, defaults, and format constraints. The description restates the size ('usdc, default 1') and address formats but adds no syntax or semantics beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('SELL TEST AT YOUR SIZE... can I get out?') and explicitly distinguishes itself from the scoring tool ('not a score'). Names the two sibling alternatives (arc_verdict, arc_exit_check_bulk) so an agent can disambiguate without opening schemas.

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

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

Gives explicit when-to-use routing: 'For one 0-100 buy score with no size needed, use arc_verdict. For up to 25 tokens in one call use arc_exit_check_bulk.' Also scopes the tool to Arc and to token addresses / v4 pool ids, 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 load and does a lot: it declares the operation is PAYWALLED, gives the exact price ($0.025) and accepted currencies (USDC on Arc, USDC on Solana, XNT), names the paid endpoint, and specifies the 25-item cap and sort order. What it does not disclose is the actual result payload once paid, or failure behavior on invalid/mixed ids.

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

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

Four dense fragments, front-loaded with the paywall flag and capped scope, with zero filler. Every clause carries a distinct fact: cap, sort order, payment output, price/currencies, and the sibling alternative.

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

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

There is no output schema, and the description compensates by stating that the call returns x402 payment instructions and the endpoint path, plus the ordering of the eventual result. For a one-parameter tool this is close to complete, though it leaves the post-payment response shape and invalid-input behavior unstated.

Complex tools with many parameters or behaviors need more documentation. 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 'ids' parameter is fully documented, so the baseline is 3. The description's 'up to 25 Arc tokens or pool ids' mirrors the schema description rather than adding format or validation details (e.g. whether addresses and pool ids can be mixed in one array).

Input schemas describe structure but not intent. Descriptions should explain 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 operation (bulk exit check) with an explicit scope cap (up to 25 Arc tokens or pool ids) and an ordering rule (worst first by cannot sell / heavy loss / cannot buy), which conveys what an 'exit check' actually evaluates. It also names the sibling it is not (arc_exit_check), so the agent can separate the two without opening schemas.

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

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

Clearly routes single-token work to arc_exit_check ('For one token use arc_exit_check'), which is an explicit alternative with a selecting condition. It also flags the paywall and the x402 payment path, so the agent knows a payment step is required before results. It does not state when the bulk call is preferable beyond the count (e.g. batch economics), so it stops short of 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 the burden. It discloses the measurement basis (EIP-3009 authorization spend), the scope (on-chain, Arc USDC), and the inclusion of Circle's facilitators. It also notes the tool is 'Free', which is a behavioral/access trait. It does not mention pagination or rate limits, but the single optional limit parameter covers the main behavioral control.

Agents need to know what a tool does to the 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 sentence that front-loads the core purpose and then lists the output dimensions. Every clause adds information: measurement basis, scope, output fields, flow shape, and the Circle facilitator addition. 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 read-only analytics tool with one optional parameter and no output schema, the description is nearly complete. It tells the agent what data it returns and the measurement basis. The only missing context is what 'flow shape' means precisely (direct, circular, concentrated, self or contract are listed but not defined), and there is no explicit statement about the return format. These are minor gaps 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?

Schema coverage is 100% for the single parameter, so the schema already documents 'limit'. The description does not add detail about the limit's effect beyond what the schema says (default 15, max 60). Baseline 3 is appropriate because the schema carries the parameter meaning fully.

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

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

The description states a specific verb ('settles'), a resource ('x402 payments on Arc'), and a precise measurement basis ('every relayer that spent an EIP-3009 authorization on Arc USDC'). It also enumerates the exact outputs (settlements, payers, payees, volume, flow shape) and names the two facilitator categories. This clearly distinguishes it from siblings like arc_x402_stats or x402_inspect.

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

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

The description implies when to use it: when you need relayer-level settlement detail on Arc, including Circle's facilitators. It does not explicitly state when not to use it or name alternatives, but the specificity of 'measured on the chain' and the relayer focus provides clear context. A small gap: no explicit exclusion of other x402 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?

With no annotations provided, the description carries the full burden and handles it very well: it discloses that the operator pays gas, that a contract enforces cooldown/daily limits, that there is no withdraw function, the UTC open windows, and the 8-hour per-connection limit. It even states what a refusal means and names the response 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?

The description is dense but mostly earns its length because it packs a two-step protocol, timing windows, and response fields into a compact paragraph. It is front-loaded with the core action, though a phrase like 'Same claim for everyone' adds only modest value.

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

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

The tool has no output schema, so the description's mention of nextClaimAt and claimNumber fills that gap. Accounting for the two-step signature flow, cooldown behavior, and response contents, nothing needed to use the tool correctly is left unexplained.

Complex tools with many parameters or behaviors need more documentation. 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 description reinforces the schema's address and signature meanings. It adds useful detail beyond the schema by specifying that the signature must be personal_sign from the address's key and that the first call intentionally omits signature to receive the challenge.

Input schemas describe structure but not intent. Descriptions should explain non-obvious 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 action ('Claim real USDC and APEX on Arc') and identifies the resource and target address, so the tool's role is unmistakable. It also includes a two-step protocol that sets it apart from status/metrics siblings like arc_faucet_status and faucet_metrics.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 step-by-step invocation guidance: call with only {address} first, sign the challenge with EIP-191, then call with {address, signature}. It explains timing and cooldown constraints, but it does not explicitly name alternative tools or say when not to use this one.

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 fully carries the behavioral burden and does so excellently: it discloses live reads from the contract, honest error behavior (failed reported as failed, never zero), cost ('Free'), and the three-part daily release schedule. This is highly transparent for a status tool.

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

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

Every sentence earns its place. The description front-loads the core status payload, then adds crucial behavioral details and the chain identifier without any filler. Dense but well organized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 annotations, and no output schema, the description is complete: it lists every returned datum, explains the timing semantics, clarifies live vs cached reads, and specifies error and cost behavior. An agent has everything needed to call and interpret the tool correctly.

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

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

The tool has 0 parameters, so the baseline is 4. The description adds relevant output-context semantics even though no parameters exist to document.

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

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

The description states a specific resource (APEX faucet on Arc) and explicitly enumerates the data points returned: pot, claim amounts, claims left today and right now, release timing, and cooldown. It clearly identifies this as a status read, distinguishing it from the claiming sibling arc_faucet_claim without naming 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?

Clear context is provided about what information is available and how to interpret nextReleaseAt with specific UTC release times. However, it does not explicitly state when to prefer this tool over alternatives like arc_faucet_claim or faucet_metrics, so it earns a 4 rather than 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?

With no annotations provided, the description carries the full behavioral burden. It discloses the two-phase x402 payment flow, pricing, supported currencies, the fact that changes are measured against a previous scan, and that the purchase completes inside the tool call. This is unusually transparent for a paid tool.

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

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

The description is three dense sentences with no filler. The data result is front-loaded before payment instructions, and each clause contributes distinct information: result contents, fee source, pricing, and workflow.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 one optional parameter and no output schema, the description is complete: it states what data will be returned and exactly how to complete the payment flow. An agent has everything needed to call the tool correctly without inferring missing details.

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

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

The schema already describes `payment` clearly with 100% coverage, so the baseline is 3. The description adds value by explaining the exact call sequence—get terms without payment, sign with your own wallet, then resubmit with payment—making the parameter's role actionable 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 defines the tool as a view over Arc launchpad fee vaults, listing current USDC vaults, their creators, tokens, and change since the previous scan. It lacks an explicit verb like 'list' or 'show,' but the colon-style definition and concrete return fields make the purpose clear and distinguishable from 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 gives an explicit usage workflow: call once without `payment` to receive terms, sign them, then call again with `payment`. It also states the per-call cost and accepted currencies. It does not name alternatives or exclude other use cases, but the context is sufficient for an agent to know when to invoke it.

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

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

With no annotations, the description carries the full burden and does so well: it discloses pricing ($0.003/call), the accepted x402 payment rails (USDC on Arc/Base/Solana, XNT on X1), the payment handshake, and the provenance of the verdicts (first 60 swaps of the first two minutes, earliest 12 buyers' funders). This is exactly the behavioral context an agent needs before paying to call.

Agents need to know what a tool does to the 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 and the value proposition, then the payment mechanics. Dense but nearly every clause carries a distinct fact; the parenthetical on swap/buyer sampling is long but justifies the trust claim.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, no-output-schema, paid tool, the description covers everything needed to call it correctly: cost, accepted currencies, the sign-then-resubmit flow, and what the returned verdicts mean and where their raw evidence lives.

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

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

Only one parameter, and schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining the semantics of omitting `payment` (returns terms) versus supplying it (purchase completes in-call), which is the key operational distinction the schema alone does not convey.

Input schemas describe structure but not intent. Descriptions should explain 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 (real-time Arc launches / new pools) and states precisely what each result carries: a sell verdict from a real round trip and a bundle verdict. It also implicitly differentiates itself from arc_bundle_check by naming it as the place the raw evidence lives, so the agent can tell the summary tool from the evidence tool.

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

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

Gives explicit invocation instructions, including the two-step handshake (call once without `payment` for terms, sign with your own wallet, call again with `payment`). It does not, however, state when to prefer this over siblings such as arc_pools or arc_exit_check, 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 burden. It discloses the two-phase workflow (terms then payment), the cost, and that payment completes the purchase within the same tool call. However, it doesn't specify what the response looks like when terms are returned or what happens if payment fails, which is a minor gap given the paid nature.

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

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

The description is compact and front-loads the core value (real costs) before procedural details. Every sentence earns its place; no fluff.

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

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

For a tool with one optional parameter and no output schema, the description covers the workflow and cost adequately. The only minor omission is what the returned data looks like (e.g., a table of percentiles), but the high-level outcome is clear. It's sufficient for an agent to proceed 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% for the single `payment` parameter, so the schema already describes it as a signed x402 payment. The description adds context on how to use it (the two-call workflow) but not much beyond. Baseline 3 is appropriate given high schema coverage.

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

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

The description clearly states the tool reports actual Arc transaction costs with percentiles and sample sizes, distinguishing it from quoting docs. It also mentions the specific cost ($0.004 per call) and the payment workflow, making its purpose unmistakable.

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

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

It provides explicit instructions: call once without `payment` to get the terms, sign them, then call again with `payment`. It implies this is the tool for Arc gas costs, standing apart from siblings like arc_cctp_cost or arc_x402_stats, and tells the agent exactly when to use it.

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

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

With no annotations, the description carries the burden. It discloses the $0.025 per-call cost, accepted tokens, and the two-step payment process. It doesn't describe the response format or potential side effects, but for a data-listing tool this is acceptable.

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

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

The description is two sentences, front-loaded with the core purpose, followed by cost and payment instructions. No redundant information; every sentence adds value.

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

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

The description covers the tool's purpose, cost, and payment flow, which are the critical aspects for correct usage. It doesn't specify the exact output structure, but since there's no output schema and it's a simple data listing, the information provided is adequate.

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

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

Schema coverage is 100% for the single 'payment' parameter, and the schema already explains its format and purpose. The description adds context about the sequential usage (first call without, second with), which enriches the parameter semantics.

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

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

The description clearly states the tool provides a list of dead Arc pools with state and lifetime volume, enabling users to know where selling is impossible. It is distinguishable from siblings like arc_pools by name and content, though it doesn't explicitly compare to alternatives.

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

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

It explains when to use the tool (to know dead pools) and provides a clear payment flow: first call without payment for terms, then sign and call with payment. It doesn't explicitly contrast with alternative tools, but the context is sufficient for most use cases.

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 full disclosure burden and does so thoroughly: it explains the swap of half the USDC, minting of a full-range Uniswap v4 position to the caller, refund of leftovers, non-custodial nature, removal path, mode-dependent behavior, and the price-check condition. This goes well beyond a minimal description.

Agents need to know what a tool does to the 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 efficiently structured: the deposit action leads, followed by removal, then the read-mode distinction and the price warning. Every sentence earns its place, and there is no filler or restatement of the tool name.

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

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

For a single optional parameter tool with no annotations and no output schema, the description provides enough context to call it correctly: what it does, how to use it, what changes with the parameter, and when not to act. Nothing essential is missing.

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

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

Although the schema covers the optional address parameter, the description adds meaningful semantics by explaining what happens with and without it: with an address it returns positions/deposit/value; without it returns the contract, ABI, steps, and price comparison. This gives an agent actionable parameter behavior beyond the schema.

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

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

The description states a specific action, resource, and scope: putting USDC to work in the APEX/USDC pool on Arc via the ArcGrow contract. It is clearly distinguishable from sibling tools like arc_pools or arc_market because it names the exact contract method, the pool, and the non-custodial mechanism.

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

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

The description gives clear operational guidance: deposit with USDC as native value, remove liquidity via the PositionManager methods, use an address to read positions, and avoid depositing when the price divergence exceeds 10%. It does not explicitly name sibling alternatives or exclusions, but the usage context is unambiguous.

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

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

With no annotations, the description carries the full behavioral burden and does so: it discloses the pay-per-call model ($0.002 over x402 with named chains/tokens), the two-step signed-terms flow, the freshness precondition ('tokens older than about 2 days are refused before payment'), and a provenance claim ('history proven complete'). These are exactly the traits an 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?

Front-loaded with the core question ('Who holds this Arc token, and did the creator pull the liquidity?') and dense throughout, but the return-value rundown is one long comma-spliced sentence that could be tightened. Nearly every clause earns its place, so only minor trimming is warranted.

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

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

No output schema exists, so the description must describe returns and it does comprehensively (holders, pools, creator behavior, flags). It also covers the payment mechanics and freshness constraint, leaving nothing an agent needs before invoking it.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: the `payment` parameter is explained as the signed x402 payload equivalent to PAYMENT-SIGNATURE, and the description clarifies it can be omitted on the first call to retrieve terms. That workflow semantics is not derivable from the schema alone.

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

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

States a specific resource (Arc token holders) and verb-equivalent (report who holds it), then enumerates the exact payload: holder count, top 10 holders, top 10 ordinary wallets with % of supply, Uniswap v4 pool holdings, creator holdings/flow, other launches in 30 days, and flags. This is far more specific than siblings like arc_whales or arc_token_info and lets an agent distinguish it 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 a clear operating context: call once without `payment` to fetch terms, sign with your own wallet, call again with `payment`, and the precondition that tokens older than ~2 days are refused before payment. However it never names or excludes alternatives (e.g. arc_whales, arc_trust_check, arc_token_info), so the when-not-to-use-this 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?

No annotations are provided, so the description carries the burden. It discloses that the call is read-only ('no chain call'), costs $0.003, and requires a two-step payment process (call once for terms, sign, call again with payment). This is significant behavioral transparency, though it doesn't mention error handling 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 front-loaded with the core purpose, then explains the payment mechanism. It's concise but includes necessary details like pricing and the two-step call process. No redundant fluff.

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

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

Given the tool's complexity (payment flow, two-step invocation), the description covers the essential usage. It explains what the tool does, how to pay, and clarifies it's a capability check. It lacks output format details, but no output schema exists, so the agent may need to infer from context. Overall, adequate.

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

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

Schema coverage is 100%, so both parameters are already described. The description adds the payment flow context but does not add parameter-specific semantics beyond what the schema provides. Baseline of 3 is appropriate given high schema coverage.

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

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

The description states a specific verb and resource: it reads permission bits from a Uniswap v4 hook address on Arc, clarifying it determines allowed actions (runs on swaps, rewrites amounts). It distinguishes itself by noting it's a capability check, not a verdict, which differentiates from similar arc_* tools like arc_verdict.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 context on when to use it (checking hook permissions without a chain call) and explains the payment flow, but does not explicitly name alternatives or conditions when not to use it. Siblings like arc_contract_check might overlap, but no explicit routing is given.

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 execution model (an actual buy-then-sell round trip, i.e. real funds move), the $0.01 x402 cost, that 10% is recorded as owed to a People Pot ledger, and that the evidence hash is recomputable. It stops short of detailing payment failure or refund behavior.

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

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

Front-loaded with the purpose, but it is one long run-on with deeply nested parentheses (the grade legend plus the B caveat) that taxes parsing. The People Pot contract address is arguably tangential and expands the block without adding invocation value.

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

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

For a no-annotation, no-output-schema tool, it covers the essentials: what it computes, what it returns (grade, every reason, sha256 evidence hash), and what it costs. Missing only the payment-failure path and any guidance on when this depth of check is warranted versus cheaper siblings.

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

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

Schema coverage is 100%, so both parameters are already documented in the schema (including the exact meaning of the payment payload). The description adds only the cost/ledger context around the payment, so the baseline 3 applies.

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

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

States a specific verb+resource ('deep immune check for an Arc token') and enumerates the mechanism: a real buy-then-sell round trip, launch cluster, holders, creator launch history, fused into a letter grade. This distinguishes it in depth from shallower siblings like arc_token_check or arc_trust_check, though it never names them explicitly.

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

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

No when-to-use or when-not-to-use guidance is given, and no alternative is named despite ~40 sibling token-screening tools (arc_token_check, arc_trust_check, arc_antibody, arc_verdict). The cost and payment mechanics are described, but nothing routes the agent between this and its siblings.

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

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

With no annotations, the description carries the full burden and does well: it discloses that nothing is spent, that quotes come from the Uniswap v4 Quoter on the deepest USDC pool, that a hook refusal or failed read is rejected before payment, and the $0.002/x402 cost and accepted chains. It stops short of describing output shape or any rate/coverage 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?

Three sentences, all front-loaded with the core capability first and the payment mechanics later; no filler. Slightly dense with pricing/chain detail, but every clause conveys actionable 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?

Covers the gaps a 2-param, no-output-schema, no-annotation paid tool would otherwise leave: cost, read-only nature, failure handling, and the x402 handshake. It does not explicitly sketch the returned quote structure, which is a minor omission given there is no output schema.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real value over the schema by explaining the two-step `payment` protocol (fetch terms unsigned, then pass a signed payload) rather than merely restating the parameter. The `token` contract-address meaning is left entirely to the schema.

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

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

States a specific verb (quoting price impact) and resource (an Arc token), and pins the exact scope: buy and sell impact for $10/$100/$1,000 against the deepest USDC pool. An agent can distinguish this from arc_price / arc_price_at purely from the description, since it is explicitly a what-if, nothing-spent simulation with named amounts.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 operational context and an explicit invocation sequence: call once without `payment` for terms, sign with your own wallet, call again with `payment`. It does not, however, say when to prefer this over arc_price or arc_price_at, so the alternative-selection guidance is missing.

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 a good job: it discloses the $0.004 cost, the two-call x402 payment flow, the need to sign terms with your own wallet, and the important semantic rule that identity is the contract, not the symbol. It does not explicitly state read-only behavior or data freshness, but the query nature is clear.

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

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

The description is compact and front-loaded: the first sentence states the core output and identity rule, and the second sentence covers the payment mechanics. Every sentence earns its place with no fluff or repetition of schema details.

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

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

For a single-optional-parameter paid query with no output schema, the description covers the essential context: what is returned, the identity caveat, cost, currencies, and the payment handshake. It stops short of describing exact return formatting or pagination, but those are minor gaps for this tool's simplicity.

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

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

Schema coverage is 100% and the schema already describes payment as a signed x402 payload. The description adds meaningful context beyond the schema by explaining the required two-step flow: call without payment to receive terms, sign them, then call again with payment. This clarifies when the optional parameter should be present.

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

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

The description clearly identifies the resource: every token symbol on Arc shared by more than one contract, including share counts and the canonical verified address. It is specific and not a tautology, but it does not explicitly differentiate itself from the closely named sibling tool impostor_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?

The description implies when to use it (when you need a list of symbols worn by multiple contracts) and gives concrete invocation steps for the payment flow. However, it does not explicitly state when not to use it or mention alternatives such as impostor_check, leaving the agent to infer the boundary.

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 must disclose behavior fully. It covers cost ($0.99), payment chain (USDC on Arc/Base), minting and delivery to signing wallet, return of agentId and both transactions, and the no-charge guarantee. This is strong transparency for a purchase tool, though it omits failure modes and reversibility.

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

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

The description is a single, dense paragraph that front-loads the purpose and process. It is efficient with no wasted words, though it packs a lot of information that might benefit from splitting into bullet points.

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

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

The description explains the two-step process, the return value (agentId and both transactions), and the no-charge policy. However, it does not cover error handling, what happens if payment is invalid, or detailed parameter guidance. For a tool with 5 parameters and no output schema, this is a moderate gap.

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

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

Schema description coverage is only 20% (only 'payment' has a description). The description explains 'payment' semantics and the two-step flow, but does not provide guidance for the required 'name' and 'description' parameters or optional 'image' and 'services'. Given low coverage, the description should compensate but does not.

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

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

The description clearly states the action (buy ERC-8004 identity) with a specific method (signature alone) and distinguishes it from sibling tools like arc_passport_draft and arc_passport_status by focusing on the purchase and completion flow. It leaves no ambiguity about the tool's primary 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?

Provides explicit step-by-step usage: call without 'payment' to get terms, sign them, call again with 'payment'. Also notes that refused inputs are never charged, which helps the agent decide when to invoke. Does not explicitly compare to alternatives, but the usage is clear.

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

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

With no annotations, the description carries the disclosure burden and does well: it explains the legacy-flow ordering dependency, the deadline, and the split from the buy path. It omits what happens on success/failure, whether the call is idempotent, and any gas/permission notes, so it falls short of full behavioral 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, front-loaded with the primary action and precondition, and the alternative path is a trailing qualifier rather than clutter. Every clause earns its place.

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

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

For a two-parameter completion call with no output schema and no annotations, the description supplies the flow context, deadline, and routing alternative an agent needs. It stops short of describing return values or error/deadline behavior, which the absence of an output schema leaves unaddressed.

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

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

Schema coverage is 100% and both parameters are documented in the schema itself, including that tx is the register() hash and slug is the 12-character draft id. The description restates 'draft slug' and 'transaction hash' but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (finish) and resource (passport started in the old flow) and names the sibling it is not (arc_passport_buy for new passports). An agent can distinguish it from arc_passport_draft and arc_passport_buy 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 an explicit precondition ('after the register() transaction from the old flow'), a cutoff date ('before 1 Oct 2026'), and a named alternative with a price for the other path ('New passports are bought with arc_passport_buy ($0.99)'). When-to-use and when-not-to-use are both covered.

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. It discloses the critical behavioral fact that the tool is retired and returns a static response rather than performing any passport creation. It does not explain why the schema still requires name and description, which is a meaningful gap for a schema that looks like a creation tool.

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

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

A single dense sentence with the retirement notice front-loaded. Every clause earns its place (status, cost, human path, agent path, current behavior), though the sentence is packed.

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

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

It explains the tool's dead-end behavior and points to alternatives, which is enough to avoid misuse. However, it leaves unexplained why a retired tool still declares two required parameters, and there is no output schema to clarify what the canned answer looks like.

Complex tools with many parameters or behaviors need more documentation. 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 every parameter documented inline, so the baseline is 3. The description adds no parameter meaning and does not reconcile the mismatch between the required name/description fields and the tool's stated no-op 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 the tool's status (RETIRED) and its current operation precisely: it returns a single canned answer about Arc Agent Passport pricing. This clearly distinguishes it from arc_passport_buy, which the description names as the actual purchase path.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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: humans pay at the given URL, agents use arc_passport_buy, and this tool only returns that answer. An agent knows exactly when to use it (never, for purchasing) and which sibling to call instead.

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 must carry the behavioral burden. 'Look up' implies a read operation and 'Free' discloses cost behavior, which is useful. But it does not explicitly state that no mutation occurs, nor does it mention auth requirements, rate limits, or failure behavior.

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

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

One compact sentence that front-loads the action and resource, uses a colon to introduce the output fields, and ends with the cost qualifier 'Free'. Every clause earns its place; there is no redundancy or filler.

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

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

For a single-parameter lookup with no output schema, the description adequately captures the accepted input, the returned data categories, and cost. Minor gaps remain around error responses and invalid-ref behavior, but they are not critical for an agent to select and invoke the tool.

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

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

The input schema already fully documents the single parameter, including the agentId-as-number and 12-character slug alternatives. The description only restates 'by agentId or draft slug' without adding new format or usage nuance, so it provides no meaningful semantic value beyond the schema.

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

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

States a specific action ('Look up an Arc Agent Passport'), the resource, and the accepted reference formats. The colon-separated list of returned fields makes the tool's scope concrete and distinguishes it from transaction-oriented siblings like arc_passport_buy or arc_passport_draft.

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

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

The description clearly implies the use case: retrieve passport status by ref. However, it does not explicitly say when to prefer this over alternatives such as arc_agent_status or arc_passport_draft, nor does it mention exclusions or prerequisites.

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 burden. It discloses the cost ($0.003 per call), the payment mechanism (x402), and the two-step process. It also states what it checks and that it compares against expectations, making the behavior transparent.

Agents need to know what a tool does to the 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 block but well-structured: it starts with the purpose question, lists checks, then cost and usage. No fluff, each sentence contributes to understanding the tool.

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

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

Given the complexity of a two-step payment flow and no output schema, the description is remarkably complete. It explains the purpose, the checks, the cost, and the exact call sequence. An agent can correctly invoke this tool without additional context.

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

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

Schema coverage is 100%, so baseline is 3. The description adds workflow context, explaining that `payment` is a signed x402 payload that completes the purchase inside the call, and clarifies `expect` as expected amount in USDC. This goes beyond the schema's basic descriptions.

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

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

The description opens with a clear question that defines the tool's purpose: verifying whether an Arc payment landed. It enumerates specific checks (payer, recipient, amount in both transfer forms, confirmation, gas) against expectations, distinguishing it from other arc_* tools like arc_contract_check or arc_fee_flow.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 usage instructions: call once without `payment` for terms, sign with wallet, call again with `payment`. It implies this is for verifying payments and contrasts with other tools by focusing on payment confirmation. It doesn't name alternatives but the context is clear.

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

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

No annotations are present, so the description carries the full burden. It discloses the data source (PoolManager events), the refresh interval (five minutes), the cost (free), and the exact output fields (first buyer, seconds, sold straight back, USDC depth, flags, leaderboard). This is thorough behavioral disclosure.

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

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

The description is dense but front-loaded with the title and a comma-separated list of outputs. It is efficient: each clause adds distinct information, and the data source/frequency sentence is short.

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

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

The description enumerates all return fields despite lacking an output schema, and it states the update frequency and cost. Nothing critical is missing for a zero-input monitoring tool.

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

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

The tool has zero parameters, so the description has nothing to explain. Baseline 4 applies.

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

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

The description clearly states the tool's purpose: monitoring new Uniswap v4 pools on Arc, including first buyer details and metrics. It specifically mentions the resource (pools on Arc) and the action (watch), distinguishing it from generic pool tools.

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

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

The description provides clear context: it is for pools created in the last 24 hours and updates every five minutes. However, it does not explicitly compare to sibling tools or state when not to use it.

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

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: data source, pool-selection policy, quoted cost ($0.001/call), accepted payment assets and chains, refusal semantics before payment, and the returned warning signals (hook, thin). An agent knows the price, the safety characteristics of the read, and the negotiation flow.

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

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

Four dense sentences, front-loaded with purpose then returns then payment mechanics; every clause carries information. The long final payment sentence is justified by a non-obvious protocol but is the one place a reader has to work.

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

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

No output schema exists, but the description enumerates the return fields (usdPrice, pool, liquidityUsdEstimate, block, warnings), and covers cost, payment, and failure modes. The only meaningful gap is disambiguation from arc_price_at for time-scoped pricing.

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

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

Schema coverage is 100%, so baseline is 3; the description exceeds that by explaining the two-step payment handshake that gives `payment` meaning across calls (fetch terms, sign, resubmit) and by tying the returned 'pool used' to the `token` input's pool universe.

Input schemas describe structure but not intent. Descriptions should explain 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 ('USD price of any Arc token: read live from the Uniswap v4 pool state across its USDC pools') and even names the selection heuristic (deepest hookless pool). It does not, however, differentiate itself from the obvious sibling arc_price_at, so the agent must infer that 'live' means spot versus historical.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 invocation protocol for x402: call once without `payment` for terms, sign with your own wallet, call again with payment. It also states the failure path (no USDC pool or failed read is refused before payment). What is missing is when to prefer this over arc_price_at or other pricing siblings.

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

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

With no annotations, the description carries the full burden and does so: it discloses the pricing source and block-pinning rule, the batch cap, refusal-without-charge semantics for unpriceable batches, cost ($0.003/call), accepted payment rails (USDC on Arc/Base/Solana, XNT on X1), and the exact two-call authorization handshake (call without `payment` for terms, sign, call again).

Agents need to know what a tool does to the 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 capability and scope, and every sentence carries load (use cases, refusal rule, price, payment flow). The telegraphic 'Not one priceable pair = refused before payment' and crammed payment rails cost a little readability, but there is no filler.

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

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

Covers what the tool does, when to use it, cost, and the payment protocol end-to-end for a paid historical-data tool with no output schema. It stops short of describing the shape of returned price records or per-pair partial-failure behavior within a batch.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning: it explains the batch/50-pair semantics of `q` and, crucially, the stateful usage of `payment` (first call omits it to obtain terms, second call carries the signed payload, purchase completes inline).

Input schemas describe structure but not intent. Descriptions should explain 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: historical token prices on Arc at a given block, batched up to 50 token@block pairs, sourced from the deepest Uniswap v4 USDC pool at that block. This distinguishes it clearly from siblings like arc_price (current), candles, and crypto_price.

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

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

Gives explicit use cases ('For history values, P&L, tax exports') and an important pre-condition ('Not one priceable pair = refused before payment'), plus the two-step payment flow. It does not name a sibling alternative (e.g. spot price via arc_price) for the non-historical case, so routing is inferred rather than spelled out.

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 behavioral burden. It discloses what is measured, that measurements were taken 'this minute from our server,' and even notes the official RPC's throttling quirk. It does not state the output format explicitly, but as a zero-parameter read-only status tool, the disclosed behavior is largely sufficient.

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

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

Three short sentences pack the core purpose, data points, measurement window, and a practical use case with no wasted words. The front-loaded question-style opening immediately signals what the tool does.

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

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

For a zero-parameter status tool with no output schema, the description is complete: it states what is reported, how current the data is, where it is measured from, and why an agent would call it. Nothing essential is missing for selecting and invoking the tool.

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

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

The tool has zero parameters and the schema coverage is 100%, so there is no hidden input meaning to document. The description still adds value by explaining what the result conveys: latest block, lag, and response time.

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

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

The description clearly identifies the resource (Arc RPC endpoints) and the action (report which one is answering and how fast, including latest block, lag, and response time). It distinguishes itself from sibling status tools like arc_agent_status or arc_faucet_status by focusing specifically on RPC performance rather than agents, faucets, or wallets.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 concrete use case: when Arc's official RPC throttles with a bug-like error, use this tool to pick another endpoint. It provides clear context but does not name explicit alternative tools or state when not to use it, though no sibling appears to cover RPC status.

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 pricing ($0.005/call), payment chains accepted (USDC on Arc/Base/Solana, XNT on X1), the x402 auth requirement, and that concentrated/shared-payout cases are flagged. It lacks detail on rate limits or failure modes, but covers the key behavioral traits.

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

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

Dense but front-loaded: the ranking thesis leads, followed by what is returned, flags, and payment mechanics. Every sentence earns its place, though the payment-chain list and workflow sentence are packed tightly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 usefully enumerates the returned signals (payers, payments, USDC, concentration, liveness). Combined with pricing and the payment workflow, an agent has enough to call it correctly; only ranking order ties and error handling are unspecified.

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

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

Schema coverage is 100% and the single `payment` param is documented, so baseline is 3. The description adds genuine value beyond the schema by explaining the two-step x402 flow (fetch terms unsigned, then re-call with the signed payload), which the schema alone does not convey.

Input schemas describe structure but not intent. Descriptions should explain 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 — ranking Arc agents by distinct OUTSIDE payers read from settlements — and immediately differentiates itself from reputation/market siblings via 'Track record, not price.' An agent can tell what this produces 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 clear invocation workflow (call once without `payment` for terms, sign, call again with `payment`), but no explicit when-to-use or when-not-to-use versus siblings like arc_agent_reputation or arc_trust_check. Usage is implied by the ranking semantics 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?

With zero annotations, the description carries the full burden and does well: it discloses the verdict vocabulary (stop/check/ok), the fail-closed semantics ('a failed read is refused before payment'), the x402 pricing and accepted chains, and the two-step auth/terms flow. It stops short of describing output structure beyond the verdict labels or any rate/retry behavior.

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

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

Front-loaded with purpose, then the check list, then pricing and the call flow. Dense but each clause carries signal; the long enumeration of checks is justified because it tells the agent what the verdict means. Slightly list-heavy but no filler sentences.

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

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

For a no-annotation, no-output-schema tool this is close to sufficient: the verdict semantics, failure behavior, cost model and invocation sequence are all covered. Remaining gaps are the exact response shape and error/refund behavior on a partially completed x402 purchase.

Complex tools with many parameters or behaviors need more documentation. 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 goes further by explaining payment semantics that the schema only hints at ('the base64 payload you would put in PAYMENT-SIGNATURE') and the sequencing needed to obtain it. It adds little about `from`/`to`/`token` beyond the schema.

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

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

The description names a specific verb+resource ('Send guard for Arc: call before sending USDC or a token') and enumerates the exact checks performed, from address poisoning to OFAC/USDC blacklist to fake stablecoins. This clearly separates it from adjacent safety siblings like arc_trust_check, arc_verdict and arc_payment_check without opening their schemas.

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

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

It states the trigger condition explicitly ('call before sending USDC or a token') and prescribes the flow order with 'call once without payment for the terms, sign them, call again with payment.' What's absent is an explicit contrast against the other safety-lookup siblings (arc_trust_check, arc_payment_check), so the agent must infer which guard to run.

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 substantial work: it discloses pricing ($0.01/call), accepted payment rails (USDC on Arc/Base/Solana, XNT on X1), the exact output payload (wallet record, simulated sell check, staged entry/exit plan with quarter-Kelly cap), and a 'not advice' disclaimer. It omits rate limits, timeout/refund behavior, and what happens if payment is invalid.

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

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

Purpose and signal definition are front-loaded in a dense first sentence, followed by output contents and the payment flow. It is wordy and packs many clauses into one sentence, but each sentence conveys actionable information (criteria, outputs, cost, handshake) 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 1-param tool with no annotations and no output schema, the description is nearly self-sufficient: it defines the signal, enumerates the returned artifacts, states cost and payment rails, and gives the two-step paid-call procedure. Minor gaps remain around error/refund handling and rate limits, but nothing critical for a 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?

Only one parameter and schema description coverage is 100%, so the schema already fully documents `payment` including that it is a base64 x402 payload passed as PAYMENT-SIGNATURE. The description corroborates the two-call flow but adds no format detail beyond the schema, so baseline 3 applies.

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

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

Names a specific resource (smart-money signals on Arc) and gives precise scope: the 25 most profitable wallets of the last 24h, with concrete trigger thresholds (3+ buys or $150+ in 60 min; 2+ wallets together) and an EXITED exit condition. This clearly distinguishes it from siblings like arc_dip_signals, arc_whale_feed, and arc_exit_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 invocation flow for the paid handshake: call once without `payment` for terms, sign with your own wallet, then call again with `payment`. It does not, however, say when to prefer this tool over adjacent signal tools (e.g. arc_dip_signals or arc_whale_feed), so the routing guidance is incomplete.

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 burden of behavioral disclosure. It explicitly states this is a read operation ('read from the contracts') and notes it is free, which is useful cost/risk context. It also names the exact data being read, giving the agent a clear picture of what the call will do.

Agents need to know what a tool does to the 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 sentence that front-loads the core question, then specifies the exact data returned and the cost. Every phrase earns its place, and there is no filler or repetition of structured fields.

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

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

For a parameterless read tool, the description is complete: it states the source (contracts), the data items returned, and the cost. An agent can invoke it without needing additional context about inputs, side effects, or return structure.

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

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

The tool has zero parameters and schema description coverage is 100%, so there is no parameter ambiguity. The description still adds value by enumerating what the response will contain, which partially compensates for the lack of an output 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 identifies the resource (stablecoins on Arc) and the specific data points returned: USDC and EURC total supply, addresses, and EIP-712 signing domains. It does not explicitly contrast itself with sibling tools, but the scope is concrete enough to understand what the tool does.

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

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

The description gives no guidance on when to use this tool versus alternatives, and there is no mention of exclusions or related tools. While 'right now' implies current on-chain state, that is not enough to help an agent choose it among the many Arc-related siblings.

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

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

With no annotations, the description carries the full burden. It does add useful behavior beyond the schema: the price ($0.002 per call over x402), the fact the safety score comes from a 'real round trip' (simulated execution), and the specific owner capabilities checked. However it does not disclose failure modes, what happens without a valid payment, or rate/pagination behavior.

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

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

A single dense sentence that front-loads the core promise ('Everything about an Arc token in one call') and then the specifics; cost is placed last where it belongs. Slightly run-on due to stacked parentheticals, but no wasted sentences.

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

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

No output schema exists, and the description compensates by enumerating the return content (safety score, pool fee, hook, owner privileges), plus pricing. What is missing is a mention of the x402 payment workflow failure path, but for a 2-parameter read tool this 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 description coverage is 100%, so both parameters are already documented, and the baseline is 3. The description marginally enriches 'payment' by tying it to the x402 price model, but adds no format or syntax detail for 'token' beyond what the schema provides.

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

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

States a specific verb and resource ('Everything about an Arc token in one call') and enumerates the concrete outputs — sellability score, pool fee, hook, and owner powers (mint, pause, blacklist, upgrade). That is a real description of what the tool does, though it never names the nearby siblings (arc_token_info, arc_trust_check, arc_contract_check) it could be confused with.

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

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

The framing 'can you sell it' implies a pre-trade safety check, which gives an agent implied usage, but there is no explicit when-to-use, when-not-to-use, or pointer to an alternative sibling. The agent must infer the scenario from the phrasing alone.

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 $0.002 per-call cost, accepted payment assets and chains, the pre-payment refusal of invalid inputs, the two-call payment handshake, and the guarantee that launch data comes from a real index and is 'never guessed'. This is unusually rich behavioral disclosure.

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

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

Front-loaded with the purpose ('Token info... before showing it') and the payment mechanics, with no filler sentences. The field enumeration is dense and long, but each item maps to an actual return value, so it earns its place.

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

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

No output schema exists, so the description must describe return values — and it does, listing the exact fields an agent receives. Combined with the payment flow, pricing, and refusal behavior, nothing needed to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the prose adds real meaning to `payment`: it explains that the value is a signed x402 payload placed in PAYMENT-SIGNATURE and that passing it completes the purchase inside the call. The `token` parameter is only mirrored, not enriched, so not a 5.

Input schemas describe structure but not intent. Descriptions should explain 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 ('Token info for an Arc token') and enumerates the exact data returned — metadata, provenance via a launch index, pool price/liquidity, and risk signals. An agent can distinguish it from siblings like arc_price or arc_pools because it bundles token metadata with launch provenance and risk in one call.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 operational context: use it 'before showing' a token, wallet/non-token inputs are refused before payment, and the exact two-step x402 flow (call without payment to get terms, sign, call again with payment). It does not explicitly compare against alternatives like arc_touchstone or arc_verdict, 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?

With no annotations, the description carries the full burden. It usefully discloses that an assay is a reverted real buy-and-sell, the emitting contract address, and the event payload (verdict, round-trip cost, streak), but it never states this tool's own read-only safety profile, permissions, or pagination/return shape.

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

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

The first two sentences are dense and front-loaded with the definition, but the third sentence pivots to how to *create* an assay via a direct contract call, which is tangential to a read tool and adds routing noise rather than value for invoking 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?

No output schema and no annotations exist, so the description should fully cover return behavior and safety. It explains the assay's conceptual outputs but does not describe what this read tool actually returns or how results are shaped, leaving a gap for an agent to close on its own.

Complex tools with many parameters or behaviors need more documentation. 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 there is only one optional param, so the baseline is 3. The description adds genuine meaning beyond the schema: omitting 'token' returns every pool's last assay, while supplying it scopes to one token's assay.

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

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

The description gives a specific verb+resource (read every pool's last assay and streak, or one token's) and defines what an assay is, so an agent understands the purpose without opening the schema. It does not, however, explicitly differentiate this from nearby siblings such as arc_verdict or arc_trust_check, which is what would be needed for a 5.

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

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

It implies usage by stating the two modes ('read every pool's last assay' vs 'one token's'), but never says when to choose this over alternatives like arc_verdict or arc_contract_read. The 'to make one' sentence describes a contract call rather than routing guidance for this tool.

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 cost ($0.002/call), the accepted payment currencies, and the exact multi-call payment protocol. It omits failure/retry behavior if a signed payment is rejected and any rate limits or data-freshness caveats, but the essential behavioral envelope is covered.

Agents need to know what a tool does to the 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 returned data before the payment mechanics, and every sentence earns its place. The enumerated data list is long but is the core of what the tool provides; minor trimming possible without real loss.

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

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

No output schema and no annotations, so the description must cover purpose, cost model, and payment protocol, which it does. For a paid two-param data-retrieval tool, what an agent needs to call it correctly is present; return-value structure is described in prose rather than schema.

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

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

Schema description coverage is 100%, so baseline 3 applies for the fields themselves. The description adds meaning beyond the schema by clarifying the payment param's role in the two-call purchase sequence ("Pass it and the purchase completes inside this tool call"), which the schema text alone does not fully convey.

Input schemas describe structure but not intent. Descriptions should explain 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 set (trade history + net USDC flow) with resource (Arc token), scope (last 24 h), and an explicit breakdown of returned data: buys/sells, distinct buyers/sellers per 1h/6h/24h, latest 30 trades, and per-pool swap counts. This is clearly distinguishable from siblings like arc_holders, arc_price, and arc_whale_feed.

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

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

Explicitly explains the two-step x402 flow: call once without `payment` to get terms, sign with your own wallet, then call again with `payment`. This is concrete operational guidance. It lacks guidance on when to prefer this over sibling tools such as arc_whale_feed or arc_holders, hence not 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?

With no annotations the description carries the full burden and does well: it discloses the sell-test filter, that launch-and-pull pools are excluded, the ranking methodology (inflow not volume), the $0.001 cost, the two-call payment flow, and the ad-free 'facts, never advice' stance. It omits rate limits or caching behavior, keeping it below 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?

Dense but front-loaded: the trending definition and ranking rule come first, followed by exclusions and then the payment mechanics. Every sentence carries substance, though the run-on style is somewhat heavy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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, no-annotation, no-output-schema tool, the description covers everything needed: what is returned (volume, buys/sells, price change, pool age), filtering rules, cost, and the exact payment procedure. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning by explaining the payment parameter's workflow: call once without payment for terms, sign with your own wallet, then pass the signed payload to complete the purchase.

Input schemas describe structure but not intent. Descriptions should explain 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 ('What is trending on Arc right now: tokens ranked by NET USDC inflow') and pins down scope (last hour and 24h, every Uniswap v4 pool). An agent can distinguish it from siblings like arc_fresh_launches, arc_price or arc_whale_feed 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?

The description makes usage conditions implicit (it is a read-only market snapshot, no input) and gives explicit mechanics for the x402 payment handshake, but never states when to prefer it over alternatives such as arc_fresh_launches or arc_trades. Usage is implied by the topic rather than by comparison.

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, so the description carries the full behavioral burden and does so well: it discloses pricing ($0.003/call over x402), accepted assets/chains (USDC on Arc/Base/Solana, XNT on X1), and the exact two-call auth flow (fetch terms without payment, self-sign, re-call with payment). It omits failure/error behavior and rate/limit characteristics, but the core cost and settlement mechanics are transparent.

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

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

Purpose is front-loaded and every clause maps to something an agent needs (what is measured, what to pass, cost, payment flow). The measurement list is dense and comma-heavy, making it slightly hard to parse, but there is little genuine filler for a tool of this 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 complex, paid, no-annotation, no-output-schema tool, the description is nearly sufficient: it names the measured outputs, the price, the asset/chain options, and the full payment handshake. It lacks any statement about failure modes or what a non-delivering verdict looks like, which is the main remaining gap.

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

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

Schema coverage is 100% and the single payment parameter is well documented in the schema, so baseline is 3. The description pushes past that by explaining the parameter's role in the staged flow (first call returns terms, second call with the signed payment completes the purchase) and what payload to use. It also references 'agent, address or url' inputs that are not present in the schema, a minor ambiguity.

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

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

States a specific verb+resource (vet an Arc agent's actual delivery) and enumerates the concrete dimensions it measures: responsiveness now and over 7 days, response time, payment functioning, settled paid calls, and on-chain payer concentration. An agent can tell this apart from arc_agent_reputation and arc_payment_check by the empirical 'measured, not claimed' scope. It does not, however, explicitly name those siblings to sharpen the boundary.

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

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

Opens with a clear usage trigger ('Before paying an Arc agent') and gives an operational context, plus the required two-step purchase flow. It gives no explicit when-not-to-use or named alternative, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that per-wallet estimates are paid calls ($0.003 via x402 or card pass) and adds a notable conflict-of-interest disclosure ('We hold UBI and say so'). However, it does not state that the tool is read-only, has no side effects, or describe rate limits or authentication, leaving important behavioral traits implicit.

Agents need to know what a tool does to the 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 dense, run-on sentence with nested parentheticals and multiple topics (free data fields, paid call, website parity, holding disclosure). It front-loads the data fields but could be broken into clearer sentences. Some elements, such as the website-parity note, are terse, while the overall length is not excessive for the amount of 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?

There is no output schema, so the description must explain return values; it does by listing key data points (USDC waiting, payout list validity, USDC per 1M UBI, recent payouts). It also covers the paid per-wallet estimate path and a conflict-of-interest note. It omits what happens when address is omitted, but that behavior is strongly implied.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaningful detail beyond the schema: the optional address parameter triggers a paid call at a specific URL, costs $0.003 via x402 or card pass, and returns the same numbers as the public website. This is useful semantic enrichment for the single optional parameter.

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

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

The description clearly identifies the resource: UBI holder payout data on Arc, listing specific fields (USDC waiting, next valid payout list, USDC per 1M UBI, recent payouts). It does not name a sibling for differentiation, but the tool is unique among the large sibling set. The purpose is clear, though it lacks a direct verb like 'get' or '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?

It distinguishes the free aggregate data this tool provides from the per-wallet payout estimate, which it explicitly marks as a separate paid call with URL and price. This gives clear context for when to use this tool versus the paid alternative. No explicit when-not-to-use condition or sibling tool is named, but the paid-call boundary is useful.

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, so the description carries the load. It does disclose the pricing model ($0.002/call), the two-step x402 payment flow, the 10-minute sell-probe staleness, and that all inputs are shown. It doesn't state latency, rate limits, or what happens on a missing/failed payment beyond re-calling, leaving some gaps for an unannotated composite tool.

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

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

Front-loads the value proposition in caps, then inputs, then alternatives, then payment terms. Slightly dense but each sentence carries information. Efficient for a tool with a nontrivial payment model.

Shorter descriptions cost fewer tokens and are easier for agents to parse. 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 unannotated 3-param composite tool with no output schema, it covers purpose, inputs, alternatives, and the full payment workflow, which is the critical missing context. Gaps are minor: no return-value shape detail and no failure semantics.

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

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

Schema coverage is 100%, so the schema already documents pool/token/payment and the 'pass this or that' exclusivity. The description reinforces the payment flow (call once without payment, sign, call again) but adds no syntax 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?

States a specific action: returns one 0-100 buy score plus an ok/caution/avoid verdict for an Arc pool, and lists the five inputs it aggregates. It doesn't explicitly differentiate from sibling risk tools like arc_trust_check or arc_hook_risk, but the composite 'buy score' framing is distinctive enough.

Agents choose between tools based on descriptions. A clear purpose with a specific verb 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 redirects to arc_exit_check for selling at your own size or testing liquidity pull, which is a clear alternative. The re-run-when-stale and 'avoid only with evidence' guidance helps. No explicit when-not-to-use, but a clear enough 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 provided, the description carries the full burden. It explicitly states 'Read live from the chain' (indicating real-time data and read-only behavior) and discloses a rate limit ('Free, 200 calls a day'). These are important behavioral details not inferable from the name or schema. It also says 'Everything public', clarifying it does not return private data. This goes beyond a simple 'get info' and provides useful operational context.

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

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

The description is front-loaded with the core value proposition ('Everything public about one Arc address in one call') and follows with a concise list of what is included. Every sentence provides information: the data types, the live read behavior, and the rate limit. There is no wasted wording or redundancy. It is visually structured with a colon and list, making it easy for an agent to parse.

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

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

The description is comprehensive for a single-parameter tool with no output schema. It enumerates the types of data returned (USDC/EURC/APEX balances, contract status, ERC-8004 identities, x402 selling), which gives an agent a clear picture of the output's scope. It also mentions live-read and rate limits, rounding out the operational context. It doesn't specify the exact return structure, but since there is no output schema and the data types are listed, this is sufficient for an agent to infer the shape. One minor gap is that it doesn't mention whether the tool returns zero values or handles errors, but this is not critical for a read-only overview.

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

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

The schema fully describes the single parameter 'address' as '0x address on Arc', so schema coverage is 100%. The description adds no new meaning beyond the schema—it merely refers to 'one Arc address' without providing additional format, validation, or example. Since the schema already covers the parameter semantics, a baseline score of 3 is appropriate.

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

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

The description clearly states a specific verb ('get') with a resource ('everything public about one Arc address') and enumerates the specific data returned (USDC, EURC, APEX balances, contract status, ERC-8004 agents, x402 selling). It distinguishes itself from sibling tools like arc_contract_check (which focuses solely on contract status) and arc_agent_status (agent-specific) because it is a comprehensive single-call overview. The phrase 'in one call' also sets it apart from tools that might require multiple lookups.

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

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

The description implies usage as a one-stop-shop for address information ('Everything public about one Arc address in one call') but does not explicitly state when to prefer it over alternatives, nor does it mention when not to use it (e.g., if only contract status is needed, arc_contract_check might be more direct). There is no mention of alternative tools or exclusions, so usage guidance is implied rather than explicit.

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

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: read-only history, dedup rule for USDC via native logs, NFT listing, impostor/poisoning flagging, 'A failed read is refused before payment,' and $0.003 cost. This is behavioral context beyond any structured field.

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