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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and non-destructive, so safety is covered. The description adds real value beyond that by disclosing null/absence semantics: router is null with a reason, unknown tokens yield data:null, and unreadable indexes yield live:false with outcome compute_unknown. That is substantive failure-mode context, though some terms remain unexplained.

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 long, dense sentences that front-load return-field jargon before establishing the action. The null-handling details are useful but the first sentence crams compute_og, pool, ladder tier, and basis sentence without defining them. Wasteful in style, not 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?

With no output schema, the description does attempt to describe the return shape (compute_og, pool, ladder tier, basis sentence, router) and its null states, which is the right burden to pick up. But the field explanations lean on undefined internal terms, leaving an agent unsure what the values actually mean or how to interpret them.

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

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

There is a single required parameter with 100% schema description coverage (contract address, 0x… 40 hex chars), so the schema already carries the semantics. The description adds nothing about the token argument, which is acceptable given the coverage but earns no above-baseline credit.

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 the resource as one token's delivered compute from a points engine and lists the fields returned, so an agent can infer it is a per-token compute lookup. However it is a noun phrase, not a verb+resource statement, and it never differentiates itself from the sibling comfy_compute_funded, which likely overlaps. Undefined jargon like 'Infinity index' and 'ladder tier' further blurs 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?

There is no guidance on when to call this versus comfy_compute_funded or any other sibling, and no stated prerequisites (e.g. token must be launched). The edge-case sentences describe outcomes, not call conditions. An agent must guess the selection criteria.

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

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

Annotations already declare readOnly, idempotent, non-destructive and open-world access, so the safety profile is covered. The description adds one behavioral note — the data is returned raw as the engine serializes it, i.e. unfiltered/un-normalized — but says nothing about volume, ordering, or freshness.

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 short sentence with no padding, and the key qualifier (public, active services) is placed up front. Nothing is repeated from the schema or annotations.

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 parameters, the description is the only place an agent can learn what comes back, and it defers with "exactly as the engine serializes them". It is complete enough to know this is a zero-arg read of a service listing, but not enough to anticipate the response shape.

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

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

The tool takes zero parameters, so the schema leaves nothing to explain and the baseline of 4 applies. The description correctly implies no filtering or paging inputs are needed.

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

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

It conveys that the tool returns the active services that agents sell, but the framing is metaphorical ("public bazaar floor", "exactly as the engine serializes them") rather than a plain verb+resource statement like "List active services". An agent can guess it is a listing tool, but the domain jargon blurs what is actually returned.

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?

There is no statement of when to call this versus the many siblings (comfy_jobs, comfy_tokens, comfy_agent_compute, etc.) or when not to. The 'public' qualifier hints at a scope distinction but never names an alternative or condition.

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?

Adds real behavioral context beyond the annotations: no keys, no signatures, no submission, the creator-binding constraint, and the five-minute deadline embedded in the output. That said, the description doesn't explain what happens with the fee/policy hash in practice, and readOnlyHint=true alongside a state-dependent (idempotentHint=false) build could confuse an agent about reproducibility. No contradiction, but not exhaustive.

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

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

Two tightly packed sentences with zero filler. The UNSIGNED constraint and the no-keys/no-submission caveat are front-loaded, and the sibling-flow disambiguation is appended efficiently.

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 10 parameters, a nested object, and no output schema, the description covers the safety and flow story well but leaves the biggest input surface (terms: tax, delay, opening/floor bps, decay) totally unexplained. Return values are implied (policy hash, fee, deadline) but not confirmed. Adequate but with a clear gap for a tool this structurally complex.

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

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

Schema coverage is 50%, so the schema documents some fields (name, symbol, creator, salt, opening_tick), but the most complex input — the nested `terms` object with five numeric fields — has no description-level explanation in either place. The description adds the creator/sender binding but nothing about the terms, recipients array semantics, or opening_tick alignment. Baseline 3 for partial coverage plus marginal additive value.

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

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

States a specific verb and resource ("Build an UNSIGNED ordinary token launch") and pins it to the committed mainnet ComfyLauncher. It also distinguishes the output artifact (unsigned tx with policy hash, fee, deadline) from the sponsored-launch and agent-registration flows, so the agent can tell it apart without opening the schema.

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

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

Explicitly scopes when this is appropriate: unsigned build only, no submission, and directs agent registration and sponsored launch elsewhere. It also states the precondition that the creator must be the eventual sender. It stops short of naming an exact sibling tool as the alternative, which keeps 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?

Adds real behavior beyond the annotations: sells emit conditional ERC20→Permit2 and Permit2→router approval transactions in order, the recipient receives output while the signing wallet supplies input, and nothing is signed or broadcast. This matters because readOnlyHint=true is otherwise ambiguous for a tool that assembles transactions. Minor gap: no statement on quote expiry/freshness 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?

