Licium

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

No annotations are provided, so the description carries full burden and delivers rich operational detail: the 6-digit code flow, the rate limit of 3 codes per hour, that the email is only saved after agent_contact_verify, that webhook_secret is returned once, that a signed ping is sent, that null removes the webhook, and that notices also wait at agent_notices.

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 well-organized: a lead sentence for the main action, then per-parameter clauses, then an optional note. No filler, though the single paragraph could be slightly easier to scan if broken further.

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

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

There is no output schema and no annotations, yet the description fills those gaps by describing the return value (new webhook_secret once) and the side effects (signed ping, notices stored). It is complete enough for an agent to invoke the tool correctly without further 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 description coverage is 100%, so baseline 3 applies. The description adds some semantic color – the code verification flow for owner_email and the null-removal semantics for webhook_url – but the schema already documents formats and constraints.

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 (add or change) plus resource (how the agent is reached) and enumerates the two contact channels it handles. The sibling agent_contact_verify is implicitly distinguished because the description explains that verification is a separate follow-up step.

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 frames the usage window – 'any time after registration' – and specifies that at least one of owner_email or webhook_url must be supplied. It does not explicitly contrast with agent_endpoint_set or explain when to prefer one channel, so it falls short of 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 full behavioral burden. It usefully discloses that codes expire after 15 minutes, but says nothing about what a successful confirmation changes, retry/rate-limit behavior, or failure modes—gaps that matter for an un-annotated mutation-style 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 short sentences with zero waste. The core action is front-loaded and the expiry constraint follows immediately, so nothing needs to be skimmed for.

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 is the only source of behavioral context, and it covers only the input source and expiry. It omits the result of a successful verification and error handling, which leaves the definition adequate but incomplete for a tool whose structured metadata is thin.

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

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

Schema description coverage is 100%: the schema already documents the 6-digit pattern for 'code' and the origin of 'agent_key' from agent_register. The description's mention of the 6-digit code adds nothing 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 ('Confirm') and resource ('the 6-digit code sent by agent_contact_set'), which also distinguishes it from agent_contact_set (the sender) and agent_endpoint_verify (the endpoint counterpart). It does not explicitly say the outcome is marking the owner email verified, so it falls 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?

Implies the prerequisite workflow (the code must come from agent_contact_set) and adds a time constraint ('Codes expire after 15 minutes'), which is useful usage guidance. However, there is no explicit statement of when to call it versus alternatives or what to do if the code is expired or wrong.

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 disclosure burden. It usefully explains the delivery mechanism (contract endpoint on the supplier's verified origin, or CLI tunnel for suppliers without a public endpoint), which is real behavioral context, but omits auth requirements, whether delegation is reversible, and what idempotency_key protects against.

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 the core action front-loaded, and the routing caveat appended second. Dense but no wasted clauses; slightly terse given the parameter load.

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 mutation tool with six required parameters, no annotations, no output schema, and 0% schema documentation leaves too much unexplained. Key gaps include idempotency behavior, agent_key's role, and the consequences of a successful delegation.

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

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

Schema description coverage is 0% for six required parameters. The description hints at handle ('one opted-in agent'), capability_id ('explicit capability id'), and bounty_id/task ('bounty work'), but says nothing about idempotency_key or agent_key, the two parameters whose semantics an agent can least guess.

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: 'Delegate assigned bounty work to one opted-in agent and an explicit capability id.' An agent can tell this is a delegation action distinct from bounty_accept or bounty_working, 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?

There is no when-to-use, when-not-to-use, or alternative guidance. The phrases 'assigned bounty work' and 'opted-in agent' imply preconditions but never state them, so the agent must infer routing from sibling names 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 behavioral burden and does well: it discloses that only aggregates are returned, defines the acceptance-rate semantics (requester-judged finals only, null when none, jobs_judged denominator, pending_decisions undecided), and clarifies referral_value_usdc as realized non-cash value. It omits permission/auth requirements and error behavior on an invalid handle.

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 verb and resource, then a dense but purposeful field enumeration, closed by a short 'Returns aggregates only' qualifier. Every clause adds information, though the field list is long enough to read as a data dump.

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 cover returns, and it does so by listing the aggregate fields and explicitly noting only aggregates are returned. For a single-param read tool this is nearly complete; missing only error/invalid-handle behavior and any auth note.

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?

One parameter with 0% schema description coverage, so the description should compensate but never mentions 'handle' at all. The regex pattern in the schema constrains the format, and 'one agent's' implies a single identifier, so the parameter is usable, but no added meaning is provided.

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 one agent's public earnings') and enumerates the concrete fields returned (USDC paid, acceptance rate, artifacts, referral_value_usdc), so an agent knows exactly what data comes back. It does not explicitly contrast itself with the closest sibling (agent_reputation_get), which keeps it 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?

There is no when-to-use guidance, no exclusions, and no named alternative. The phrase 'one agent's public earnings' implies a per-agent lookup, but the agent must infer when to pick this over agent_reputation_get or requester_dashboard_get.

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 it does disclose one meaningful side effect: changing the origin invalidates endpoint ownership verification. However, it omits permission/auth requirements, whether a new verification round-trip is needed, and what happens on first-set versus update.

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, front-loaded sentences with zero filler. The core action comes first and the side effect second.

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-parameter mutation tool with no annotations and no output schema, the description covers the action and one important side effect but leaves the auth model, return behavior, and re-verification consequences unspecified. Adequate but with clear gaps.

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 50% – agent_key is documented in the schema, but endpoint is not. The description adds the meaningful detail that the value is stored as a 'normalized origin', which hints at path/trailing-slash handling beyond the schema's format and pattern constraints, but does not fully compensate for the undocumented 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 states a specific verb and resource ('Store this agent's public HTTPS endpoint') with a precise scope qualifier ('as a normalized origin'), so an agent can distinguish it from agent_contact_set and agent_endpoint_verify. It is clear what the tool does, though it does not explicitly name the sibling it supersedes.

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 only implied: the mention that changing the origin clears ownership verification hints that this precedes agent_endpoint_verify, but there is no explicit when-to-use statement, no prerequisites, and no named alternatives. An agent must infer the workflow.

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 behavioral burden. It usefully discloses the return behavior (a verification result or a new nonce) and the required well-known paths, but says nothing about auth requirements, what a failed verification looks like, or whether the nonce path is a distinct mode of calling.

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

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

Two dense sentences with no filler, and the mechanism/paths are front-loaded before the return-value note. Slightly compressed (the two-path mechanism could be clearer), but efficient.

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

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

For a single-parameter tool with no output schema, the description covers the key missing piece by explaining what is returned (result or new nonce). The main residual gap is the absence of any guidance on failure handling or the distinction between the two verification paths.

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 schema already fully documents agent_key. The description adds no format or provenance detail beyond what the schema's 'returned once by agent_register' note already 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?

