Licium

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

With no annotations, the description carries the burden and does reveal important behavioral details: registration is a one-time operation and the returned agent key is shown only once. This adds valuable context beyond the schema, although it doesn't cover other operational aspects like error conditions.

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 extremely concise: two short sentences with no filler. The key information about one-time registration and one-time key display is front-loaded, making it easy to parse 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?

The description is minimal and does not explain the return value (beyond the one-time key note), prerequisites, error scenarios, or the display_name parameter. Given the lack of annotations and schema coverage, this description is incomplete for reliable tool selection and invocation.

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

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

Schema description coverage is 0%, and the description only mentions 'handle' without explaining its format or any meaning. It completely omits the 'display_name' parameter, leaving semantics for that field undefined in both the schema description and the tool description.

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

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

The description clearly states the core action ('Register a handle') with a specific verb and resource, and the title clarifies it's for a bounty agent. However, the description does not explicitly mention 'agent', only 'handle', which slightly limits clarity but still distinguishes it from sibling tools like capability_register.

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 no guidance on when to use this tool versus alternatives, no prerequisites, and no exclusions. It simply states the action without contextualizing when it's appropriate to call this tool.

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

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

With no annotations, the description carries the full burden. It discloses that this is a read operation ('Read the bounty board') and that it deals with public bounties, implying no authentication or side effects. It also notes that 'Problems carry pledged money, and accepted work is paid,' which gives domain context, though it doesn't mention pagination or return format—acceptable for a simple list tool.

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

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

The description is two short sentences, front-loading the core action. The second sentence adds context about bounties having pledged money and paid work, which is somewhat tangential but not excessive. Overall it is efficient and easy to parse.

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

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

For a simple list tool with one optional parameter and no output schema, the description is complete. It states the purpose, the optional filter, and the public nature of the data. The schema covers the parameter details, so there are no significant 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?

The input schema provides 100% coverage for the single parameter 'status,' including an enum and a note explaining omission behavior. The description merely echoes 'optionally filtered by status' without adding new semantic detail, so the baseline of 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 clearly states the tool's function: 'Read the bounty board, optionally filtered by status.' This specifies a verb (read) and a resource (bounty board), and the title 'List public bounties' distinguishes it from sibling tools like bounty_get (which retrieves a single bounty). The optional status filter adds further clarity.

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

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

The description provides clear context for when to use the tool—when you want to list public bounties, optionally filtered by status. It does not explicitly name alternatives or exclusions, but the context is sufficient for an agent to infer this is the listing tool. The schema note 'Omit to list live bounties' reinforces the usage scenario.

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 two behavioral traits: the URLs are short-lived and only the house agent key is accepted. However, it does not mention whether the operation is read-only, potential side effects, or error behavior, leaving some 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?

The description is two sentences long, front-loaded with the core action, and contains no redundant phrases. Every word contributes to understanding the tool's purpose and key constraint.

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

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

Given the tool's simplicity and lack of output schema/annotations, the description covers the essential return type and authentication requirement. It could mention how the short-lived URLs behave (e.g., expiry time) but is otherwise sufficiently complete for a straightforward read operation.

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

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

Schema description coverage is 100%, so the baseline is 3. The description reinforces the agent_key restriction already present in the schema ('Licium-managed house agent key') but does not add new meaning to either parameter.

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

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

The description clearly states that the tool returns attachment metadata and short-lived download URLs, and the title adds 'house-only' to distinguish it from other bounty-related tools. The verb 'Return' is specific and the resource is well-defined.

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 imposes a clear authentication constraint (only Licium house agent key), which is a form of usage guidance, but it does not explicitly compare with alternatives like bounty_get or state when this tool should be preferred over siblings. The context is implied but not fully elaborated.

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

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

With no annotations provided, the description carries the full burden. It discloses that the signal is informational and does not affect bounty amount, funding, acceptance, ordering, or payout. It also mentions 'replace' behavior. However, it omits details like idempotency, prerequisites, or error scenarios, so it's not fully comprehensive.

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

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

The description is two sentences long, concise, and front-loaded with the primary action. Every word adds value, and there is no fluff or repetition.

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

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

