arcgate

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

With no annotations, the description carries the burden and does well: it declares the cost model (free, never x402-gated) and enumerates what the diagnostics include (DB import health, rule set version, commit, counters, payer-identity mode). It stops short of describing failure/error behavior when the service is down, which is the one remaining transparency gap.

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

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

Front-loaded one-line purpose followed by tightly scoped Cost/Returns/Next bullets. Every line earns its place with no filler.

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

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

For a no-param, no-output-schema probe, the description covers the return contents and the recommended call timing, which is everything an agent needs to invoke it correctly.

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

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

Zero parameters, so the baseline is 4. There is nothing for the description to clarify beyond what the empty schema already conveys.

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: reports whether the service is up and returns its diagnostics. Clearly distinguishable from the trade* siblings, which are all action-oriented trading 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?

Explicitly states when to call it ('call before search/quote/swap to check the service is up'), giving the agent a concrete pre-flight trigger. No exclusions needed for a health probe.

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: cost model (free, never x402-gated), error codes and their triggers (404 swap_not_found, 400 invalid_request), rate limits (one read per quote every 5s, 132 per quote then permanent 429), and finality semantics ('the first result from a mined swap is final'). This is far beyond anything a schema or annotation would convey.

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

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

Bold headers (Cost, Key inputs, Returns, Limits, Next) front-load the critical routing info, and most sentences are information-dense. It is long and occasionally dense enough that a few clauses could be tightened, but the detail is largely warranted for the tool's complexity.

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

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

For a 2-param tool with no annotations, no output schema, and no param descriptions, the description supplies everything needed: return-value semantics (pass/fail/pending, delivered, block, status, reason), failure reasons, rate limits, and post-result actions. Nothing an agent needs to call or interpret it correctly appears 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 0%, so the description must compensate, and it does: quoteId is identified as the one passed to POST /trade/v1/swap, and txHashes as the 1-to-4 transactions sent (the swap plus any approvals). It also explains the validation scope tied to each parameter, adding real meaning the bare schema cannot.

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

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

Starts with a specific verb+resource statement: it tells you whether the transactions that POST /trade/v1/swap returned did what the quote promised, and clarifies 'It only reads the chain.' This cleanly separates it from the mutating siblings (tradeSwap, tradeSwapTx), so an agent can distinguish it 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?

Explicit about when to call it ('once you've sent them'), when it does not apply (smart-contract wallets sending from an executor/bundler instead get 400 invalid_request, with a redirect to checking the transaction's own receipt), and what to do next based on result (requote/stop/pending). Alternatives and exclusions are named, not implied.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses the x402 payment flow (402 with PAYMENT-REQUIRED header, retry with PAYMENT-SIGNATURE), the exact cost, where payment goes in `params._meta`, and that results are ordered by relevance. It omits error/no-match behavior and 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?

Front-loaded with purpose and structured in labelled bullets (Cost, Key inputs, Returns, Next) that scan well. Slightly overlong: the 0.005 USDC cost is stated twice in different units, adding mild 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 and no annotations, so the description must stand alone; it summarizes return contents (verification status, safety verdicts, pools) and the downstream handoff. It leaves out failure modes and whether results are paginated, which is a modest 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 0%, so the description must compensate, and it does: it marks `query` as required, specifies `limit` range 1-25 and default 10, and — most valuably — expands the semantic space of `query` to ticker, name, prefix or 0x address, which the bare string schema 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?

The first sentence gives a precise verb (resolves) and resource (ERC-20 tokens on Arc) plus the accepted input forms (ticker, name, prefix, 0x address). It is clearly distinguishable from tradeQuote/tradeSwap siblings, though it never explicitly says how it differs from other search-like 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 states the enabling context (resolve a token before trading) and the explicit next step: pass the chosen result's `address` as `sell` or `buy` to POST /trade/v1/quote. No when-not-to-use guidance is given, which holds it below 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 entire behavioral burden and does so thoroughly: fee tiers and x402 payment handshake, quote TTL/default/max, 409/410/422/429/400/404 error semantics, attempt reservation rules, and the fact that 200 responses require downstream signing/sending. This is well beyond what structured fields supply.

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

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

