Asks

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds only that payment outcome is included, which is a small content hint; it says nothing about what happens with an unknown address or collectionId, whether review can be pending, or how fresh the verdict is for an openWorld server with no stored key.

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 no filler and the payoff detail placed after the verdict, which is a sensible ordering. It is concise to the point of being thin, 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?

There is no output schema, so the description should describe what a verdict looks like, what states exist, and what the money-status field can be. It is instead a fragment that leaves the return shape and the sibling boundary with review_billing_status entirely undefined.

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%: address is well documented in-schema, but collectionId has no description anywhere, and the tool description never mentions either parameter or how they scope the lookup. With half the parameters undocumented, the description needed to compensate and 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 identifies the subject as the review decision on an answer plus its payout outcome, which is more specific than the title alone. But it is a noun phrase with no verb and no indication that this is a retrieval operation, and it does not distinguish itself from siblings like review_billing_status, which also sounds like it covers money status.

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 when-to-use guidance at all: nothing says to call this after collect_answer, nothing explains how it differs from review_billing_status or list_checkers, and no prerequisites are given. An agent must guess from the sibling names.

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 safety profile is covered. The description adds genuinely new behavior the annotations cannot express: a consent-link flow on private asks, the one-day access window, and the fact that a repeat call is expected rather than an error.

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 filler; the read operation is stated before the conditional flow. The long parenthetical in sentence two is dense but still earns its place by explaining the access window.

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 returns and does so only loosely ('answers ... and their supporting evidence'). It says nothing about what a call returns when answers are still pending or absent, which matters for a polling-style 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 only 50% — collectionId carries no description at all beyond a digit pattern. The description never mentions collectionId or wait_seconds by name, so it does not compensate for the gap, and it leaves the schema's internal inconsistency (wait_seconds description says max 20 while the constraint allows 45) unresolved.

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 ('Read answers to an ask you posted') and narrows scope to approved answers plus supporting evidence, which separates it from the ask-creation sibling post_ask. It never names read_ask or check_verdict, so an agent must infer the boundary with the tools that touch the same ask object.

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 procedural guidance for the tricky case: on a private ask the first call may return an Allow link that grants one-day access, and the agent should hand it over then call again. What's missing is any explicit routing guidance against siblings such as read_ask or check_verdict.

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, non-destructive, but the description adds substantial context beyond them: 'Spends nothing' (cost), newest-verification-first ordering with 'nothing ranks them', the exact row contents returned, and the non-obvious rule that a private page is absent from lists yet still invitable by exact @handle or ixo1 address.

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?

Opening clause is well front-loaded and dense, but the paragraph is long and runs together listing behavior, ranking, invite flow, private-page rules, and page mode without visual separation. A few clauses (e.g. restating 'who they are, their rate' in both modes) could be trimmed.

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 fully compensates by enumerating each returned row (identity, LinkedIn verification date, rate, page, invite path) and describing both operating modes. An agent can call and interpret results without further information.

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 already 100%, so the baseline is 3; the description adds real meaning by clarifying that `q` searches the pro's page as the directory search box does, that `handle` accepts an exact @handle or an ixo1 address, and that `available` means open to work now. It largely mirrors the schema, hence 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?