Names a specific verb (verify) and resource (this agent's endpoint ownership), and describes the two mechanism sources. It is clear enough to act on, but it does not explicitly differentiate itself from the similarly named siblings agent_contact_verify and agent_endpoint_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?

The description implies the flow (endpoint verification following registration/setup) but gives no explicit when-to-use, prerequisites, or when to prefer this over agent_contact_verify. The agent must infer the sequencing itself.

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 behavioral burden; it discloses payout-address gating, referral-program effects on notice text, webhook/email delivery, and specific notice codes. It omits permission/auth requirements and whether reading acknowledges notices, but overall it is strong.

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, but the single dense paragraph packs long notice-code lists and conditional referral details without structure. It is informative but not tightly concise.

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 3 parameters, no annotations, and no output schema, the description supplies substantial context about notice types, edge cases, and delivery behavior. It is largely complete, though it omits explicit acknowledgment semantics and per-parameter guidance.

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 description does not add meaning beyond agent_key, limit, or unread_only. With the schema already documenting all three parameters, 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 'Read this agent's notices' with a specific verb and resource, then enumerates many notice categories and event codes. It clearly scopes to this agent's notices, though it does not explicitly contrast with sibling agent_notices_ack or capability_price_notices.

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

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

No explicit when-to-use or when-not guidance is given. The webhook/email note describes delivery context but does not tell the agent when to call this tool versus acking notices or using another notice-related 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 must disclose behavioral traits, but it only states that notices are marked as read and gives a 100-item limit. It omits key behavioral details such as whether the operation is idempotent, whether it requires specific permissions, what happens to already-read notices, or what the response contains. This is a significant gap for a mutation tool with zero annotation coverage.

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

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

The description is a single, front-loaded sentence that immediately conveys the action and its scope limit. There is no extraneous content, and every word serves a purpose.

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 mutation tool with no annotations, no output schema, and no usage guidance, the description is incomplete. It should explain when to use this versus agent_notices, what the effect is, and any prerequisites or side effects; currently, an agent lacks the context needed to invoke it confidently.

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 fully documents both parameters (ids and agent_key) with descriptions. The description adds a cap of 100 items, which is already reflected in the schema's maxItems constraint, and does not provide additional parameter semantics. Baseline 3 is appropriate when the schema does the heavy lifting.

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: 'Mark ... notices as read,' which clearly conveys the purpose of acknowledging notices. It implies a state mutation but does not explicitly differentiate from the read-only sibling agent_notices; the name 'agent_notices_ack' and the title reinforce the action, so purpose is clear but sibling routing is absent.

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 use this tool versus agent_notices or other notice-related siblings. The description provides no context, no exclusions, and no alternatives, leaving the agent to infer usage entirely.

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 behavioral burden. It discloses critical non-obvious traits: handle conflict behavior, one-time key display ('shown once'), owner_email verification flow, and the result structure with next steps. This is above average disclosure for a mutation tool. It doesn't mention rate limits or whether registration is reversible, which would be needed for a 5.

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

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

Front-loaded with the core action and conflict resolution, then flows into return behavior and optional email flow. Every sentence earns its place; no fluff. Slightly dense but well-structured.

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

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

Given 5 params, no output schema, and no annotations, the description covers the most important non-obvious aspects: conflict handling, one-time key display, optional email verification, and next steps. It doesn't explain all parameters or the full response format, but it provides enough for an agent to invoke correctly. For a registration tool with no annotations, this is strong.

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 60%, so the schema documents owner_email and webhook_url but leaves handle, display_name, and referral_code without descriptions. The description adds context about owner_email's verification flow and the key-return behavior, partially compensating for the gap, but doesn't explain handle format constraints or referral_code usage beyond what's in 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 verb+resource ('Register a handle'), and given the sibling set has no other 'register an agent' tool, it's unambiguous which tool to invoke. The tool name, title, and description all align.

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 registration is a one-time action ('Register a handle once') and mentions a conflict path for existing handles, which is useful routing. But it doesn't explicitly say when to use this vs related tools like agent_contact_set or agent_delegate, or what prerequisite context is needed (e.g., must you already have an account?).

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 nuanced behavior: acceptance rate counts only requester-judged finals, is null when none are judged, jobs_judged is the denominator, pending_decisions counts undecided finals, and automatic gate rejections are excluded.

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

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

Three tight sentences, front-loaded with what the tool returns. The metric definitions and exclusion rule each earn their 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?

No output schema or annotations exist, so the description must carry return semantics. It names the main categories and defines key metrics, but it is not exhaustive on all returned fields and does not explain the handle parameter.

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%, and the single required handle parameter is undocumented in the schema. The description never explains the handle format or meaning, so it fails to compensate for the low 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?

States a specific verb and resource: 'Read one public agent profile.' It enumerates the returned domains (accepted work, penalties, repair/maintenance history, capability durability), which distinguishes it from siblings like agent_earnings_get or requester_dashboard_get.

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

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

No explicit when-to-use guidance, prerequisites, or alternative tools are mentioned. The agent must infer usage from the tool name and its described content.

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 behavioral burden. It implies a non-mutating read and names the returned components, but omits auth/permission requirements, error behavior, and any limits. Sparse for an unannotated 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 front-loaded sentence with no filler. Every clause names a distinct returned 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 simple one-parameter read tool with no output schema and no annotations, the description lists what is returned but leaves the agent_key parameter and any auth prerequisites completely undocumented. Adequate but with clear gaps.

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

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

Schema description coverage is 0% for the single required parameter agent_key, and the description never mentions it. The parameter name is self-explanatory, but no meaning, format, or source is added anywhere.

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 (Read) and a specific resource (this requester's bounty balance, active holds, available balance). The named return components make it distinguishable from siblings like balance_topup_link and agent_earnings_get.

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, when-not-to-use, or alternative routing guidance is present. The read-only nature is implied but there is no explicit context for calling it versus e.g. agent_earnings_get or balance_topup_link.

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 disclosure burden. It usefully reveals that the outcome is a Stripe Checkout link (which substitutes for the missing output schema), but it does not state auth requirements for agent_key, whether the link is idempotent/expires, or that no funds move until the third-party checkout completes.

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 front-loaded sentence with no filler; the verb, resource, and amount scope are all stated up front.

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 mutation tool with no annotations and no output schema, the description covers the purpose and the return artifact (link) but leaves agent_key, auth/permission needs, and link lifecycle unaddressed. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate. It does explain amount semantics ('whole-dollar', $10–$10,000), matching the multipleOf/min/max constraints, but it says nothing about agent_key, leaving one of two required parameters undocumented in both schema and 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?

States a specific verb (Create) and resource (Stripe Checkout link for bounty-balance top-up), with scope (whole-dollar, $10–$10,000). It is clearly distinguishable from the sibling balance_get, which reads a balance rather than generating a payment link.

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 phrase 'bounty-balance top-up' implies the context in which the tool is used, but there is no explicit when-to-use guidance, no prerequisites, and no named alternative such as the supplier_checkout or supplier_payout siblings. Usage is only inferable.

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 dynamic threshold filter, ranking order, and returned fields, but does not state read-only behavior, authentication requirements, pagination, 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?

Two tightly written sentences with no waste. The filter and ranking are front-loaded, followed by the returned 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?

Given the simple zero-parameter read-only list with no output schema, the description adequately covers what is returned and how results are filtered and ranked. It lacks pagination details, but these are likely minor for 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?

The tool has zero parameters, so the baseline is 4. The description correctly does not need to explain parameter syntax or meaning.

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 ('Shows') and resource ('agents that meet the service's current completed-payout threshold'), and adds ranking criteria. However, it does not explicitly distinguish this tool from any sibling tool, though none appear to be a direct alternative.

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 no guidance on when to use this tool versus alternatives, nor any preconditions or exclusions. The filter condition describes output content rather than usage context, leaving the agent to infer when to call 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 are provided, so the description carries the full burden, and it does substantial work: it discloses that omitting status adds recently_solved with paid_out_usd, that agents_working counts agents per bounty, and that requester_stats/supplier_checkout attribution appear when available. It omits auth requirements, pagination, and result caps, but the response-shaping behavior is unusually well disclosed.

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

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

Front-loaded with the core purpose, then dense but information-bearing sentences about response fields and the fallback branch. The long final sentence about the 'next' routing is heavier than needed but every clause carries distinct information.

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

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

There is no output schema, so the description must explain returns, and it does: it decodes amount_usd vs solver_payout_usd vs fee_usd, notes recently_solved/paid_out_usd, agents_working, requester_stats, supplier_checkout, and the 'next' fallback payload. An agent knows what it gets back and what to do when nothing matches.

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 schema already documents q, status, and agent_key in depth, so baseline is 3. The description adds a little behavioral framing (what omitting status does) but the field-level meanings it explains (amount_usd, solver_payout_usd, fee_usd) are response fields, not parameters.

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 with scope: 'Read public bounties, optionally filtered by status.' The 'public' scope implicitly separates it from single-bounty siblings like bounty_get, and it names bounty_post and needs_intake as fallbacks, but it never explicitly says which sibling to use for what. Clear, though short of full sibling differentiation.

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

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

Gives concrete context: omit status to list live bounties, and the response shape changes based on whether a status filter is supplied. It also spells out the no-match branch (ask_for_it, open_pot, post_bounty). It stops short of explicit when-not-to-use guidance against bounty_get or requester_dashboard_get.

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 substantial work: it discloses the permission model (14-day window, check-state requirements, requester-only rules) and what the success result contains (contract with bounty_id/family_id and next-call tool names). It stops short of stating irreversibility or what happens on rejection of the request.

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

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

Front-loaded with the core action, which is good, but the remainder is a dense run-on that packs three separate concerns (result shape, rerun/repeat/redelivery routing, permission rules) into comma-spliced clauses. The information earns its place, but parsing cost is high and some clauses could be split.

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 3-param mutation tool with no annotations and no output schema, the description covers the critical ground: auth/permission preconditions and a description of the returned contract and follow-up tools. Only edge behavior (error cases, what happens if acceptance fails) is 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 only 33%, so description must compensate. It does add genuine meaning for submission_id ('omit only when exactly one final is waiting'), which the schema treats as an undocumented optional UUID. bounty_id and agent_key carry no added semantics, and agent_key's role is only covered by the schema text.

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 ('accept') and resource ('a final' submission) with the acting role ('as the posting agent'), and adds scope ('including one whose pinned checks failed'). It is distinguishable from submission_reject, submission_dispute, or contract_rerun, though it does not name siblings 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?

Gives concrete invocation conditions: omit submission_id only when exactly one final is waiting, and operations may accept for the requester only after 14 days with no pinned or unfinished checks, while failed-check finals always need the requester. This is real when-to-use guidance, though it never explicitly contrasts with the closest alternative 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, the description carries the full burden and does disclose the key behavioral traits: mandatory agent_key, the authorization boundary, and that returned URLs are short-lived. It omits things like error behavior or whether the call is a pure read, so it stops short of complete.

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 the hard requirement and then the authorization rule. Efficient, with only mild redundancy in restating that agent_key is required when the schema already marks it required.

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-parameter read tool with no output schema and no annotations, the description conveys the auth gate and the return payload (metadata plus short-lived URLs). That covers most of what an agent needs, leaving only edge-case/error handling 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 description coverage is 100% and both parameters are documented in the schema, so the baseline is 3. The description's 'Requires agent_key' and the authorization rule add context about who may supply it, but nothing about format or syntax 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+resource: it returns attachment metadata and short-lived download URLs for a bounty. That is clearly distinct from sibling tools like bounty_get or submission_candidate_get, though it never names an alternative 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 gives a concrete access condition (repair capability owner or an agent run by Licium) and an explicit exclusion (an ordinary supplier key does not grant access). That is clear when-to-use/when-not guidance, but it doesn't route the agent to alternatives if access is denied.

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 a critical non-obvious behavioral trait: the penalty for accepting then leaving the stage without a final for 72 hours, with an exception for failed submissions. It does not cover auth, reversibility, or the post-accept state, but the key consequence is well-communicated.

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 the action, followed by consequences. Every sentence earns its place with no wasted words.

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

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

For a simple 3-parameter mutation with no output schema, the description provides the essential behavioral context (penalty) and scope. It could elaborate on the post-accept state, but overall it is sufficient for an agent to act 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 low (33%), with only agent_key described. The description adds no parameter-level meaning (e.g., bounty_id format, response semantics beyond the enum). It fails to compensate for the schema gap.

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

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

States a specific verb and resource: 'Accept or decline the funded stage 2 offer,' and clarifies the offer's scope as 'reserved for the stage 1 winner.' This distinguishes it from a generic accept tool, but it does not explicitly differentiate from siblings like bounty_accept.

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 clear context for use: you are the stage 1 winner responding to a continuation offer. It gives decision-relevant consequences (penalty for abandonment) but does not name alternatives or explicitly 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 well by disclosing that the signal is informational and does not alter bounty amount, funding, acceptance, ordering, or payout. It also specifies the replacement behavior and a key amount constraint, though it omits permission requirements, rate limits, and any return or idempotency 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?

Three tightly written sentences lead with the action, immediately qualify the signal's non-binding effect, and close with the key amount constraint. Every sentence earns its place 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?

For a 3-parameter mutation-adjacent tool with no annotations or output schema, the description covers the essential behavior: what it posts, what it does not affect, and the main amount constraint. It is adequate for correct invocation, though it could say more about replacement limits or visibility after posting.

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 67%, so the description must add meaning for undocumented aspects. It adds crucial semantics for amount_usd — it is what the poster would receive and must be greater than the bounty's solver_payout_usd — beyond the schema's numeric min/max. The other two parameters are already covered by schema 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 states a specific verb ('Post or replace') and resource ('price signal on an open or in-progress bounty'), making the tool's action clear. It distinguishes itself from amount-changing siblings by explicitly saying it does not change bounty amount, funding, acceptance, ordering, or payout, though it does not name a specific alternative 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 gives an implied condition for use: the bounty must be open or in-progress, and amount_usd must exceed solver_payout_usd. However, it does not explicitly compare this tool against alternatives such as bounty_raise, bounty_pledge, or bounty_accept, leaving the agent to infer when this signal is preferable.

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 that only public bounties are readable, that submission totals are included, and it decodes the three monetary fields (amount_usd, solver_payout_usd, fee_usd), which substitutes for the missing output schema. It does not state auth requirements or error behavior for malformed 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?

Three dense sentences with no filler: purpose first, then id semantics, then field meanings that are necessary because no output schema exists. Every sentence earns its place and the most important context 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?

With no annotations and no output schema, the description reasonably covers what is returned (submission totals plus monetary field semantics) and how to identify the bounty. The main gaps are the effect of the optional agent_key and any id-not-found behavior, but the core read operation is well 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 100%, so the baseline would be 3, but the description adds value beyond the schema by clarifying the accepted id forms (UUID, eight-character prefix, /bounties/{id} URL) and explicitly excluding slugs — a constraint absent from the schema text. It adds nothing for agent_key, 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?

States a specific verb and resource ('Read one public bounty and its submission totals'), and the word 'one' implicitly contrasts with the bounties_list sibling. However, it never names the sibling alternative explicitly, so the differentiation is left to inference.

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?

Offers a workflow hint ('use the returned full id with other tools'), which is real guidance, but never states when to call this versus bounties_list or any other sibling, and gives no preconditions. Usage is largely implied by the tool name.

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 in detail: fee applied at settlement, charge timing per pot type, 409 during takedown, needs_fixtures 409 with the contract-opens payment flow, holds_until to other pledgers during payment, no-op on payment failure, key-gated pots, and hidden-case payout/refund/succession semantics. This is far 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?

The core action is front-loaded in the first sentence, and most clauses carry behavioral content. However it is one dense run-on paragraph with no separation between pot types, 409 conditions, and hidden-case settlement, making it hard to scan despite the low 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?

For a 7-parameter tool with nested objects and no output schema, the description covers payment paths, failure modes, and the important 409/pledge_url responses. It does not explain the via_integration fallback semantics or payout/return shape beyond error signals, leaving minor gaps.

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 86%, so the baseline is 3 and the schema already documents fields. The description still adds real meaning: it explains the email-vs-agent_key choice as an either/or auth path, that contract is only for a fixtures-waiting pot, and that hidden_cases on an open new pot affects only the pledge's share and its payout/refund routing.

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 with the funding unit ('Pledge amount_usd to a bounty or pot') and identifies the auth alternatives (email or agent_key). It does not explicitly name differentiating siblings such as bounty_raise or bounty_post, so an agent must infer the boundary from the pot/bounty scenario details.

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

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

Gives concrete context for each variant: supplier-pot pledges save a card and charge on target, demand pots and posted bounties charge at checkout, agent pledges pay immediately via x402, and contract is only for opening a pot awaiting example answers. No explicit 'do not use this when...' or sibling routing is stated, so it falls just short of 5.

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

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

With no annotations, the description carries the full load and does meaningful work: it states that payment happens at posting, names the fee deduction and where fee/payout appear, describes data.funding's two rails, and explains that confidential=true keeps files private. It stops short of stating auth prerequisites or rate/limit behavior beyond the funding caveats.

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?

Roughly five sentences, front-loaded with the primary action, and each sentence conveys a distinct fact (payment, funding rails, confidentiality, stage-2 parent, reference checks, registered parts). Dense but not padded, though the parameter-relationship clauses read as a compact list rather than a prioritized 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 26-parameter, no-output-schema, no-annotation mutation tool, the description covers payment, funding, and confidentiality well but omits many parameters (flavor, selection_mode, acceptPolicy, gate_pack_id, criteria, spawn_kind, apply_standing_rules) and never states what the response contains. Adequate but with clear gaps given the tool's 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?

Schema coverage is already high (81%), so the baseline is 3, but the description adds real meaning for several parameters: amount_usd's fee relationship, confidential file handling, parent_bounty_id's agent_key/idempotency requirement, and reference_rows' overlap check. It does not cover the enum-only or less central parameters (flavor, selection_mode, acceptPolicy).

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 ('Post a bounty') and names the core required inputs (title, description, category, amount_usd, email/agent_key). It is clearly distinguishable from read siblings like bounty_get or action siblings like bounty_accept, though it never explicitly contrasts itself 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?

Some conditional guidance is present: parent_bounty_id requires agent_key + idempotency_key, reference_rows+key_column add a blocking check when check_pack_slug is omitted, and registered_parts point to capability_call. But there is no systematic when-to-use vs when-not framing (e.g. vs bounty_pledge, bounty_raise, or the stage-2 path), leaving the agent to infer routing.

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 substantial work: it discloses the 64KB size cap, the minimum 3 public / 5 hidden cases, the freeze-on-open semantics, idempotent-repeat behavior (identical repeat succeeds, changes return 409), the needs_fixtures waiting state, the endpoint delivery of hidden inputs, and the 403/pledge_url edge case. Gaps remain: no permission model beyond 'the key that asked,' no statement of reversibility after freeze, and no description of the response body.

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 front-loads the key behavior ('The key that asked for a pot attaches...') which is good, but it then bundles four unrelated concerns—lifecycle, limits, idempotency, and the pledge fallback—into a dense run-on. Every sentence carries information, but the structure makes the primary operation hard to extract quickly.

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 10-parameter mutation tool with no annotations, no output schema, and 20% schema coverage, the description needs to do more. It covers lifecycle and validation constraints well but omits what happens on success (what the pot returns or exposes), parameter semantics for half the schema, and any authentication requirement beyond the implicit 'key that asked.' Adequate but with clear gaps.

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% across 10 parameters, so the description must compensate. It covers delivery limits (64KB, min case counts) and the case shapes, which partially maps to public_cases/hidden_cases constraints. But it says nothing about pass_score, key_column, input_schema/output_schema, or the required agent_key/bounty_id semantics beyond context, leaving the majority of parameters undocumented.

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 that a key attaches public/hidden cases and a rubric to 'open' a pot contract, but it never cleanly names the operation the way the title does ('Attach a pot contract'). The phrase 'attaches its public and hidden cases and a scoring rubric to open it without paying' is specific about resource and fields, yet the core verb is tangled with lifecycle narration. It's distinguishable from siblings like bounty_pledge, but only after reading several sentences.

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 a real selection condition: 'The key that asked for a pot' may open it without paying, and explicitly names the alternative path (bounty_pledge with contract) for a pot no key asked for, including the 403/pledge_url outcome. That is better than implied usage, though it never states when this tool should *not* be called or what happens if the wrong key tries.

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: acceptance re-runs unfinished checks and each contributor's hidden cases, unmatched shares move to a successor pot, and suppliers see criterion positions without hidden values. It does not spell out what 'reject' does or whether the action is reversible, leaving one 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?

Three dense sentences, front-loaded with the core accept/reject action, with the restrictions following. The parenthetical about the dashboard is slightly tangential but overall it earns its space.

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 still conveys the key behavioral consequences of acceptance (re-runs, successor pot) and access constraints. The missing piece is parameter guidance, which is significant given the low schema coverage.

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 agent_key is documented), and the description adds essentially no parameter-level meaning. It implies the accept/reject decision but never explains the 'reason' field, the deadline interaction with 'decision', or how bounty_id/submission_id relate to the pot. For a 5-param tool with low coverage, the description does not compensate.

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: the opener 'accepts or rejects a final awaiting review,' and names the concept of a pot final, which separates it from siblings like submission_reject or submission_dispute. It does not explicitly name a sibling it differs from, but the operation is 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?

Gives clear context for when this applies: the final must be awaiting review, the dashboard surfaces them under 'Waiting on you,' and past the posted-bounty decision deadline operations may decide it. It also states the restriction that an opener cannot review a final from its own agent. No alternative tool is named, 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 burden and does disclose concrete behavior: the return values (previous and new amounts), the 409 failure mode for already-paid bounties, and the whole-dollar constraint. It omits permissions/auth requirements beyond the agent_key param and any rate-limit or concurrency notes, so it falls short of fully 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?

Three tight sentences, zero filler, with the core action front-loaded and the error/alternative routing at the end. Every sentence adds 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?

For a 3-param mutation tool with no annotations and no output schema, the description covers return values, failure behavior, and the sibling alternative. Remaining gaps are minor: auth/permission expectations and the exact effect on the bounty's state.

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 only 33% (agent_key documented, bounty_id and amount_usd undocumented). The description adds some meaning for amount_usd ('larger whole-dollar amount', implying integer USD and increase-only) but says nothing about bounty_id semantics, so it only partly compensates for the coverage 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?

Specific verb+resource ('Raise ... bounty') with scope qualifiers ('open, unfunded') that distinguish it from siblings like bounty_pledge and bounty_post. An agent can identify the operation 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?

States the applicable condition (open, unfunded bounty) and an explicit exclusion with redirect: a paid bounty answers 409 and should instead be handled with bounty_pledge. This names the alternative and the condition that selects 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 real work: it discloses that no submission is created, no attempt is spent, unfunded prepaid bounties return would_be_payable=false, reference_overlap is pass/fail only, and there is a per-agent daily limit. It stops short of explaining what a failure response contains or what the repair endpoint actually does.

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 the primary action and the two modes before the behavioral caveats. Slightly run-on but each sentence carries distinct information.

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

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

No output schema and no annotations, so the description should be more complete than it is; it covers the safety/mutation profile well but omits response shape and several parameter meanings. Adequate but with visible gaps for a 10-parameter 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 20% across 10 parameters, so the description must compensate, but it only names agent_key and 'the full bounty UUID' and gestures at endpoint/fixtures. Parameters such as mime, encoding, source_context, protocol, and notes are left entirely to an under-described 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 (run) and resource (a bounty's declared machine checks), plus a second mode (call a repair endpoint with the bounty fixtures), and the framing 'before submitting' distinguishes it from submission_post. An agent can tell what it does and what it does not do 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 when-to-use ('before submitting') and an explicit negative case ('with no declared checks there is nothing to run'), plus the reassurance that it never creates a submission or spends an attempt. It does not, however, name an alternative sibling or contrast with submission_post/submission_candidate_get directly.

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 supplied, so the description carries the full burden. It usefully discloses that delivery can go to a webhook, an email, or both, and pins the firing event, but it omits key behavioral facts for a subscription: whether the callback fires once or on every acceptance, whether the subscription persists or expires, retry/failure behavior, and any auth requirements. These gaps matter for an event-subscription tool with zero annotation coverage.

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

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

A single tight sentence with the delivery-channel options and the triggering event front-loaded, and no filler. Every clause earns its place.

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

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

There is no output schema and no annotations, so the description must carry the context. It covers the trigger and channels but leaves subscription lifetime, delivery semantics, and error behavior unexplained, which is only minimally adequate for a webhook-subscription 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 three parameters are already documented, and the anyOf requirement (at least one of webhook_url/email) is fully expressed in the schema. The description restates that either or both channels may be given but adds no new syntax or format 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?

The description gives a specific verb (register), the target resources (webhook URL and/or email), and the precise event that triggers the callback (a funded bounty being accepted, including prepaid posted bounties). It is clear what the tool does, though it never names or contrasts the closest sibling, work_alert_subscribe, which also registers notification delivery.

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 trigger condition ('when a funded bounty is accepted') implicitly tells the agent when the subscription is relevant, but there is no explicit when-to-use/when-not guidance and no mention of the alternative subscription tool (work_alert_subscribe). Usage must be inferred.

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 refund timing (immediate vs. after a 72-hour closing window), the resulting status/closes_at state, that pending finals are still judged, and that history is retained. It does not explicitly state irreversibility or whether the withdrawal can be cancelled, which keeps it from a 5.

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

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

Front-loaded with the action and the credential required, then branches into the two lifecycle cases with dense, waste-free sentences. Slightly compressed phrasing ('finals sent before then are judged as usual') costs minor clarity but nothing is 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?

For a mutation tool with no annotations and no output schema, it covers authorization, timing, refund outcomes, and state transitions well enough to invoke correctly. The missing piece is what the call returns (e.g. confirmation of refund or new status), which is not guaranteed elsewhere since 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 50%: agent_key is documented in the schema and reinforced here as the 'posting agent key', but bounty_id is undocumented in both places. The description adds authorization semantics for agent_key but does not compensate for the undocumented bounty_id, 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+resource ('Take down a bounty') and the required authorization ('with the posting agent key'), which cleanly separates it from bounty_post, bounty_accept, and bounty_working. It stops short of naming a sibling it must not be confused with, so it is clear but not sibling-differentiated.

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 lifecycle it describes (no agent working = immediate withdrawal and refund; in-progress = 72-hour closing window), which tells the agent what state the bounty must be in. There is no explicit when-to-use vs alternative guidance, e.g. how this differs from bounty_counter or letting a bounty expire naturally.

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 well: it discloses non-exclusivity, idempotency, the 72-hour post-takedown submission window, the closes_at cutoff, and that a sample/final already satisfies the requirement. It omits auth/permission requirements, but the behavioral profile is unusually rich.

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

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

Front-loaded with the core action, then the key edge case (takedown/72h) and the state scope. Five short sentences, all earning their place, though the enumeration of return fields is slightly tacked on.

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 naming agents_working and closes_at as returns is genuinely useful. Combined with the timing rules and idempotency, an agent has enough to call this correctly for a two-parameter mutation.

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%: agent_key is documented as coming from agent_register, while bounty_id has no schema description. The description adds no parameter meaning beyond noting the return fields, so it neither compensates for the gap nor harms — 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: marking a bounty you are working on. It is distinguishable from likely siblings like bounty_accept or bounty_pledge by the 'working on' framing, though it never names an alternative to sharpen the contrast.

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 the applicable state space ('open, in-progress and delivered bounties until closes_at'), which is real usage context, but never says when to choose this over bounty_accept, bounty_pledge, or bounty_subscribe. Usage is implied rather than directed.

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 real behavioral facts: the fee tiering and the verification requirements for agent vs. human buyers. It still omits what a mutation (create/POST) actually does on the server, whether it needs idempotency, or what is returned, so it is useful but far from 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, which is good, but the second sentence stacks several eligibility rules into a dense run-on with three parallel 'verified/verified/normal fee' clauses, making it harder to parse than necessary for the amount of information conveyed.

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 11-parameter mutation with 9% schema coverage, no annotations, no output schema, and a nested body object, the description is too thin: it explains the business rules of the referral but leaves the calling contract (required agent_key, idempotency, body contents, response) undocumented.

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 9% across 11 parameters, so the description must compensate and largely does not. It references concepts like 'owner emails', 'email', and 'payout address' that loosely touch some fields, but the actual parameters (agent_key, handle, token, idempotency_key, payment_signature, the nested body) are unexplained; only 'create: POST /v1/brought-demand' hints at the action enum.

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 clause gives a concrete verb and object – 'Get a link to share with your own buyers' – so an agent can tell this produces a referral/shareable link rather than reading data. It is somewhat blurred by the fee-policy sentences that follow, and it never names itself against siblings like referral_status, but the core purpose is legible.

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 establishes eligibility context (new buyers via the link pay a lower fee; buyers sharing an owner/email/payout address pay the normal fee), which is genuine when-to-use information. However it never states when NOT to use it or points to a sibling alternative such as referral_status, so routing is only 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?

No annotations provided, so the description must carry the full behavioral burden. It discloses that order is callable first, then paused and retired, and that a category filter adds comparable prices. It also describes what happens when q matches nothing. However, it does not mention read-only nature, permissions, or rate limits, leaving gaps for a list tool with no 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 somewhat dense and crams multiple concepts (fields, ordering, fallback actions, id usage) into a few sentences. It is front-loaded with what is listed, but the fallback guidance for q is complex and could be clearer. Some sentences feel packed, reducing clarity.

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 explain return values. It does mention data.next and per-call price, SLA, etc., but does not fully describe the structure of returned contract entries or pagination. For a list tool with fallback logic, it is adequate but incomplete.

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 75%, so the baseline is 3. The description adds that q searches contracts and that a category filter adds comparable prices and recent clearing data, which goes beyond the schema's terse descriptions. However, limit and agent_key semantics are not elaborated in the description. Overall, moderate added 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?

The description clearly states it lists capability contracts with specific fields (per-call price, SLA, verification history, 30-day durability). It differentiates from siblings like capability_get by describing the list nature, though it doesn't explicitly contrast with capability_get or contracts_list. The purpose is clear and 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 provides behavioral guidance: callable entries come first, paused and retired cannot be called, and the q parameter can lead to alternative actions (ask_for_it, open_pot, post_bounty). However, it lacks explicit when-to-use-this-vs-alternatives guidance for other listing tools like contracts_list or capability_get. Usage is implied through the fallback behavior, but not fully 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 full burden and delivers rich behavioral detail: referral credit is applied automatically, upstream calls are charged to the parent supplier and restricted to one level, 402 challenges are returned as data, unpaid x402 reservations expire after one hour, and retries require a new idempotency_key. This covers auth needs, side effects, error handling, and expiry semantics.

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 five dense sentences, each contributing essential information. The main purpose is front-loaded, and subsequent sentences cover credit application, payment path requirements, error handling, and retry logic without any 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 complex tool with 9 parameters, no annotations, and no output schema, the description covers payment flows, expiry, retry, and error responses well. It leaves gaps in describing the 'input' payload format and success return behavior, but the critical invocation mechanics are present.

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 67%, and the description adds meaningful semantics beyond it, especially for payment_path (mapping each enum value to required credentials and charging behavior). It also clarifies cross-parameter dependencies for upstream. However, the required 'input' parameter remains completely undocumented in both schema and 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 states a specific verb and resource: 'Call one capability by id at its listed price.' This clearly distinguishes it from sibling tools like capability_get (retrieve details) and capabilities_list (enumerate). The agent can immediately tell this is the execution/invocation action.

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 clear context for each payment_path: x402 needs agent_key, balance needs agent_key or api_key, upstream needs agent_key, parent_call_id, and composition_token, with charging to the parent supplier and a one-level limit. However, it does not explicitly state when to choose this tool over alternatives or include exclusions about sibling 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, the description carries the full behavioral burden. It usefully discloses the breadth of returned data and the paused/retired readability trait, but says nothing about permissions, auth requirements, rate limits, or cost of access.

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?

Effectively two sentences, front-loaded with the action and identifier. The long field enumeration is dense but earns its place by substituting for a missing 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 does the work of describing return contents (schemas, price, SLA, verification/repair history, uptime, freshness, ownership, comparable prices, clearing data). Combined with full schema coverage for inputs, an agent has what it needs; only auth/limit context 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?

Schema description coverage is 100%, so both parameters (capability_id, agent_key) are already documented in the schema. The description's 'by id' phrasing echoes the schema without adding format or constraint detail, 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 ('Read one capability by id') and enumerates the returned contract data, which separates it from capabilities_list (multiple) and capability_call (invocation). It never names those siblings explicitly, but the singular-by-id framing is clear enough to route correctly.

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 explicit when-to-use or when-not-to-use statement, and no alternative tool is named. The sentence 'Schemas stay readable when calls are paused or retired' does imply a useful usage context (inspect even when not callable) but stops short of 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose that capability.repair.started entries with repair_bounty_id and public_at are surfaced, but says nothing about read-only safety, whether reads are idempotent, auth requirements beyond the schema keys, or 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?

Two short sentences, front-loaded with the core purpose, with no filler. The second sentence is somewhat tangential but still compact.

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 should explain the read semantics, auth expectations, and what fields are returned. It gestures at entry types but leaves the operational picture incomplete, and the supplier-agent sentence adds confusion rather than completeness.

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% for both api_key and agent_key, so the schema already explains the parameters and the description adds nothing about them. Baseline 3 applies when structured fields do the heavy lifting.

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 price-change notices') with scope ('for capabilities this buyer called recently'), which is clear enough to distinguish from generic notice tools like agent_notices. However, the second sentence switches audience to 'a supplier agent' and to a different entry type (capability.repair.started), muddying whether this tool is buyer-facing or supplier-facing.

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

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

No explicit when-to-use guidance versus the many notice-adjacent siblings (agent_notices, agent_notices_ack, capability_get). The only implicit cue is 'capabilities this buyer called recently', which hints at context but does not tell the agent when to prefer this over alternatives or whether acknowledgement is needed.

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

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

With no annotations, the description carries the full burden and does well: it discloses the one-to-one accepted-final/capability constraint, the endpoint_unverified error path returning verification paths and an identity document, and the brought_demand rail behavior. It stops short of stating reversibility, permissions beyond key ownership, or rate limits, so it is strong 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?

Purpose is front-loaded in the first clause, and the prerequisite sequence is compact. The closing brought_demand sentences are useful but make the entry dense enough that a reader must parse several independent concerns in one block.

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 14-parameter mutation with no annotations and no output schema, the description supplies the workflow, error handling, and sibling routing an agent needs to call it correctly. The main gap is field-level meaning for several required parameters that the sparse schema does not cover.

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 only 36% across 14 parameters, so the description must compensate. It covers price_credits (supplier-set), SLA, endpoint, protocol, and engine, but says nothing about slug, category, machine_spec, source_id, or the required input/output schema shapes, leaving roughly half the parameters meaningfully undocumented.

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 ('Register') and resource ('a callable contract from an accepted final submission') and enumerates the payload fields (behavior, schemas, price_credits, SLA, endpoint, protocol, engine). It explicitly distinguishes itself from capability_version_publish, which handles later changes, so an 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?

Gives explicit when-to-use (after an accepted final), the owning-key prerequisite, and the sequencing of agent_endpoint_set, well-known publishing, and agent_endpoint_verify. It also names the alternative for subsequent edits (capability_version_publish), 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 behavioral burden and does disclose non-obvious traits: callers receive a durable notice, the effective_at 30-minute lead requirement for price changes, and that each version states its own engine rather than inheriting it. It omits auth/permission requirements and what happens to superseded versions, so it is strong but not complete.

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

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

Three dense sentences with no filler; the core purpose and the two critical rules (lead time, engine non-inheritance) are front-loaded. Slightly terse given the twelve-parameter surface, but every sentence 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 12-parameter mutation tool with 9 required fields, no annotations, and no output schema, the description covers key behavioral rules but leaves most parameter semantics and any post-publish result expectations unaddressed. Adequate but with clear gaps.

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 only 33%, so the description must compensate. It adds real meaning for effective_at (30-minute lead on price changes) and engine (not carried over, retirement triggers notice and recertify deadline), but says nothing about the other undocumented params such as endpoint, protocol, machine_spec, input_schema, output_schema, price_credits, or sla_seconds.

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: 'Publish a new supplier-owned contract version.' An agent can distinguish this from capability_register, capability_get, or capability_call without opening a schema, though no sibling is named explicitly 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?

Usage is implied rather than stated: it describes a rule for price changes (effective_at at least 30 minutes ahead) but never says when to choose this tool over capability_register or when republishing is appropriate. No when-not guidance or prerequisites are 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. It discloses that the operation is read-only in nature and that the check pack is public, and it notes that the result includes available versions. However, it does not cover rate limits, authentication requirements, error behavior, or output shape in detail.

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 front-loaded sentence with no filler or redundancy. Every phrase contributes to identifying the resource and the operation.

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 tool with no output schema and no annotations, the description is minimally adequate: it identifies the main resource and mentions version listing. It remains thin on slug semantics, output structure, and operational constraints, which leaves gaps given the missing structured coverage.

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%: check_pack_version is documented in the schema, but check_pack_slug has no description there. The tool description does not compensate by explaining the slug's format, origin, or semantics, so parameter meaning remains incomplete.

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: 'Read one public check pack version and the list of available versions.' It distinguishes reading a single version from a broader pack list, though it does not explicitly name or differentiate against sibling tools such as check_packs_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?

There is no explicit guidance on when to use this tool versus alternatives, nor any stated preconditions or exclusions. The read-oriented phrasing implies a retrieval use case, but the agent must infer that 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?

No annotations are provided, so the description carries the full behavioral burden. It implies versioning ('publish the next version') but says nothing about permissions, whether re-registration overwrites, idempotency, whether published packs are immutable, or what happens to prior versions.

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 efficient sentence with the primary action front-loaded and no filler. It is under-specified rather than bloated, so brevity here is not a strength it fully exploits.

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 6-parameter, 5-required mutation tool with no annotations and no output schema, the description omits required-field meaning, the format of criteria, the role of agent_key, and publication side effects. It is far from complete enough for an agent to call it confidently.

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 17% (only agent_key is documented), and the description mentions none of the six parameters, including required ones like slug, criteria, and description. It does not compensate for the large schema gap, leaving most inputs undocumented anywhere.

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 specific verbs (create, publish a next version) against a clear resource (check pack), and distinguishes the two modes of operation within the tool. It does not name or contrast with siblings like check_packs_list or check_pack_get, and leaves 'check pack' itself undefined.

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?

Implied guidance via the two modes: supplier-authored creation vs. publishing a next version of a pack you own. There is no explicit statement of when this is preferred over alternatives such as criteria_draft or gate_pack, nor any 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 the full burden of behavioral disclosure. It implies a read-only listing but does not mention authentication requirements, pagination behavior, rate limits, or whether results are filtered or sorted, leaving significant gaps for an agent to invoke correctly.

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, front-loaded sentence that states the core purpose without any redundant or wasteful content. It is optimally concise for a simple list operation.

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 is minimally adequate but leaves out several contextual details an agent might need, such as whether the list is paginated or what fields each pack entry contains. It covers what is listed but not how to interpret or invoke the result fully.

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 per the scoring rules, a 0-parameter schema sets the baseline at 4. The description appropriately adds no parameter detail, and nothing is needed beyond the 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?

The description states a specific verb ('List') and resource ('reusable public acceptance-check packs and their current versions'), clearly distinguishing the action from singular retrieval tools like check_pack_get. However, it does not explicitly name an alternative or clarify the boundary with sibling get/register tools, so it lacks full sibling differentiation.

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 offers no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states what is listed without any conditional or contextual cues for selection.

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

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

With no annotations, the description carries the full burden and does so well: it discloses the side effect ('Nothing is stored unless save is true, which returns report_url'), the possible outcomes (pass/fail/could_not_verify), the conditional payloads on failure (rework.api, settlement), rate limits (20 free checks/month, 500 rows each), and the 402 failure mode with payable terms.

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 dense and front-loads the core verb and the input modes before the version-resolution rule, output states, and billing limits. Every sentence carries information, though the middle sentences are long and packed with parenthetical asides that slow reading for a 14-parameter call.

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 tool with no output schema, the description supplies return values, side effects, failure payloads, limits, and version-pinning rules, which is close to complete. Minor gaps remain: it does not restate the authentication requirement for contract_id (only the schema does) and says nothing about the source_context requirement beyond the schema text.

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 86%, so the baseline is 3; the description earns above that by explaining cross-parameter behavior the schema only implies, such as how check_pack_version resolves via bounty_id and how report_token reuses the saved criteria structure and origin. It adds interpretation rather than restating field 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?

It states a specific verb and resource ('Privately check a received file against a template, plain-word requirements...') and enumerates the six input modes, which makes the tool's scope immediately clear. It stops short of naming or differentiating its nearest siblings (vendor_check_request, vendor_check_status, criteria_draft), so it lands at 4 rather than 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 real conditional guidance: check_pack_slug without check_pack_version uses the version pinned by bounty_id, otherwise the current version, and report_token 'adds a rerun delta'. It also states when storage occurs (save=true) and when a 402 is returned. There are no explicit when-not or sibling-alternative statements, so it is clear context without exclusions.

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

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

With no annotations, the description carries the full behavioral burden. It discloses key operational behavior: recovery auto-accepts only when all blocking machine checks pass, otherwise waits for buyer approval, and the monthly cap and kill switch are rechecked before reserved balance is captured. It still omits permissions, idempotency semantics, and exactly what the kill action destroys.

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 front-loads purpose and behavior, then uses an efficient action-to-endpoint mapping. It is dense with semicolon-separated technical details, but for a five-action tool most sentences earn their 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 five actions, no annotations, no output schema, and very low schema description coverage, the definition supplies important behavioral and action/body context. It still leaves authentication, many shared parameters, and mutation side effects undocumented, so an agent cannot resolve every call detail from the definition alone.

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 9%, so the description must compensate. It does add meaning for the action values mapped to HTTP methods and for body fields in configure and recover, such as enabled, monthly_cap_usd, callback_url, failed_input, budget_usd, and idempotency_key. But required fields like agent_key and many shared schema properties remain unexplained.

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 set (read, configure, invoke, kill) and resource (unattended recovery for a saved contract), and enumerates the five supported actions. It makes the tool's scope clear, though it does not explicitly distinguish itself from sibling tools such as contract_rerun or unattended_policy.

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 maps each action to an endpoint, which implies when each action should be used, and explains the conditional auto-accept versus buyer-approval behavior. However, it gives no explicit when-to-use guidance against alternatives and no exclusions for when this tool should not be selected.

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 the default attachment-copy behavior and the override rule, and that the run snapshots the latest accepted spec/checks/price, but it says nothing about idempotency behavior on repeated keys, authentication needs, or the funding timing consequences of posting.

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 the action and scope before the attachment caveat. No filler; every clause carries information.

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

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

For a mutation tool with no annotations, no output schema, and 40% parameter coverage, this is thin. An agent still cannot tell what happens on duplicate idempotency keys, whether prior runs' state is affected, or what the call returns on success.

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 only 40% (2 of 5 params documented), and the description's only parameter detail (carry_attachment_ids default) merely restates what the schema already says. agent_key, bounty_id, and especially idempotency_key — behaviorally important for a posting operation — are unexplained in both places.

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 ('post a new run of an accepted saved contract') and clarifies what the new run inherits (latest accepted spec, checks, price). It is distinguishable from most siblings, though it never explicitly contrasts itself with the closely named procurement_contract_run or contract_recovery.

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: this is for re-running an existing accepted contract rather than posting a fresh one. The precedent condition ('accepted saved contract') is stated, but there is no explicit when-not-to-use guidance and no pointer to alternatives such as procurement_contract_run or bounty_post.

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 is a read operation ('List'), but the description never says whether it is safe, whether it requires authentication, whether results are paginated, or what happens for an agent with no contracts. The recurrence sentence describes a sibling tool's purpose, not this tool's 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?

The first sentence is efficient and front-loaded. The second sentence about create_recurrence is tangential to a listing tool and competes for attention without serving the primary action.

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-list tool with no output schema and no annotations, the description is minimally adequate: it says what is listed and that a balance is included. It omits authentication expectations, pagination, and the format of the balance and contracts, leaving gaps an agent may hit at call time.

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

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

There is one parameter, agent_key, with 0% schema description coverage. The description does not mention it or explain how the requester is identified. However, with only one required key and a self-evident name, the baseline for a single-parameter tool keeps this at 3 rather than lower.

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 (List) and resource (this requester's accepted saved contracts) plus a secondary output (bounty balance). This distinguishes it from siblings like bounties_list (open opportunities) and contract_recovery/contract_rerun, though the distinction is by scope word 'accepted saved' rather than an explicit contrast with 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?

There is no statement of when to use this tool versus alternatives such as bounties_list, contract_recovery, or requester_dashboard_get. The only implicit guidance is the possessive 'this requester's', which an agent must infer.

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 usefully discloses that the tool creates editable output and does not check or store a delivery, but it omits auth requirements, idempotency behavior, and any rate/permission context for what is effectively a state-creating 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?

Compact and front-loaded, leading with the primary purpose before the endpoint mapping. The endpoint/body fragment is terse and the whole thing avoids 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 complex tool with 11 parameters, nested body object, no output schema, no annotations, and near-zero schema coverage, the description is far too thin. An agent lacks enough to invoke it correctly beyond the endpoint mapping.

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 9% across 11 parameters, so the description must compensate but largely does not. It mentions only 'body: need; optional columns', leaving the other parameters (token, handle, idempotency_key, etc.) undocumented anywhere.

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 (draft) and resource (editable machine checks from requirements and column names), and adds the distinguishing scope that it happens 'without checking or storing a delivery'. It is a clear purpose, though it does not name a specific sibling it competes with among the large toolset.

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 phrase 'without checking or storing a delivery' implies this is the draft-only variant versus a checking/storing operation, giving implied usage guidance. However, no alternative tool is named and no explicit when-to-use/when-not condition is 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?

No annotations and no output schema, so the description bears the full transparency burden, yet it discloses nothing about pagination (cursor/before/limit), result ordering, or that reads are non-destructive. 'Active' hints at filtering but is never defined, so an agent cannot predict the result set.

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 front-loaded sentence with zero filler. It is efficient, though the brevity is arguably the source of the missing detail rather than a deliberate trade-off.

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 5 parameters, no annotations, no output schema, and 0% schema coverage, the description is far too thin to let an agent invoke the tool correctly. Pagination semantics, view selection, and the meaning of agent_key are all 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 description coverage is 0% across 5 parameters, so the description must compensate, but it only loosely gestures at 'view' (assignments vs submissions) and says nothing about limit, before, cursor, or agent_key. An agent gets no meaning for three of the five parameters from either source.

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 (List) and resource (this agent's assignments or submitted work), which an agent can distinguish from unrelated siblings like bounty_* or capability_*. It does not reference the closest related sibling (siblings list has no directly overlapping tool), so full sibling differentiation is unexercised but the purpose itself is 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?

There is no guidance on when to use this versus related tools such as check_received_work, submission_candidate_get, or agent_earnings_get, nor any prerequisite or scope conditions. The description merely asserts what it returns, leaving the choice entirely 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 full behavioral burden, yet it discloses almost nothing beyond routes: it does not say whether install mutates or stores credentials, what auth the call requires, whether escalate is irreversible, or what happens to the buyer balance. The only behavioral hint is the budget and public_input_acknowledged requirement for escalate, which is thin for a tool with three write-capable 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 action-to-endpoint mapping is front-loaded and the sentence count is minimal, with no filler. The compressed semicolon syntax is terse to the point of being hard to parse, but every clause carries actionable routing or field 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 11 parameters, a nested body object, no annotations, and no output schema, the description covers only endpoints and the escalate body fields. It omits auth/credential parameters, the read and install schemas, and any notion of what a successful call returns, which is a significant gap for a multi-action 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 9% across 11 parameters, so the description must compensate, and it does partially by enumerating the escalate body fields (need, budget_usd, callback_url, idempotency_key, public_input_acknowledged, optional via_integration). However, it says nothing about the other flat properties (token, handle, agent_key, wanted_id, transfer_id, delete_credential, payment_signature) or how they map to read/install, leaving most parameters undocumented in both places.

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 (fallback wiring) and enumerates three distinct modes with their HTTP verbs and paths, so the agent knows exactly what read/install/escalate do at a transport level. It does not distinguish itself from any sibling tool, and the oddly-phrased 'open a fixed-price fallback order within the buyer balance' is the only semantic gloss on 'escalate'.

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 three actions are listed with their endpoints, which implicitly tells the agent which action maps to which operation, but there is no guidance on when to choose escalate over a sibling like request_escalate or redelivery, and no prerequisites or exclusions are stated. Usage must be inferred from the endpoint list 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?

No annotations are provided, so the description carries the full behavioral burden. Implicit read-only semantics come from 'Read', but nothing is said about which credential (agent_key vs api_key) is required, whether results are paginated, scoped by time, or what happens if the caller is not a funder. This is a significant gap for a tool with zero annotation coverage.

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

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

A single front-loaded sentence with no filler; the resource and scope are stated immediately. It is appropriately sized, though the brevity comes at the cost of missing details rather than being efficiently complete.

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 read tool with no output schema and no annotations, the description leaves key call-time questions unanswered: which credential form is expected, whether the identity must be a registered funder, and what the accrual results represent. The identity scoping note is useful but insufficient 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 description coverage is 0% and neither 'agent_key' nor 'api_key' is referenced in the description. The only hint is 'the calling funder identity', which weakly implies the credential determines the funder scope, but it does not explain the oneOf requirement or which key applies in which situation.

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 clear verb ('Read') and a specific resource ('royalty recovery and credit accruals') scoped to 'the calling funder identity'. An agent can tell this apart from generic read tools like balance_get or agent_earnings_get. However, it does not explicitly name a sibling or contrast the royalty domain with those adjacent money-related readers.

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, no prerequisites, and no mention of alternatives such as agent_earnings_get or balance_get. The phrase 'for the calling funder identity' implies the caller must be a funder, but this constraint is not framed as a usage condition or exclusion.

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 behavioral burden. It does not disclose that register is an authenticated write, whether it is idempotent, what permissions or credentials are needed, whether registration is reversible, or what the response contains. With 11 parameters and a nested body, this is a significant gap.

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

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

The action-prefixed format (list/author/register with their endpoints) is front-loaded and efficient, with no filler sentences. It packs a lot into few lines, though the body-field list compresses heavily.

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 11-parameter, multi-action tool with a nested body, no output schema, and no annotations, the description covers only the three action routes and part of the register body. It omits auth expectations, return shape, and the meaning of most parameters, leaving the agent under-informed for a mutation action.

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 9%. The description compensates partially by listing the register body fields (title, description, checks, optional holdout_checks), but leaves token, agent_key, id, idempotency_key, wanted_id, transfer_id, delete_credential, and payment_signature entirely undocumented in either place.

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 specific verbs and resources (list, register, read author) and maps each to a REST endpoint, so the three modes are legible. However, it does not distinguish itself from nearby siblings like check_packs_list, check_pack_register, and check_pack_get, which appear to 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?

It implies selection by naming the three actions and their endpoints, but never states when to choose list versus author versus register, nor any exclusions or prerequisites (e.g. that register requires agent_key). Usage is inferable from action names rather than explicit 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?

With no annotations, the description carries the full burden. It does disclose two real traits: results are capped at 8 and each row is dated and attributed, which tells the agent the output is time-scoped and provenance-tagged. It omits permission requirements, what happens when no run exists, and whether the sample is deterministic.

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 with the core scope ('up to 8 sample rows from the last run') front-loaded and the alternative pointer last. Nothing is padded, though the phrasing is clipped enough that some meaning requires inference.

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, no-output-schema, no-annotation tool, the description covers what is returned and its limits but leaves the required 'source_id' undefined and does not clarify how a source or its 'last run' is identified. Adequate but with real gaps.

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% — 'limit' is documented (default 8, max 8) and the description's 'up to 8 sample rows' corroborates that cap. 'source_id' is undocumented in both schema and description, so the description only partially compensates for the coverage 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 states specifically what is returned: a capped sample (up to 8) of rows from the last run of a named source. That is enough to distinguish it from list_sources and get_source, though it never names a retrieval verb explicitly and the title ('Take the rows from a source') is clumsy.

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 one routing hint: for more than a sample, use the REST rows endpoint with an instant free key. That is a useful fallback cue, but it does not explain when to prefer this tool over siblings or what preconditions (valid source, prior run) apply.

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 behavioral burden. It usefully discloses the payload contents (status, contents, dates, limits), which partially substitutes for the absent output schema, but says nothing about permissions, error behavior when the id is unknown, 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?

A single front-loaded sentence with no wasted words; the purpose and return contents arrive immediately. It is efficient, though it could be marginally reorganized to lead with the action.

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 partially compensates by listing returned fields (status, contents, dates, limits). However, it omits parameter format and usage routing, leaving real gaps for a tool with a 0%-covered required parameter.

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?

One parameter (source_id) with 0% schema description coverage, and the description gives no format, source, or valid-value guidance for it. The description's phrase 'one source id' only restates the parameter name rather than adding 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 ('Read') and resource ('one source id') and enumerates the returned fields (status, contents, dates, limits). It distinguishes itself informally from the neighboring list_sources by specifying a single source, though it does not name that sibling 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?

There is no stated when-to-use or when-not-to-use, and no mention of the obvious alternative list_sources for enumeration. The agent must infer that this is a by-id lookup rather than a listing operation.

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 behavioral burden. It describes output fields and an empty-state routing behavior, which is useful, but it never states whether this is read-only, whether it requires authentication, pagination behavior, default limits, or whether counts are live or cached. For a no-annotation tool, that leaves important behavioral 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?

Two sentences, front-loaded with the core action and return dimensions, then the empty-result guidance. The second sentence is dense but structured as a conditional followed by three named actions. Slight compression could improve readability, but it is efficient.

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 4-param list tool with no annotations and no output schema, the description covers what the tool returns and how to handle an empty result, but omits authentication/permission expectations, pagination limits beyond the schema default, and when this tool should be chosen over siblings like get_source or bounties_list.

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 75%, so most parameters are already documented in the schema (limit, query, bundle, status). The description reinforces the query semantics ('Free text, e.g. ...') and the notion of matching nothing, but adds little parameter-specific syntax or constraints 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 clear verb and resource: 'Search or browse maintained sources' and enumerates the dimensions returned (coverage, last-read time, row count, count-check method, status). It is distinguishable from list siblings, but it does not explicitly contrast with get_source or bounties_list, which slightly weakens differentiation.

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 strong guidance for the empty-result case ('When query matches nothing, next says what to do') and names concrete next-step tools (request_source, open_pot, bounty_post). However, it does not state when to prefer this tool over get_source, or when to combine it with bounties_list/search_mcp_directory.

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 real behavioral rules: a seat is never charged above max_share_cents and the cycle is skipped, accepted payouts wait 48 hours for disputes, founding royalties need a completed founding-cycle payment, and underfunded cycles post no work or extra charges. It still omits auth/permission requirements and what each action returns.

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 overall purpose and constraints are front-loaded before the action-by-action endpoint/body breakdown, which is dense but organized and largely free of filler. The single long paragraph is information-rich rather than padded, though some Helm-style rules could be tightened.

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 six-action tool with 11 parameters, no annotations, no output schema, and low schema coverage, the description covers workflow semantics well but leaves gaps: return shapes, error/edge behavior, and the meaning of roughly half the parameters are unaddressed, so an agent cannot fully operate it from this text alone.

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 9% across 11 parameters, so the description must compensate. It does document the key body fields (recurrence_id, title, attribution_ref, max_share_cents, dispute {cycle, reason}), but several parameters (token, handle, delete_credential, idempotency_key, wanted_id, transfer_id, payment_signature) get no explanation anywhere.

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 precise verb+resource enumeration (create/read a shared data feed, subscribe a seat, change max share, dispute a cycle, leave) and names the concrete endpoints, so the opaque name 'maintenance' is fully disambiguated. It does not, however, relate itself to any sibling (e.g. recurrence, settlement), leaving the agent to infer boundaries.

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?

Per-action prerequisites are spelled out: create requires an active, monthly, balance-funded monitoring_alerts recurrence you own, and subscribe's max_share_cents must be at least the current seat price. That is clear context for each action, but there is no explicit when-not guidance or routing to an alternative 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?

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavior: the grace-period precondition, the five-measured-run threshold, the meaning of the house field, and that house groups are per-lane with engine null. It omits auth requirements, whether recertify is reversible, idempotency expectations (despite an idempotency_key param), and the mixed read/write nature is only implied by the HTTP verbs.

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 sentence is a dense run-on that front-loads domain-specific clauses before stating the tool's actions, hurting comprehension. The action-to-endpoint mappings are useful but appended rather than structured. Information density is high but organization is poor, so sentences do not cleanly earn their 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 complex multi-action tool with 11 parameters, nested body object, no annotations, and no output schema, the description is only partially sufficient. It covers the three actions and the recertify payload well, but omits return-value expectations (no output schema to fall back on) and leaves most of the shared parameters undocumented. It is more complete than a bare endpoint list but not adequate 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 description coverage is very low (9%) across 11 parameters, so the description must compensate. It does enumerate the recertify body fields (endpoint, protocol, input_schema, output_schema, machine_spec, price_credits, sla_seconds, engine, optional sla, effective_at) and explains what engine means, which is valuable. But it leaves token, handle, agent_key, wanted_id, transfer_id, idempotency_key, delete_credential, and payment_signature entirely unexplained.

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 lists three distinguishable actions (status, pass_rates, recertify) with their HTTP methods and paths, which helps an agent map the tool's scope. However, the opening sentence is a run-on that buries the actual purpose in domain jargon ('house field', 'after grace with at least five measured runs'), so a reader cannot quickly state what the tool does. It is action-scoped but not clearly framed.

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 explicit guidance on when to choose this tool over siblings like capability_version_publish or capability_register, even though recertify clearly overlaps with version publishing. Some conditional context exists ('after grace with at least five measured runs') but it reads as a data qualifier, not a routing rule. An agent gets no when-to-use vs when-not-to-use signal.

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

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

With no annotations provided, the description carries the full behavioral burden, yet it discloses little beyond the action. 'Return its verification status' hints at a synchronous verification response, but it omits whether submission is idempotent, what determines success/failure, permission requirements, or what happens to a previously submitted artifact. This is thin for a mutation-style tool with zero annotation coverage.

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

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

A single front-loaded sentence with no filler. It is efficient, though arguably under-specified rather than genuinely concise given 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 submission tool with no annotations, no output schema, and 67% of parameters undocumented, the description leaves major gaps: the meaning of 'verification status', auth expectations, and the required agent_key are all unaddressed. It is not complete enough for an agent to call it confidently.

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 33% - just the optional 'handle' param is documented, while the two required params (public_url, agent_key) are bare. The description clarifies that the URL is a 'public agent-profile artifact URL', adding marginal meaning for public_url, but says nothing about agent_key or how handle interacts with it. It fails to compensate for the low 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?

States a specific verb and resource: 'Submit one public agent-profile artifact URL'. The agent knows exactly what action is taken. However, it offers no differentiation from the numerous sibling submission tools such as submission_post, submission_candidate_get, or submission_reject, leaving the agent to guess which submission flow this belongs to.

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, no prerequisites, and no named alternatives. The only implicit signal is the word 'one' (single URL), which hints at a per-artifact scope but is not framed as usage 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?

With no annotations, the description carries the full load and does so well: it discloses the no-key path, the dual return branches (address + supplier-listed 402 price vs. machine contract with assumptions, ledger-only reference price, and a funding question), the auth requirements for funding, and the observable post-funding state (funding.mode=prepaid, non-null funding.funded_at). It does not mention rate limits or failure modes, keeping it short of a 5.

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

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

It is dense but front-loaded: the free path is stated first, then funding, then intake, then the funded-state invariant. Every sentence carries information, though the final sentence about funding.mode and funded_at is a niche detail that slows the close.

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-parameter, no-annotation, no-output-schema tool, the description is nearly complete: it explains the branching return values that an output schema would otherwise cover, plus auth and idempotency expectations. Only via_integration semantics and any error/permission behavior are left 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 60%, so the description must add meaning and it does: agent_key is 'required only with amount_usd', amount_usd is the funding trigger, and idempotency_key is paired with funding. The one gap is via_integration, which appears only in the schema and is never explained in prose.

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 ('send one demand sentence') and immediately explains the two possible outcomes: a capability address plus 402 price, or a machine contract. It is clear what the tool does, though it never names or contrasts against siblings like capability_call or bounty_post, so an agent must infer the boundary 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?

Usage is implied rather than framed: no key is needed for the basic send, and funding (amount_usd) requires agent_key plus idempotency_key. The 'when' for the funded vs. unfunded path is derivable from the sentence, but there is no explicit when-to-use-this-vs-alternatives guidance and no stated prerequisites for the 'validated contract' intake path beyond a passing clause.

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