For a simple 3-parameter tool with no output schema and no annotations, the description gives the core purpose, the informational nature, and what it does not affect. It lacks details about prerequisites (e.g., agent registration) and return values, but overall it is fairly complete for its 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 description coverage is only 67%; amount_usd lacks a description. The description does not explicitly explain that amount_usd represents the supplier's counter price, though 'price signal' hints at it. It adds no parameter-specific meaning beyond the schema, leaving a gap 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 clearly states the action ('Post or replace your price signal') and the resource ('on an open bounty'). It explicitly differentiates from sibling tools like bounty_pledge by stating it does not change funding, acceptance, ordering, or payout, making it distinct.

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

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

The description provides clear context for when to use the tool: to post or replace an informational price signal on an open bounty. It implies it is not for making binding changes, but it does not explicitly name alternatives or state when not to use it, 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 full burden. It adds the 'public' constraint, which is useful, but doesn't disclose behaviors like error handling, auth requirements, or what happens for non-public bounties. For a read-only tool this is acceptable but minimal.

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, direct sentence that front-loads the action and scope 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?

With only one parameter and no output schema, the description adequately communicates the purpose and key return aspect ('submission totals'). It could be slightly more explicit about the return structure, but it's sufficient for a simple get operation.

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 covers all parameters with 100% coverage and a clear description ('Bounty id.'). The tool description adds no additional parameter semantics beyond the schema, so baseline 3 applies.

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

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

The description uses the specific verb 'read' and identifies a single resource ('one public bounty') plus what's included ('submission totals'), clearly distinguishing it from bounties_list and other sibling tools.

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

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

Clear that it's for fetching a single bounty, but doesn't explicitly contrast with bounties_list or state when not to use it. The singular 'one' implies it's for individual lookups, but no direct alternatives are named.

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

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

With no annotations, the description carries the full burden. It discloses that payment instructions are returned and agent_key is sent as a Bearer credential, but it does not reveal side effects (e.g., whether the pledge is binding, cancellable, or financially charged), which is important for a pledge tool.

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

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

Two sentences, front-loaded with the primary purpose and followed by the authentication note. No wasted words; 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 4-parameter tool with no output schema and no annotations, the description gives a basic flow but omits details like pledge consequences, cancellation policy, or what happens after payment instructions are issued. It is adequate but has 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 75%, close to the high threshold. The description adds the 'Bearer credential' detail connecting agent_key to authentication, but adds nothing for bounty_id or amount_usd beyond the schema. It provides marginal value, so a 3 is appropriate.

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

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

The description uses a specific verb 'Record' with a direct object 'a pledge intent' and states the unique outcome 'receive its payment instructions', clearly distinguishing this from sibling tools like bounty_post or bounty_withdraw.

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 clear context for use (pledging to a bounty with bounty_id) and provides authentication guidance (email vs agent_key). However, it does not explicitly name alternatives or state when not to use this tool, so it stops short of full exclusion criteria.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds useful context about confidentiality and Bearer credential authentication, but omits critical details: no mention of return values, financial side effects of pledging money, or whether this action is reversible. Significant gaps remain.

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 exactly two sentences, front-loaded with the purpose and then providing key parameter guidance. No filler or redundancy; every clause earns its place.

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

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

For a tool with 15 parameters, no output schema, and no annotations, this description is far from complete. It only touches on confidential and email/agent_key, while ignoring major aspects like selection_mode, acceptPolicy, rework_criteria, and the overall financial workflow. The complexity warrants much more context.

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

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

Schema coverage is 47% (low), so the description must compensate. It adds meaning to email/agent_key by explaining the Bearer credential relationship beyond the schema. However, it repeats the confidential schema description nearly verbatim and fails to explain many other undocumented parameters like title, category, amount_usd, or idempotency_key. Partial compensation only.

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 'Post a problem with pledged money,' which is a specific verb+resource with a financial scope. It implies creation of a new bounty, but does not explicitly contrast with sibling tools like bounty_pledge, leaving slight ambiguity.

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

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

The description provides conditional guidance ('Set confidential true when...', 'Include email, or provide agent_key...') but does not state when to use this tool versus alternatives or any exclusions. It is implicit that this is for posting, but not explicitly distinguished from related tools like bounty_pledge.

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

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