Four short sentences, front-loaded with the core purpose and the UNSIGNED/no-keys constraint, then the sell-approval ordering. No filler, no repetition of the title.

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

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

For a 5-required-parameter builder with no output schema, the description covers the essential contract (unsigned, per-role semantics, approval chaining). It only partially conveys the return shape — it implies an ordered list of transactions but never says so explicitly, leaving an agent to guess whether output is one tx or many.

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

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

With only 20% schema description coverage the description needed to carry parameter meaning, and it does clarify the recipient-vs-signer distinction. But it also says 'Values are decimal wei strings,' while the schema's `amount` is documented as 'Exact decimal human units ... No exponents' — a direct and dangerous contradiction on the most error-prone parameter. `slippage_bps`, `token`, and `side` receive no added 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?

States a specific verb and artifact: 'Build an UNSIGNED ComfyRouter transaction from a fresh quote.' This clearly separates it from comfy_swap_quote (which presumably produces the quote) and from comfy_build_launch_tx (a different transaction builder). An agent can select 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?

'From a fresh quote' implies the prerequisite step in the comfy_swap_quote → build → sign workflow, and 'No keys, signatures or transaction submission' marks the handoff point after this tool. However, no sibling is named explicitly as an alternative and there is no statement about when this tool should not be used (e.g. stale quotes).

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), but the description adds real behavioral content: on partial index reads the response is live:false with outcome compute_unknown and a reason, "never a number", and results are "served verbatim". That failure-mode disclosure is exactly what annotations cannot express.

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

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

The purpose is front-loaded in the first clause and the exclusion and error semantics follow in order. It is dense and jargon-heavy ("cumulative InfinityComputeDestination.totalDelivered", the "Served verbatim." fragment), but nearly every clause carries information an agent needs.

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 takes on the burden of describing returns and does so: total in OG, agent count, per-token rows with their fields, and a basis sentence. Combined with the failure-mode explanation, an agent can call this correctly and interpret both success and degraded responses.

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; baseline applies. The description instead spends its words on the return shape, which is the right choice 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 names a specific resource and scope: cumulative compute delivered per pool, all time, from the points engine's Infinity index. It explicitly excludes misreadings ("not a remaining balance or inference bought"), though it never names the sibling comfy_agent_compute as the alternative for per-agent views.

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 context is implied rather than stated: "all time" and "from the points engine" tell the agent when this metric applies, and the negative clause rules out balance/inference questions. There is no explicit "use this instead of comfy_agent_compute when..." routing against a very crowded sibling set.

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

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

Beyond the annotations (readOnly, idempotent, non-destructive, openWorld), the description discloses that wallet-only scans cover at most 100 indexed tokens by ascending address, use eight pool workers, have a 20-second budget, report failed pools and completeness, and never return a lifetime total. This is unusually rich behavioral context for a 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?

The purpose is front-loaded in the first clause and the limitations follow in a dense second sentence. It is efficient and information-rich, though the second sentence is long and packs several independent constraints together.

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 usefully names the returned fee categories and the pending projection. It also explains scoping, completeness reporting, and a key limitation (never a lifetime total). It is nearly complete, but lacks detail on the response shape and on the behavior when both parameters are supplied or when neither is supplied.

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

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

With 0% schema description coverage, the description carries the burden and does add meaning: it explains that token, wallet, or both may be supplied, that wallet selection uses current bound recipients, and that wallet-only scans have specific scoping and performance behavior. It omits what happens if neither parameter is supplied and does not explicitly state the address format, which the schema pattern covers.

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 read operation over FeeSplitter fee categories (claimable, earned, claimed, reassigned) plus a pending next-sweep projection. It clearly describes the resource and distinguishes the result from a lifetime total, though it does not explicitly compare itself to any sibling 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?

It tells the agent to supply token, wallet, or both, and explains that wallet selection uses current bound recipients. However, it gives no explicit when-to-use/when-not-to-use guidance relative to alternatives, and the wallet-only scan constraints are behavioral limits rather than selection guidance.

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

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

Annotations already cover safety (readOnly, idempotent, non-destructive), so the description is free to spend its words on auth mechanics — and it does: COMFY_SESSION is forwarded only on stdio, HTTP yields 401, and the engine validates that the address matches the session. That is genuine behavioral context an agent cannot get from the annotations or schema. It stops short of describing result shape or 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?