The description states both modes precisely: listing three to five verified pros filtered by field, and reading one person's public page when `handle` is given. The verb/resource pair is clear, though the two modes are introduced in a slightly shuffled order (page mode appears mid-paragraph) rather than up front.

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 pass `q` (what the ask needs or free words), when to pass `available` (open to work now), and when to use `handle` (one person's page), and points onward to `invite_to_call`. No explicit when-not-to-use or exclusion against siblings is given, 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?

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower; the description still adds real domain context: that humans and agents answer the same Asks, that each approved answer is paid up to a cap, and that a repeated job collapses into one row (series). It does not touch pagination or ordering beyond 'closest first' for series.

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 what the tool returns before the filter mechanics, and every sentence carries information. Slightly dense in the middle where it packs pay mechanics and series handling 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?

For an 8-parameter read tool with a nested geo object and no output schema, the description covers return content (pay, feasibility), filter semantics, and series expansion adequately. Defaults like limit and the 3-per-poster board cap are only partially explained.

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 88%, so the schema already documents q, does, kind, near, poster, series, and min_pay in detail, including 'does wins over kind'. The description mostly restates the same filter list rather than adding syntax or defaults, 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?

States a specific verb and resource: listing open Asks on asks.world, including what each pays and whether a model can do it. It is clearly distinguishable in practice from read_ask (single) or post_ask (create), but never names a sibling or an explicit 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?

Gives useful operating context — filter 'the same way the board's search does' and 'list its members with `series`' for batched jobs — but says nothing about when to reach for this instead of where_to_act, find_pro, or read_ask, and offers no 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?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered; the description adds the meaningful extra that it 'Spends nothing' — cost behavior an agent cannot infer from annotations. It also discloses the response shape in the absence of an output schema, though it says nothing about result ordering or volume.

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 what verifiers are, then the returned fields, then how to use a name downstream, closing with the cost note. Dense and largely waste-free; the field enumeration is long but each item is a distinct return attribute and no output schema exists 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?

A parameterless, non-destructive list tool with no output schema — the description fully compensates by spelling out every returned field, the cost implication, and how to feed a returned name into post_ask/ask_the_world. Nothing an agent needs in order to call it and act on 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?

Zero parameters, so the baseline is 4 and no parameter documentation is required. The description instead spends its words on enumerating the output fields, which is the more useful information for a parameterless tool.

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 identifies the resource precisely ('the verifiers on asks.world') and distinguishes what a verifier is ('checks answers by its own rules instead of rules written for the ask'), then enumerates the per-item fields returned (name, what it checks, checks offered, required answer inputs, fee per check, human approval). The verb 'list' is only implied by 'For each: ...' rather than stated, which keeps it just short of 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 gives explicit downstream usage: 'Post an ask checked by one with post_ask or ask_the_world and `checker` (its name), plus `check` when it offers several', naming the sibling tools and the parameter mapping. It does not state when to call this vs. other listing siblings like list_asks or find_pro, but no alternate verifier-lister exists so selection 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?

Annotations cover only the mutation/open-world profile; the description goes far beyond by disclosing that money actually moves, that `confirm` must restate the shown total, that a photo of a named place is refused without `near`, that every ask is screened, and that the reply ends in a link where a poster taps Approve. These are non-obvious operational facts an agent could not infer from schema or 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 critical fact (money moves) is front-loaded, and most clauses carry real constraint information. However it is delivered as one dense run-on block of ~15 sentences without structure, restating some schema-level detail (title length/example, image formats), which makes it hard to scan for a 23-parameter 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?

With no output schema, the description still tells the agent what comes back (an approval link, preview-then-confirm flow) and how to check the card path afterwards via read_ask. Given the tool's complexity, the funding paths, screening, and refusal conditions are all 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?

Schema coverage is 91%, so the baseline is 3, but the description adds genuine cross-parameter meaning the schema states only in fragments: the exclusivity set for `pay_by` (no org/oracle/payout/campaign/image), the `checker`-vs-`approver` interaction, and the fact that `report`, `person_checks`, `org`, `oracle` and `campaign` are ignored with a checker. It does not cover every optional parameter (e.g. `series`, `within_m`, `days` are untouched).

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 and resource: "Escrow money against a task for somebody else to do. Money moves." That is unambiguous and instantly distinguishes it from read_ask, list_asks and collect_answer, which read rather than create/spend.

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 routing is given for the main branches: use `pay_by: "card"` when nothing should be spent (and it is the only route on the hosted server), use `checker` for verifier-judged asks versus `approver` for human sign-off, and `org`+`oracle`/`payout` for organisational funding. The 'what cannot be asked' list plus the private-vs-public access guidance gives clear when-not conditions.

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 establish the read-only, idempotent, non-destructive behavior, so the description focuses on useful output context. It adds that the response includes terms, payment, poster, and whether the ask is waiting or live, which goes beyond the safety 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 short and front-loads the main point: full terms of one ask. The sentence fragments are efficient, though slightly clipped phrasing like "as which ask" makes it marginally less polished.

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 read-one tool with rich schema descriptions and clear annotations, the description is complete enough to guide invocation. It explains the returned information without needing to specify an output schema, though it omits edge cases such as invalid ids.

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 fully documented in the input schema. The description restates that the id can come from a pay link created with pay_by "card" but adds little beyond the schema’s own wording.

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 as one ask and lists the specific contents it returns: done criteria, payment, poster, and status. It distinguishes the tool from list-oriented siblings by emphasizing one ask, though it does not explicitly name 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?

Usage is implied by the pay-link id reference and the retrieval of full terms, but the description does not say when to use this tool instead of list_asks, collect_answer, or other siblings. No explicit exclusions or alternatives are provided.

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 readOnly, idempotent, non-destructive and open-world, so the bar is lower. The description still adds real value: 'Never signs' clarifies that despite describing budget signing, this call performs no mutation, and it states where the resulting on/off state and spend are visible to the owner.

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 'Read-only' is well front-loaded, but the single sprawling sentence crams in three enablement channels plus a CLI invocation with a default budget figure — details an agent does not need in order to invoke a read-only status tool. It is dense rather than wasteful, yet not tight.

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 one parameter, rich annotations and no output schema, the description supplies enough: what is reported (verifiers, price, enablement), what is not done (no signing), and where authoritative state lives. Only the exact response shape is left implicit, which is acceptable given the low complexity.

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 and a documented DID pattern, so the schema carries the semantics. The description only obliquely refers to 'an organisation's', adding no format or validation 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?

The description names a specific resource (an organisation's Pay-for-reviews billing status) and enumerates the concrete facts returned: which verifiers bill each review, the price per review, and enablement state. It is distinguishable from every sibling, none of which touch billing, though the head is a noun phrase rather than a verb, making the purpose slightly slower to parse.

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' signals the read context, but there is no explicit statement of when to call this versus another tool or what to do if the org has Pay for reviews disabled. The bulk of the text describes how a human would turn the feature on/off, which is adjacent guidance rather than tool-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 declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: no key is held, the operation is a read, the response is a page URL plus install lines, and signed operations are delegated elsewhere so keys stay local. The phrase 'posts an ask only as a pay link' is slightly ambiguous but is clarified by 'this connector holds no key: it reads,' so no annotation conflict.

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 content is valuable but redundant: the local-plugin requirement is stated twice ('Anything else that needs signing... is done in Claude Code' and 'Posting an ask, submitting work... need the local server'). Sentences are long and run-on, and the key output description is buried at the end rather than 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 two-parameter, zero-required routing tool with no output schema, the description covers what is returned, why the connector cannot sign, and where signed actions must go. An agent has enough to call it and to explain the result to a user; only the exact return shape is left implicit.

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

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

Schema description coverage is 100% and the enum values are fully documented in the schema itself, so the description's enumeration of actions largely restates structured data. It does add the behavioral nuance that 'install' returns only the local server's install lines and that omitting action returns all, but that is marginal. 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?

The closing sentence states the concrete output: 'the site's page for the action and the install lines for the local plugin and package,' which tells an agent this is a routing/orientation tool. The opening sentence establishes the key constraint (read-only, pay-link-only posting) that distinguishes it from the mutating siblings. It is clear but the tool's actual function is stated last rather than first.

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 routes: post_ask with pay_by 'card' works here, while posting, submitting work, connecting accounts, sending earnings and status checks 'need the local server.' It also names the counterpart mechanism (Claude Code + asks.world plugin) and even says 'Call this and say so plainly to the user.' Missing only direct sibling tool names for the local-server paths.

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