The opening sentence is front-loaded and bold section headers aid scanning, but the fee block is duplicated almost verbatim in the opening and the closing 'Next:' paragraph, and the Permit2 bullet is a dense wall of text. For a tool this complex some length is warranted, yet the redundancy costs 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?

With no annotations and no output schema, the description is the sole source of truth and covers return shape (`transactions`, `signatures`), next-step guidance (`sign_permit`, `requote`, `stop`), and failure modes. Nothing an agent needs to call this correctly appears to be missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for most inputs: `quoteId` origin (POST /trade/v1/quote), `recipient` defaulting to `taker`, and the `approval` enum's two modes are each explained with concrete behavior. `deadlineSec` is listed as optional but its meaning and the schema's 10-600 bounds are never elaborated, leaving one 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 first sentence states a specific verb and resource ('Turns a stored quote into unsigned transactions for the taker to sign and send') and immediately distinguishes the tool's role from siblings by noting arcgate never signs, broadcasts or holds funds. An agent can tell this apart from tradeQuote and tradeSwapTx 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?

Explicitly routes to POST /trade/v1/swap/tx when a permit must be signed, explains the `approval: "approve"` alternative path, and describes fallback, retry and requote conditions in detail. When-not-use cases (never send `permit` here) and the 5-attempt limit are also stated, leaving little to inference.

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

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

With no annotations the description carries the full burden and delivers: cost model (free, x402 header ignored), single-use reachability, the 409/422/429 error taxonomy with retry accounting (5 failed attempts, next: requote), signature-validation rules (ERC-1271, nonce/deadline checks), and the receipt caveat for Safe/4337/7702 takers. This is well beyond what any structured field provides.

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 bolded bullet headers make it scannable, and virtually every sentence carries operational content. It is dense and long, with some restatement (free/x402 repeated across cost and freshness notes), so not a perfect 5, but nothing is filler.

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

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

For a 5-param nested-Object tool with 0% schema descriptions and no output schema, the description covers inputs, error semantics, attempt limits, freshness behavior and the downstream confirmation step. An agent has everything needed to invoke it correctly and interpret failures.

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

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

Schema description coverage is 0%, so the description must compensate and does: it maps quoteId/taker/recipient to the paid call, gives recipient's default, names deadlineSec, and spells out the permit object shape (only message+signature allowed end-to-end, extra fields 400) plus which fields are validated and how. No parameter is left to guesswork.

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

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

Opens with a specific verb+resource+scope: it is the free Permit2 second round that finishes a POST /trade/v1/swap call whose signatures requested a PermitSingle. This cleanly distinguishes it from the sibling tradeSwap (the paid first round) without needing to open 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?

States the exact precondition ('only reachable once, right after the paid call that opened it'), names the alternative to call when no pending round exists (POST /trade/v1/swap), and closes by placing it in the pipeline 'search -> quote -> swap -> swap/tx'. When/when-not/alternatives are all 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 disclose cost behavior ('free, never x402-gated') plus the return shape (`executable` flag, hubs, launchpads). It omits pagination, auth, and error behavior, but for a read-only listing the disclosure is solid.

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 purpose followed by three tight bullets (cost, returns, next step). Every line carries distinct information with zero padding.

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

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

No annotations and no output schema, so the description must explain returns and cost — which it does, including the key `executable` flag and the hand-off to the quote tool. Minor gaps (auth, pagination, error cases) keep it from 5.

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

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

Zero parameters with 100% schema coverage; there is nothing to document, so the baseline 4 applies. The description adds no parameter-level detail, which is correct 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?

Specific verb (Lists) and resource (DEX venues, hub tokens, launchpads) scoped to 'this deployment indexes'. An agent can tell it apart from quote/swap siblings functionally, though no sibling is named 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?

The 'Next' line gives concrete downstream usage: feed venue ids into POST /trade/v1/quote's `venues`/`excludeVenues`. No explicit when-not-to-use or named alternative, so it stops short of 5.

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