Corbah: open line for agents

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is fully covered by structured data and the description is not required to restate it. The description adds useful scope context (it exposes store data location, which is non-obvious), but says nothing about return shape, auth, or limits.

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

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

A single front-loaded sentence with no filler. It is slightly opaque because 'this line' and 'Jon' are used without anchoring the reader, but nothing is wasted.

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

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

For a zero-parameter, well-annotated informational tool with no output schema, the description covers what the caller will get back and needs no return-value documentation. Adding an explicit 'call this first' cue would close the remaining gap.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is no parameter semantics to clarify and the description correctly refrains from inventing any.

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 (Read) and enumerates three concrete things it returns: what the line is, what Jon wants to hear about, and where the store data lives. That is enough to distinguish it from action siblings like send_message or commission_design, though it does not explicitly separate itself from the semantically adjacent ask_corbah. The term 'line' is left 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?

Usage is only implied -- the content (orientation, preferences, data location) signals this is a first-call entry point, but the description never says when to call it or when to prefer ask_corbah instead. No prerequisites or exclusions are stated.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world, so the safety profile is covered. The description adds a real behavioral trait beyond them — 'It answers right away' — which tells the agent this is a synchronous Q&A rather than an async request that would need check_reply. It stops short of describing response shape or limits, so not 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?