Two sentences, no filler, with the core purpose front-loaded. The second sentence is dense (parenthetical transport caveat plus authorization rule) but every clause carries operative 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 is the only place an agent could learn what a 'job record' contains, whether results are paginated, or how many come back — and it says none of that. Auth behavior is well covered; return-shape and volume are not.

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 address parameter, so baseline would be 3. The description adds real semantics the schema lacks: the address must match the session's owner, meaning a mismatched address fails rather than returning empty. That constraint meaningfully changes how an agent picks a value.

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

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

States the resource and scope precisely: 'Private commercial job records for the owner wallet' — an agent knows it returns job data scoped to a wallet. The verb is implied rather than stated (read/list), and the distinction from siblings comfy_tasks/comfy_task ('jobs' vs 'tasks') is left ambiguous, which matters in this family.

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 an important operational precondition (stdio-only session forwarding; 401 over --http) that tells the agent how to call it successfully. However, it never says when to reach for this tool versus the closely named comfy_tasks or comfy_task, so selection guidance against siblings is absent.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: case-insensitivity, substring matching semantics, use of the public indexer filter, and that results report scanned rows, hidden tokens and truncation.

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 tight sentence with the core operation front-loaded and the reporting behavior trailing. Every clause carries information; nothing is padded.

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

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

With no output schema, the description usefully pre-announces the notable return signals (scanned matching rows, hidden tokens, truncation), which is exactly what an agent needs to interpret results. The only gap is the undocumented limit parameter and its truncation interaction.

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 carry parameter meaning. It clarifies what the query matches against (name, symbol or address, case-insensitive), which is valuable, but says nothing about the limit parameter, its default of 25 or the cap of 50.

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 (case-insensitive substring search) over specific fields (name, symbol, address) and anchors scope to the same Infinity market as comfy_tokens. An agent can distinguish it from comfy_tokens and comfy_token without opening any schema.

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

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

The description makes clear this is the search-by-text path and contrasts implicitly with comfy_tokens (the same dataset, unfiltered listing). It does not name comfy_token as the alternative for exact single-token lookup or state when not to search, so it stops short of full routing guidance.

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

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

Annotations already declare read-only, idempotent, open-world, and non-destructive behavior. The description adds that it is an eth_call, includes live per-pool fee rates when readable, and returns null for unknown impact or fees, which is useful behavioral context beyond the annotations.

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

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

The description is brief and front-loaded, with no filler. Return-value and null-handling notes are compactly packed into two 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?

With no output schema, the description does a decent job of describing key return values and null behavior. However, it leaves gaps around parameter meaning, slippage handling, and how this quote should be used with the swap-building sibling.

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 25%, so the description needs to compensate for undocumented parameters. It does not explain token, side, or slippage_bps semantics, and adds little beyond the schema's amount description and the phrase 'exact-input'.

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 technical operation: a read-only exact-input CLQuoter eth_call on 0G mainnet that returns expected and minimum swap output. An agent can identify it as a quote tool, but it does not explicitly distinguish it from the sibling comfy_build_swap_tx.

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?

Read-only and exact-input imply this is a preview/quote step, likely before building a swap transaction, but the description never says when to use it instead of comfy_build_swap_tx or other siblings. Usage is implied 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?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real behavioral context: 'served verbatim', counts only never a rate, comfy-funded and same-owner counted apart, and the data:null outcome for absent tasks. It stops short of auth or rate-limit details, keeping it a 4 rather than 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 front-loaded sentences with no wasted framing; the scope and return contents come first, followed by the null-case. It is densely packed but every clause carries information, though the long parenthetical 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?

With no output schema, the description carries the return-value burden and does so fully, describing each returned component and the null case. Nothing an agent needs to call and interpret the result 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?

With one parameter at 100% schema coverage, the schema fully documents the id. The description's '(tsk_ and 12 hex)' essentially repeats the schema's own format note, adding little beyond what's already structured, so the baseline 3 is appropriate.

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

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

States a specific retrieval verb and resource ('One task by id') and enumerates exactly what the response contains: the task, its acceptors in board order with record counts, the buyer's standing counts, and now_s. The singular 'one task by id' cleanly distinguishes it from the plural sibling comfy_tasks without ambiguity.

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

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