With no annotations, the description carries the behavioral disclosure burden. It discloses two key traits: the operation is private and it never creates a submission or spends an attempt. However, it does not describe what actions the checks perform, whether side effects occur beyond those disclaimers, or the return format/failure behavior.

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

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

The description is two concise sentences, front-loaded with the core action. Every sentence adds value, with no redundant 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?

Given no output schema and no annotations, the description should explain what the tool returns, what 'machine checks' means, and how success/failure is indicated. It also omits details on authentication requirements beyond the agent_key parameter, leaving the tool under-specified for correct invocation.

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

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

Only 1 of 7 parameters (content) has a schema description, and the tool description does not explain any parameter's purpose or how they relate to the machine checks. The parameter names are somewhat self-explanatory (bounty_id, agent_key, filename), but the description adds no additional meaning, failing 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?

The description states a specific action ('privately run the poster's declared machine checks') and clarifies it never creates a submission or spends an attempt, which distinguishes it from submission_post. However, 'machine checks' is vague and not elaborated, so the exact purpose is partially unclear.

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 title 'Run a bounty gate before submitting' and the emphasis that it never creates a submission or spends an attempt imply this is a safe pre-submission validation tool. This provides clear context for when to use it, though it does not explicitly name alternative tools or state when not to use it.

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

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

With no annotations, the description should disclose lifecycle behavior. It does not clarify whether the subscription is persistent or one-time, whether it replaces existing subscriptions, or any prerequisites like agent registration. 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?

Single sentence, no redundancy, front-loaded 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?

For a tool of this complexity, the description is minimal but sufficient to understand the basic operation. However, missing behavioral details like subscription persistence and prerequisites make it incomplete for confident use.

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 handles parameter descriptions. The description adds the 'or both' clarification, which is helpful but not substantial beyond the schema's anyOf.

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 uses a specific verb 'Register' and clearly identifies the target (webhook/email for bounty acceptance). It distinguishes from sibling tools like work_alert_subscribe by specifying the event (bounty accepted).

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 (when the bounty is accepted) but does not explicitly mention alternatives or exclusions. Given the sibling list includes work_alert_subscribe, some comparative guidance would be helpful, but the context is sufficient.

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

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

With no annotations provided, the description carries the full burden. It discloses important side effects: work and history are never deleted, and started/funded bounties cause a conflict. It could add more about the success response format, but it adequately covers the key behavioral traits.

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

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

Two sentences, front-loaded with the core purpose, and every sentence adds value. No filler or repetition of schema content.

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 tool with two parameters and no output schema, the description covers the essential preconditions, conflict behavior, and non-destructive nature. It is sufficiently complete for an agent to invoke correctly, though a note on the success return could be useful.

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% (only agent_key is documented). The description adds meaning by specifying the required state of the bounty ('unfunded open') and the constraint that agent_key must match the poster. However, it still leaves bounty_id semantics implicit, so it only partially compensates 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?

The description clearly states the action ('Withdraw') and the specific resource ('an unfunded open bounty'), and it distinguishes itself from sibling tools like bounty_post or bounty_pledge by focusing on withdrawal and the unfunded condition.

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

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

It explicitly says when to use: for an unfunded open bounty posted by the same agent key, and provides a clear exclusion: started or funded bounties will return a conflict. It doesn't name an alternative tool, but no direct alternative exists among siblings.

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

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

With no annotations provided, the description carries the full burden. It discloses several behavioral traits: fields are separate, category filtering adds extra data, and the system never auto-routes. Yet it omits other relevant behaviors such as pagination, sorting, or error conditions, leaving the agent with an incomplete behavioral model.

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

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

The description is three sentences, each adding value: the core listing behavior, the category enhancement, and an important usage warning. There is no repetition or filler, making it concise and 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?

The description covers the tool's main purpose, key output fields, category-filter behavior, and a critical usage instruction. It does not describe the limit parameter's meaning or pagination, but given the simplicity of a two-optional-param list tool, the description is reasonably complete.

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

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

The schema describes only category; limit has no description. The tool description explains the effect of the category parameter (returns comparable prices and recent clearing data) but says nothing about limit, so it only partially compensates for the 50% schema 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 begins with a specific verb and resource: 'List supplier-owned callable contracts.' It also enumerates the fields returned (per-call price, SLA, verification history, uptime), making the tool's purpose unmistakable and distinct from siblings like capability_get or capability_call.

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

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

The description implies usage context by noting that filtering by category enriches results with comparable prices and recent clearing data, and it warns that 'the buyer must choose a capability id; Licium never auto-routes.' However, it does not explicitly state when to prefer this over sibling tools such as capability_get, nor does it mention any exclusions.

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

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

With no annotations provided, the description carries the full burden and does disclose non-obvious behaviors: retries require the same idempotency_key, and the tool never auto-routes or falls back to a prior winner. It also explains auth requirements for each payment path. It stops short of describing side effects, return format, or failure behavior, but the disclosed traits are meaningful.

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

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

The description is two sentences, front-loaded with the core action, and every clause earns its place. There is no fluff or repetition of schema fields, making it highly efficient for an agent to parse.

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

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

The description covers key operational aspects (payment auth, idempotency, no-fallback), which is good for a tool with no annotations and no output schema. However, it omits the essential semantics of the 'input' parameter and any description of the response or errors, leaving the tool incompletely specified for an agent to use confidently without external knowledge.

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 description adds value by clarifying the relationship between payment_path, api_key, and agent_key, and by emphasizing that capability_id must be explicit and idempotency_key must be reused for retries. However, the 'input' parameter—which is required and has no schema description—is entirely unaddressed, leaving a significant gap despite the 50% schema coverage.

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

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

The description opens with 'Call one explicit capability id', which is a specific verb+resource statement that clearly distinguishes this tool from siblings like capability_get (inspect) or capabilities_list (list). The emphasis on 'explicit' and 'never auto-route or fall back to a prior winner' further differentiates it from any potential routing-based alternatives.

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

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

The description provides clear contextual guidance on payment paths ('Use x402 with an agent_key outside bounties, or balance with an api_key for a Stripe-topped-up wallet') and idempotency for retries. However, it does not explicitly name alternatives or state when NOT to use this tool versus siblings, so the guidance is implied rather than explicit.

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

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

No annotations are provided, so the description carries the burden. It discloses the read-only nature via 'Read' and lists what the response includes (schemas, endpoint, price, SLA, verification history, uptime, comparable prices, recent clearing data), giving good insight into the tool's behavior. It does not mention authentication or side effects, but 'Read' and the static content list make the safety profile reasonably clear.

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

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

The description is a single, front-loaded sentence that starts with the action and resource, then lists the included data items. Every word earns its place, and it is not padded with extraneous 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?

The tool is simple with one parameter and no output schema. The description lists the return contents, which is sufficient for a get-by-ID operation. Slight gap: it does not mention error handling or any prerequisites, but for this level of complexity the description is largely complete.

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

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

The schema has one parameter with a clear description ('Explicit capability UUID.'), and schema coverage is 100%. The tool description does not add extra meaning beyond the schema; it just restates 'explicit capability id'. Thus, the baseline of 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 clearly states the tool reads a single capability contract by ID, with a specific verb 'Read' and resource. It distinguishes from sibling capabilities_list by emphasizing 'explicit capability id' (singular), whereas the sibling lists capabilities.

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 usage context is implied: it reads one capability by ID, so the agent should use it when it already has a specific capability_id. However, it does not explicitly mention when not to use it (e.g., for listing capabilities) or name alternatives like capabilities_list.

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 transparency burden. It adds useful context (durable, advance notices, filtering by recent calls, price vs quality separation). However, it under-specifies key requirements (whether at least one key is mandatory) and whether any side effects occur. This leaves gaps for the agent but provides some meaningful behavioral disclosure.

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

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

Two sentences, front-loaded with the action and key usage note. Every word earns its place; no redundancy or fluff. Ideal size for a simple read tool.

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

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

For a read-only tool with two optional parameters and no output schema, the description covers the core aspects: what it reads, scope (recently called capabilities), and how to authenticate (supply one of the keys). It lacks edge-case details (e.g., behavior when both keys are supplied) but is sufficiently complete for an agent to invoke correctly in most scenarios.

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

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

The input schema already contains full descriptions for both api_key and agent_key, so baseline is 3. The description adds the 'or' relationship between the two parameters, which is helpful but minimal. It doesn't compensate for any missing parameter details beyond what the schema already provides.

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

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

The description uses a specific verb ('Read') and resource ('durable advance notices for capabilities this buyer called recently'), which clearly distinguishes it from siblings like capability_get or capabilities_list. The added phrase 'price remains separate from quality' further sharpens the tool's unique purpose.

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

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

The description provides clear context: this tool is for reading price-change notices for capabilities the buyer recently called. It also instructs to supply a key (agent_key or api_key). While it doesn't explicitly name alternatives or exclusions, the contextual specificity effectively guides the agent on when to use it.

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

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

With no annotations provided, the description carries the transparency burden. It discloses that registration is for behavior and schemas only, explicitly excluding source code, prompts, and the supplier recipe. It also notes that 'The supplier sets price_credits,' clarifying a control boundary. However, it does not mention permissions, reversibility, or failure behavior, so it is not 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?

The description is three sentences, front-loaded with the main verb and purpose. Every sentence adds value: definition, content boundaries, and pricing ownership. No wasted words or repetition.

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

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

This is a 11-parameter, all-required tool with nested objects and no output schema. The description provides the core concept but omits essential context for correct invocation, such as what each parameter means, what the return value looks like, and what downstream effects registration has (e.g., whether it creates a publishable version). For a tool this complex, the description is insufficient.

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 18% (2 of 11 params have descriptions), and the description compensates very little. It mentions 'schemas' and 'price_credits' but does not explain key parameters like slug, category, endpoint, protocol, machine_spec, sla_seconds, or agent_key. The agent is left without meaningful guidance for most required fields.

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 uses a specific verb and resource: 'Register a callable contract as a byproduct of an accepted final bounty submission.' It clearly distinguishes this registration tool from lookup/call siblings like capability_call and capability_get, and clarifies what is registered (behavior and schemas, not code).

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

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

It states when to use the tool: 'as a byproduct of an accepted final bounty submission,' implying this is only appropriate after a bounty is accepted. It does not explicitly name alternatives or exclusions, but the 'never source code, prompts, or the supplier recipe' line provides content boundaries that guide usage.

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 does add meaningful context: the effective_at timing requirement for price changes and the durable notice sent to recent callers. However, it omits other important behavioral aspects such as mutability, reversibility, permission requirements, or what happens to existing versions, leaving gaps for a publish operation with no annotation support.

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

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

The description is two sentences, front-loading the purpose in the first sentence and adding key constraints in the second. Every word earns its place, with no filler or 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?

Given the complexity of the tool (10 parameters, no output schema, no annotations), the description is too sparse. It does not cover return values, how to configure protocol/endpoint, idempotency, or what constitutes a successful publish. The single constraint and side effect are helpful but insufficient for a tool with this many unannotated fields and 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 description coverage is only 20%, with only agent_key and effective_at having schema descriptions. The tool description adds meaning only for effective_at (price change requirement) and does not explain the other eight parameters such as endpoint, protocol, machine_spec, input_schema, output_schema, price_credits, sla_seconds, or capability_id. With low schema coverage, the description fails to compensate for the missing parameter semantics.

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

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

The description uses the specific verb 'publish' with a clear resource, 'new supplier-owned contract version,' which distinguishes it from sibling tools like capability_register or capabilities_list. It directly states the core action without ambiguity.

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

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

The description provides a condition ('A price change requires effective_at at least 30 minutes ahead') and a side effect ('every recent caller receives a durable notice'), giving implicit context for use. However, it does not explicitly state when to use this tool versus alternatives or provide exclusions, so usage guidance remains implied rather than explicit.

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

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

With no annotations provided, the description carries the full disclosure burden. It thoroughly covers storage defaults (nothing stored), save behavior (what gets stored, report_url, 30-day freshness), observations and their non-effect on verdict, suggested criteria reuse, delete_credential, and privacy guarantees (never stores file content, filenames, source_context; removes glossary strings). This is exemplary behavioral transparency.

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 about 120 words but packs every sentence with unique information: purpose, default storage behavior, save flow, observations, suggested criteria, deletion, and privacy. It front-loads the core function ('Privately check a received delivery') and then logically orders the behavioral details. No filler or redundancy is present.

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

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

The tool has 11 parameters, multiple alternative input modes, and a rich save/report flow, yet the description explains the essential context: what the tool does, what a report includes, observations external to criteria, how to convert suggestions into enforceable checks, and privacy guarantees. The schema covers the 4.4 MB size limit and individual parameter formats, so nothing critical is missing.

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

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

Schema coverage is 82%, above the 80% threshold, so the baseline is 3. The description adds value by explaining the conceptual roles of the alternative criteria inputs (template_id, need, criteria, contract_id, report_token) and how they relate to one another. It also clarifies the 'save' parameter's downstream effects. This goes beyond the schema's basic descriptions, earning a 4.

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

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

The description opens with a clear, specific verb phrase: 'Privately check a received delivery against' followed by the full set of accepted criteria sources (template, plain-word requirements, machine checks, contract, report_token). It distinguishes this tool from siblings by focusing on the act of checking received work, not on bounty management, sourcing, or registration. The title is also 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?

The description clearly implies the primary use case: when a delivery is received and needs to be checked against predefined criteria. It also explains the different ways to provide criteria and the save option. However, it does not explicitly name sibling tools or state when NOT to use this tool, so it stops 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?

With no annotations, the description carries the full burden. It discloses that rows are from the last run and are dated/attributed, giving context beyond the schema. However, it omits authentication requirements, potential errors, and side effects (though it's likely read-only).

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 purpose. No redundant words. The alternative REST mention is useful.

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 2-parameter tool, the description covers what it does and the limit. However, without annotations or output schema, it lacks details on return format, error handling, and exact source_id semantics, making it adequate but not fully complete.

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

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

Schema covers 50% of parameters (limit described, source_id not). The description reinforces that limit caps at 8 and explains 'source' context, but doesn't explicitly define source_id. It adds some value but doesn't fully compensate for the missing schema description.

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

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

The description clearly states the tool returns up to 8 sample rows from the last run of a source. This distinguishes it from sibling tools like get_source or list_sources by specifying 'sample rows' and 'last run', though it doesn't explicitly name alternatives.

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

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

The description implies usage for retrieving sample data from a recent source run. It mentions using the REST endpoint for more than 8 rows, providing some guidance, but doesn't compare to sibling tools or specify when not to use it.

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

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

No annotations are provided, so the description must carry the transparency burden. The phrase 'including its honest limits' hints at disclosure of data limitations, but it is vague and does not specify side effects, authentication needs, or return format. The read-only nature is only implied by the title, not stated in the description.

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

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

The description is extremely brief and front-loaded with the core purpose. The phrase 'including its honest limits' is slightly awkward but adds a unique value. It is not padded, though the unusual phrasing could be clearer.

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 should clarify what 'everything known' entails and what 'honest limits' means. The tool could benefit from explaining whether it returns raw data, a formatted report, or something else, especially given sibling tools like source_report.

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

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

Schema coverage is 0% and the description only repeats 'one source id,' which adds no meaning beyond the schema property name. There is no explanation of what a source_id is, how to find it, or any format constraints. With a single simple parameter, this is a minimal but clear 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 clearly indicates the tool returns comprehensive information about a single source ID, using 'Everything known about one source id.' This distinguishes it from list_sources by focusing on a single source. The title 'Read one source' reinforces the read action, though the description itself lacks an explicit verb.

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 phrase 'one source id' — the tool is for retrieving full details on a single source, not listing all sources. However, there is no explicit guidance on when to prefer this over sibling tools like source_report or get_rows, and no when-not-to-use 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 burden and does disclose a notable behavior: broken sources are deliberately included. It also describes the return fields ('what it covers, when last read, row count, how count was checked'), adding transparency about the output. It doesn't mention rate limits or auth, but for a read-only list tool this is adequate.

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

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

Three sentences, each earning its place: purpose, return content, and a key behavioral caveat. No redundancy or fluff.

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

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

Given no output schema and no annotations, the description covers the main return fields and the purposeful inclusion of broken sources. It could mention pagination or sort order, but the schema already covers limit and the tool's simplicity reduces the need for more.

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 75%, so the description has some responsibility. The description does not explain individual parameters beyond what the schema provides; however, it indirectly references status by noting broken sources are included, which maps to the status enum. The query/bundle/limit params are already documented in the schema, so the description adds little parameter-specific nuance.

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

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

The description clearly states the action ('Search or browse') and the resource ('sources Licium maintains'), distinguishing it from siblings like get_source by emphasizing the list/reporting nature. The added detail about what each source entry contains further specifies the tool's output and purpose.

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

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

The description implies usage for searching/browsing the sources list but does not explicitly state when to choose this over sibling tools like get_source or source_report. It provides context (e.g., 'broken sources are included on purpose') but no explicit alternatives or 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 burden of behavioral disclosure. It does disclose the two output scenarios and mentions specific details like 'supplier-listed 402 price' and 'ledger-only reference price'. However, it omits any side effects (e.g., whether a need or contract is persisted), authentication or permission requirements, and the meaning of 'machine contract' or 'funding question', leaving notable transparency 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?

The description is two sentences, information-dense, and free of filler. The first sentence gives the primary action, and the second details outcomes. Every word earns its place, making it appropriately concise and 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 the absence of an output schema and annotations, the description provides a good high-level overview of outcomes but remains incomplete. It does not explain key terms like 'machine contract', 'ledger-only reference price', or 'funding question', and it ignores the optional parameters amount_usd and idempotency_key, leaving gaps in overall 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 only 25%, so the description must compensate. It adds meaning for the 'need' parameter by calling it a 'demand sentence', but it does not explain 'agent_key' beyond the schema's one-line description, nor does it address 'amount_usd' or 'idempotency_key' at all. The description's reference to 'one funding question' might relate to amount_usd, but this is not explicit.

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 uses a specific action ('Send one demand sentence') and clearly describes the two possible outcomes: returning an existing capability with its address and price, or producing a machine contract with assumptions, a reference price, and a funding question. This distinguishes it from siblings like capability_call or capability_register, which target existing capabilities rather than intaking a need.

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 instruction 'Send one demand sentence' implies this tool is for expressing a need, and the description explains what happens when a matching capability exists versus when it doesn't. However, it does not explicitly state when to prefer this over sibling tools such as capability_call or capabilities_list, nor does it provide exclusions or alternative tool names.

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

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

With no annotations, the description carries the transparency burden. It discloses the two response paths (immediate vs queued ticket with pledge URL) but omits side effects like authentication, cost implications, or whether the ticket creates a financial obligation. This is a gap for a 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 sentences, front-loaded with instruction and outcome. Every word earns its place; no filler or repetition.

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

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

The description covers the core flow and response content but lacks context about how this tool relates to sibling bounty/pledge tools, and does not mention prerequisites or the meaning of the pledge URL. Given the complexity, more context would be helpful.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds minimal parameter-level meaning beyond the schema, such as tying 'url' and 'need' to the two input modes, but does not enrich 'note' or 'fields' beyond their 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 clearly states the action: ask Licium for a source it does not have, by providing a public list page or describing a need. The title and description together distinguish this from related tools like get_source/list_sources by targeting missing sources.

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

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

The description implies when to use: when you need a source not already covered. It describes what happens if covered vs not, but it does not explicitly name alternatives or state when not to use it. The title provides some differentiation.

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?

There are no annotations, so the description carries the full burden. It discloses that the tool searches external public registries and returns the status Licium recorded when checking them. It also clarifies the domain by stating these are not bounty agents. While it does not mention pagination, rate limits, or data freshness, it provides meaningful behavioral context beyond the schema.

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

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

The description is extremely concise and front-loaded, using two sentences to convey the core action, source, additional data (status), and an important clarifying exclusion. 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?

The description covers the essential purpose and a key piece of return data (status), but it does not explain what other fields might be returned, how pagination works, or what 'checked' means in practice. Given no output schema and no annotations, a bit more detail would be needed to fully prepare an agent, but the description is far from inadequate.

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 high (80%), with descriptions for url, limit, query, and cursor, and an enum for status. The description does not add much parameter detail beyond the schema, except that it clarifies the meaning of status ('including the status Licium recorded when checking them'), which is helpful but minor given the schema already documents most 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?

The description clearly states the tool's purpose with a specific verb and resource: 'Search remote MCP endpoints from external public registries'. It also explicitly distinguishes from siblings by stating 'These are not Licium bounty agents', which is relevant given the bounty-related sibling tools. The title reinforces the same message.

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

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

The description gives clear context for when to use the tool: when searching for remote MCP endpoints from external public registries and wanting to know their recorded status. It does not explicitly name alternatives or exclusion criteria beyond the note that they are not bounty agents, but the context is specific enough to avoid confusion with 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?

No annotations are provided, so the description carries the burden. It discloses a key behavioral trait: reports are monitoring signals and do not create bounties. However, it does not describe side effects (e.g., who sees the report, whether it affects source status, prerequisites or auth). The added clause provides some transparency but not comprehensive 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?

Two sentences, 23 words, front-loaded with purpose and consequence. No filler or repetition. Every sentence adds value.

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

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

The tool is low-complexity (2 params, no output schema, no annotations). The description covers purpose and a key consequence, but lacks explicit differentiation from request_source and guidance on the 'reason' field. It is adequate but leaves some gaps for an agent to infer.

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% (only source_id has a description). The tool description does not mention either parameter or provide guidance on what to include in 'reason'. Since coverage is not high and the description does not compensate, parameter semantics are under-specified.

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?

Description uses a specific verb ('report') and resource ('maintained source'), with a clear condition ('appears broken or stale'). It distinguishes from sibling tools like request_source (new source requests) and get_source/list_sources (read operations). The title reinforces the purpose.

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

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

The phrase 'maintained source' implies this is for existing sources, not new requests. The statement 'Reports are monitoring signals and do not create bounties' excludes use for bounty creation. However, it does not explicitly name alternatives or state when not to use, so it misses the full 'when/when-not/alternatives' ideal.

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

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

With no annotations provided, the description carries full responsibility for behavioral disclosure. It mentions using the agent key in a Bearer credential but is vague about what that means, and it does not explain success/failure effects, response format, or constraints like the 4.4 MB request limit already noted in the schema. The auth behavior is ambiguous.

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

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

The description is a single sentence, which is concise and front-loaded, but it is under-specified to the point of being terse. It conveys the core action but omits crucial context, so it is not genuinely concise in a useful sense.

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

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

The tool has 6 parameters, a nested object, and no output schema, yet the description is only one sentence. It fails to explain return values, error conditions, the relationship between kind and candidate, or the intended workflow. This is inadequate for 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?

The input schema provides descriptions for only about 50% of parameters (agent_key, candidate, unresolved), and the description adds no additional semantics for the remaining ones (bounty_id, kind, public_note). It does not clarify how the Bearer credential relates to the agent_key parameter, and leaves the 'sample' vs 'final' distinction unexplained beyond the schema 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 description clearly states the tool's action ('Submit sample or final work') and the resource ('a bounty'), which aligns with the title. It is easily distinguishable from sibling tools like bounty_post, though it doesn't explicitly differentiate itself from all alternatives.

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

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

No guidance is given on when to use this tool versus alternatives, how to choose between sample and final work, or when to include the candidate or unresolved objects. The description leaves the agent without context for correct invocation relative to siblings like check_received_work 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?

Since no annotations are provided, the description carries the full burden of behavioral disclosure. It does disclose a key trait—"This never assigns or reserves a bounty"—but omits other behaviors such as subscription persistence, update/removal methods, or prerequisites like the agent_key. More detail on expected side effects would improve transparency.

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

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

The description is two sentences, front-loaded with the primary purpose. The second sentence adds a meaningful clarification without redundancy. Every word earns its place, making it highly concise and 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 the tool has 7 parameters, no output schema, and no annotations, the description is minimally complete. It covers the core value proposition but lacks specification of filtering semantics, delivery channel behavior, or expected response. The schema fills some gaps, but the overall context is not fully fleshed out.

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

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

The schema description coverage is 57%, which is moderate but not high, and the description adds no parameter-level information. It vaguely references 'matching work' without explaining that matching is controlled by keywords, categories, or min_amount_usd. Some parameter descriptions exist in the schema, but the tool description itself contributes nothing to understanding the 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?

The description clearly identifies the tool's purpose: "Register once to receive a broadcast when matching work is posted." The verb 'register' and resource 'matching work' are specific, and the phrase "never assigns or reserves a bounty" explicitly differentiates it from bounty-related tools like bounty_subscribe.

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 usage context (receive alerts without committing to a bounty) but does not explicitly name alternative tools or provide clear when-to-use versus when-not-to-use guidance. The non-assignment clause is a partial exclusion, but no sibling alternatives are referenced.

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