Three short sentences, zero filler. The capability statement comes first, the timing note second, and the routing rule last — front-loaded and 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 one-parameter, read-only conversational tool with no output schema, the description covers topics, immediacy, and routing adequately. The only gap is that it never hints at what the answer looks like (free text, structured fields), which matters slightly more here because no output schema exists to carry that burden.

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 the single 'question' parameter, so the baseline is 3. The description adds meaning by enumerating what the question can be about (brand, sizing, made-to-order timing, custom kit, brainstorming), which sharpens how the agent should phrase the input beyond the schema's generic 'What you want to ask or discuss.'

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 ('Talk to Corbah's agent') and enumerates the domains it covers (brand, designs, sizing, made-to-order timing, custom kit, ideation). The final sentence explicitly separates it from send_message and commission_design, so an agent can route correctly without opening any sibling 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 both sides of the routing decision: use this for questions/discussion, and use send_message or commission_design for 'anything Jon needs to act on.' That is an explicit when/when-not with named alternatives, which is the top of the scale.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond them by disclosing that the catalog is 'live' and enumerating the returned fields (titles, USD prices, in-stock sizes, descriptions, images, URLs), which matters given there is no output 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?

Two tightly written sentences with zero filler. The core action and domain are front-loaded, and the return-value sentence follows immediately, so an agent gets both in one pass.

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

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

For an 8-parameter, zero-required search tool with no output schema and no annotations gap, the description covers the essential facts: it is a read-only live search, all filters are optional, and the return payload is enumerated. The remaining gap is pagination/default-limit behavior, which the schema only partially implies.

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 63%, so most parameters are documented in the schema itself. The description only adds the general note that filters are optional; it says nothing about pagination semantics for limit/offset (including the max of 50) or what include_unavailable changes, leaving the two undocumented parameters unclarified.

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 (Search/Browse) and resource (Corbah's live catalog), and scopes it to cycling jerseys, bib shorts, skinsuits and accessories. It implicitly separates itself from get_product (single item) and list_collections, but never names those siblings, 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?

'All filters optional' tells the agent the call is safe to make with no arguments, which is useful invocation guidance. However, there is no explicit when-to-use-this-vs-get_product statement or guidance on narrowing results when a query returns too many matches; usage is only implied by the browse-vs-lookup distinction.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is covered externally. The description adds the useful provenance detail that the reference and token come from a prior send, but says nothing about return behavior or whether the reply may be pending.

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 no waste; purpose comes first and the parameter hint follows. Nothing could be trimmed without losing 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 no output schema and no parameter descriptions, the description should do more than state intent. It leaves the response shape (boolean? message? pending state) and polling expectations unspecified, though the annotation set covers the read-only safety profile.

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 for two undocumented parameters. It does add provenance ('you got back' from the earlier send), but does not explain what the reference identifies (message vs. commission) or the role of the token.

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 (check) and a specific object (whether Jon has answered a message or commission you sent), which is unambiguous and clearly distinct from send_message or commission_design. It stops short of explicitly naming sibling tools, but the async-reply-check purpose is unmistakable.

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 agent must infer this is called after sending a message/commission. There is no statement of when to call it versus alternatives, how often to poll, or what to do if no reply yet exists.

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

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

Annotations cover the basic profile (write, not idempotent, not destructive, closed-world), and the description adds genuinely useful behavior beyond them: a human (Jon) reviews the request, the outcome arrives as a proof or quote on a private reply link, and no charge occurs on this call. It doesn't mention the callback_url follow-up flow, but the core async human-in-the-loop contract is 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?

Four short sentences, front-loaded with the action and audience, then the workflow and the cost reassurance. Each sentence earns its place, though the opening 'Ask Corbah to...' phrasing is slightly indirect for a tool named commission_design.

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

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

For an 8-parameter, no-output-schema tool, the description covers what the call does, who handles it, how the response is delivered, and that it's free. It leaves the callback_url notification path and the budget parameter unexplained, which the schema partially covers (88% coverage), so the picture is nearly 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 description coverage is 88%, so the schema already documents brief, items, deadline, for_whom, reply_to, and image_urls. The description only reinforces that the brief can carry 'any detail you have' and does not clarify the undocumented budget field or how reply_to interacts with the private reply link, so it adds little 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?

States a specific verb and resource: asking Corbah to design custom cycling kit, with concrete use cases (club, team, event, ride, person, idea). It is clearly distinguishable from generic siblings like ask_corbah or send_message by its design-commission framing, 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?

The description implies when to use it ('Describe what you want in any detail you have') and the use-case list signals the intended scenario, but there is no explicit when-not guidance or named alternative for someone who just wants a general question answered (e.g. ask_corbah).

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds real value beyond that by enumerating the returned payload (description, sizes/prices, availability, images, collections, ordering notes), which substitutes for the missing output 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?

One front-loaded sentence that names the operation, the key, and the payload, with no padding 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 simple read-only single-record lookup, the description covers purpose, key, and return content, and annotations cover the safety semantics. The only omission is explicit guidance on alternate discovery tools, which is minor given the straightforward scope.

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

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

With one parameter at 0% schema description coverage, the description does some compensating work by stating the lookup key is a product 'handle'. It does not clarify the handle format (slug vs. numeric id) or behavior on unknown handles, so it only partially fills 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 gives a specific verb-plus-resource ('Full details for one product by handle') and even enumerates what those details are, so the agent knows exactly what comes back. It does not explicitly contrast with siblings like browse_catalog or list_collections, but the 'one product by handle' scoping makes the distinction inferable.

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: 'by handle' signals you need a known product handle, and 'one product' implies a targeted lookup rather than browsing. No when-not conditions or named alternatives (e.g. browse_catalog for discovery) are given, leaving the agent to infer when this beats a catalog listing.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the shape of the payload (descriptions plus per-collection product counts), which is real added value, but says nothing about pagination, ordering, or filtering 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?

A single well-formed sentence with no filler, and the most useful content (what fields each collection carries) is placed up front. It is a noun fragment rather than a verb-led statement, which slightly weakens the opening.

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 zero-parameter, read-only listing with no output schema and full annotation coverage, describing the returned fields is the main requirement and it is met. The remaining gap is routing guidance against sibling catalog tools, which the description does not supply.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool is 4. No parameter syntax or defaults need explaining.

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 the specific resource (Corbah's collections and design series) and enumerates what each entry contains (descriptions, product counts), with concrete examples like Weekend Warrior and World Lines. It is clear what the tool returns, though it never states the action explicitly and does not name the sibling it differs from (e.g. browse_catalog, get_product).

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 browse_catalog, get_product, or about_corbah. The agent must infer that 'listing collections' precedes fetching a product, and no prerequisites, exclusions, or alternative routing 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?

Annotations mark it non-read-only and non-destructive, and the description adds the key behavioral fact: by default nothing is sent, and only send=true dispatches a real request to Corbah. It also discloses what the returned estimate means (a ceiling at Corbah's current store prices) and that Jon quotes the final team price, though it doesn't discuss idempotency or duplicate-send risk.

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 that front-load the purpose and then the return payload and the send branch. Every clause carries information, though the middle of the second sentence packs several return items that could read more cleanly.

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

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

With no output schema, the description correctly takes on the return-value burden: order summary, price estimate with its ceiling behavior, artwork approval deadline, and next steps. It also notes reply_to is needed when send=true. It doesn't cover behavior when no inputs are supplied (zero required parameters) or error paths, leaving a small gap.

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

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

Schema description coverage is 91%, so the schema already documents almost every parameter, including the send flag, design enum, piece keys and nested object. The description reinforces but rarely exceeds that (e.g. 'optional size split'), so 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 pair ('Plan and price custom kit for a club or team') and enumerates the exact inputs it captures (riders, pieces, optional size split, needed-by date). This clearly distinguishes it from siblings like commission_design and browse_catalog, which handle design work and catalog browsing respectively.

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 use — a team/club wanting a quote — and, crucially, explains the send=true vs default branch ('otherwise nothing is sent'). It stops short of naming alternative tools (e.g. commission_design for artwork-only work), so the agent must 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?

Annotations already declare the write profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so safety is covered. The description adds two useful behavioral facts beyond the schema: no format is required, and a reference plus private reply link are returned. It says nothing about rate limits, auth, or how the callback_url path behaves.

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 with no filler. The core action is front-loaded and the return-value note is appended where it belongs.

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, the description covers the action, format freedom, and the return contents, which is the minimum an agent needs. It omits routing guidance relative to ask_corbah and any explanation of the asynchronous callback behavior, leaving 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 100% and every parameter carries its own description, so the schema does the heavy lifting. The description's 'No format required' adds mild reassurance about the required message field but says nothing about from, reply_to, or callback_url beyond what is already documented.

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 destination (send a message to Jon, the founder) and enumerates what may be sent, so the action is unambiguous. It does not, however, distinguish itself from the sibling ask_corbah, leaving an agent to guess which of the two messaging tools applies.

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 lists acceptable message types but gives no when-to-use criteria, no prerequisites, and no comparison against ask_corbah or the other contact-style siblings. The agent gets content guidance but no routing guidance.

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

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

Annotations only give a coarse safety profile (not read-only, non-destructive, non-idempotent, not open-world). The description adds real behavioral context beyond them: the callback must be HTTPS, Corbah POSTs a JSON event to it, and a token is returned for later unsubscription. It does not describe delivery guarantees, retries, or failure handling.

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 purpose, then the mechanics, then the return value. Every sentence adds information; none is redundant.

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 purpose, the callback contract, and the return value. It is nearly self-sufficient, missing only lifecycle details such as event frequency or whether subscriptions expire.

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

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

Schema coverage is 0%, so the description must carry the parameter burden, and it does: callback_url is an HTTPS URL that will receive Corbah's JSON event POSTs. It adds a protocol constraint the bare string schema lacks. It does not state whether the URL is validated or whether non-HTTPS is rejected.

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 concrete verb+resource ('Get notified when Corbah releases new products') and immediately explains the mechanism (POSTing JSON events to a callback URL). This clearly distinguishes it from the sibling unsubscribe_updates, which it even references via the unsubscribe token.

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 purpose statement, but there is no explicit 'use this when you want X' guidance, no prerequisites, and no named alternative. The inverse sibling unsubscribe_updates is alluded to only indirectly through the returned token.

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

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

Annotations already declare the safety profile (readOnlyHint=false, idempotentHint=true, destructiveHint=false, openWorldHint=false), so the description need only supplement. It adds the token-source requirement, but does not say what happens after unsubscribing or whether the token is invalidated, which would have earned a higher score.

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 short sentence with the action front-loaded and the token dependency attached; no filler, nothing redundant.

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 one-parameter, no-output-schema tool whose annotations cover safety and idempotency, the description supplies the one piece an agent truly needs (token provenance). It stops short of describing post-unsubscribe state, which is a minor but real gap.

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

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

Schema description coverage is 0%, so the description must carry the one parameter's meaning. Saying the token comes from subscribe_updates tells the agent exactly where to obtain it, which is the key semantic for this parameter and compensates well for the undocumented 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 and resource ('Stop update notifications') and explicitly ties itself to its counterpart sibling, subscribe_updates, making the subscribe/unsubscribe pair unambiguous without opening either schema.

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

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

The token's origin ('from subscribe_updates') gives an implicit prerequisite and usage context, but there is no explicit when-to-use/when-not-to-use guidance or mention of alternatives among siblings such as check_reply or send_message.

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