Usage is implied by the singular lookup and the note that a missing task yields data:null, but the description never explicitly names the alternative (comfy_tasks) or states when to prefer one over the other. An agent can infer the retrieval context but gets no explicit routing guidance.

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

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so safety is covered. The description adds genuinely non-obvious behavior: newest-first ordering, verbatim serving with the engine's now_s, cursor-based paging, and the live:false / task_board_closed outcome for a non-open board.

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 tight sentences, front-loaded with what the tool returns before covering pagination and the closed-board edge case. Minor jargon ('the engine's now_s') costs a little, but no sentence 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?

With no output schema, the description carries the burden of describing return values and does so field by field, and it covers paging and the closed-board failure mode. Filter combination semantics are left entirely to the schema, which is the only real gap for a 4-parameter listing tool.

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

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

Schema description coverage is 100%, so all four parameters are already documented in the schema, establishing a baseline of 3. The description's note that '`after` is the `cursor` of the last page' largely restates the schema and adds no meaning for kind, category, or min_budget_og.

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 ('Open tasks on the Comfy task board, newest first') and enumerates the returned fields, which makes it clearly distinguishable from the singular sibling comfy_task. It stops short of naming that sibling explicitly, so an agent still infers the plural/singular split.

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

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

Gives concrete guidance for pagination ('`after` is the `cursor` of the last page') and for the failure case (a closed board yields a live:false outcome such as task_board_closed). It never says when to prefer this over comfy_task or how the kind/category/budget filters combine, so the when-to-use guidance is implied 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?

Goes well beyond the annotations by decoding two distinct null states ('null market figures mean the token has never traded' vs 'data:null means the index does not know the address') and explaining the meaning of the `listed` flag. Those edge-case semantics are the main failure mode for an agent reading a sparse address lookup, and they are spelled out precisely.

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 resource and access pattern, then the field inventory, then the null-state caveats last. No filler; the field list is dense but justified because there is no output schema to carry 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?

There is no output schema, so the description has to convey what comes back and what degenerate responses look like — it does both via the field enumeration and the two null explanations. An agent needs nothing further to call this 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 `token` parameter is already documented in the schema as a 40-hex-char 0x address. The description only reinforces 'by address' and adds no format, checksum, or casing guidance, so this sits at the baseline where the schema does the work.

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 resource and access pattern ('One token by address') and then enumerates exactly which fields come back (identity, creator, pool, price, volumes, FDV, market cap, liquidity, counts). This clearly separates it from list-style siblings like comfy_tokens or comfy_search_tokens, 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?

The singular 'one token by address' implies this is the detail lookup and siblings are the list/search paths, but there is no explicit 'use this when…' or 'for discovery use comfy_search_tokens instead' statement. An agent must infer the routing from the phrasing rather than being told.

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

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

Annotations already cover read-only/idempotent/non-destructive, but the description adds substantive behavior: never-traded tokens report null market figures ('unknown is not zero') and the list omits test launches and reserved tickers while reporting the count in `hidden`. These are exactly the caveats an agent needs before interpreting results.

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, then useful caveats follow in two tight sentences. The market-field enumeration is somewhat dense but each clause carries information an agent needs to interpret the output.

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

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

With no output schema, the description correctly carries the return-value burden by naming the market fields and the `hidden` count, plus null-semantics. It could be slightly more explicit about the overall response shape (list vs. object), which keeps it short of a 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?

There is a single `limit` parameter with 100% schema description coverage, so the schema already documents its meaning and defaults. The description adds no parameter-level syntax or constraints beyond what the schema provides, which is the baseline case.

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 — 'List the newest launched tokens on comfy.fun (0G mainnet) with market fields' — and enumerates the market data returned. It also distinguishes itself from comfy_token, noting that hidden tokens are still readable there by address.

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 context for using this tool is clear (newest launches with market stats) and it explicitly points to comfy_token for the tokens excluded from the list. It doesn't explicitly contrast with comfy_search_tokens, so the alternative routing is only partial.

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

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

Annotations already declare read-only/idempotent/open-world, so the bar is lower; the description still adds real value by disclosing ordering, the exact field set, and two null-handling rules (unknown side → null, unknown token → data:null). It does not mention rate limits or truncation behavior beyond the implied newest-first ordering.

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 front-loaded sentence carries scope, ordering and the return-field list, followed by a short edge-case clause; no filler. The field enumeration is dense but each item earns its place since there is no output schema.

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

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

With no output schema, the description appropriately documents what comes back (side, trader, amounts, prices, tx hash) and how nulls behave, which is what an agent needs to interpret results. It stops short of clarifying whether 'data:null' is a top-level or per-record shape, leaving slight ambiguity.

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

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

Schema description coverage is 100%, including limit's default/min/max and token's address format, so baseline 3 applies. The description adds only the 'newest first' ordering nuance, which the schema's limit description already states.

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

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

States a specific resource and scope ('recent trades for one token, newest first') plus enumerates the returned fields, so it is immediately distinguishable from siblings like comfy_token or comfy_search_tokens.

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 'one token' scoping implies this is the per-token trade-history lookup, but there is no explicit when-to-use/when-not or named alternative (e.g., vs comfy_token or comfy_jobs). Usage is inferred rather than stated.

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