CapabilityWire

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 clearly signals a read-only fetch and clarifies that the id parameter accepts either an id or slug, which is valuable. However, it does not mention behavior when the event is not found, whether fetching has any side effects (especially relevant given the mark_seen sibling), or what the response contains.

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 entire description is a single, front-loaded sentence with no filler. Every word earns its place, and the key information (operation, resource, and parameter interpretation) is delivered immediately.

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 single-parameter fetch, the description is adequate, but it leaves gaps: it does not describe the return value (no output schema is present), how to handle missing events, or how this relates to the sibling tools. The id-or-slug nuance is the only added context beyond the schema, and an agent might still wonder whether search_capabilities should be used first.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to the lone id parameter by stating it can be either an id or a slug, which is not evident from the plain string type in the schema. It could be even richer with examples or format constraints, but it gives the agent the essential disambiguation.

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 (Fetch), a precise resource (a single capability event), and a clear access method (by id or slug). It is immediately distinguishable from siblings such as list_recent_capabilities, search_capabilities, and mark_seen, which cover listing, searching, and mutating.

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 trigger condition: use this tool when you already have an id or slug for a specific capability event. It does not explicitly contrast with the sibling tools or state when not to use it, but the single-resource focus provides clear enough context for an agent to select it appropriately.

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 of behavioral disclosure. It conveys a read-only list operation and 'most recent' ordering, but it does not mention default limit behavior, how filters compose, or what the returned event shape looks like. It is not misleading, but it leaves room for ambiguity.

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, well-structured sentence that front-loads the main action and resource. Every part adds useful information, and there is 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?

This is a simple optional-parameter list tool and the description covers the core purpose and filtering options. Still, without an output schema, a brief note about return format would improve completeness, and there is no explicit guidance on when to choose this over search_capabilities.

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

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

Schema description coverage is only 33%, so the description must compensate. It mentions 'category' and 'since timestamp' and labels them as optional filters, adding some context beyond the bare schema. However, it does not explain the 'limit' parameter or clarify the expected timestamp format, relying mostly on the schema for that.

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 ('List'), a specific resource ('CapabilityWire events'), and gives concrete examples of event types. It also includes scoping ('most recent') that helps distinguish it from siblings like get_capability, mark_seen, and search_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 description says the tool lists recent events and can be optionally filtered, which implies when it would be used. However, it does not explicitly contrast it with search_capabilities or say when one should be preferred over the other, so the guidance is only implicit.

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 of explaining behavior. It states that the tool records a delivery and is used for analytics, which implies a state change, but it does not disclose whether the action is idempotent, whether it mutates the original event, or what happens if the event_id does not exist. This is adequate for a simple tool but 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 two short sentences with no filler. The core purpose is front-loaded in the first sentence, and the second sentence adds useful analytics context without drifting. It is appropriately sized for a tool with one parameter.

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 deliberately simple tool, the description gives the essential behavior and purpose. However, it lacks guidance on event_id provenance, expected error cases, and whether duplicate marking is allowed or harmful. Given no output schema and no annotations, a little more context would make the tool fully safe to invoke.

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 provides only an opaque event_id string with no description, and the schema description coverage is 0%. The description mentions 'capability event' but does not explain how to obtain event_id, its expected format, or its lifecycle context. The tool description needs to compensate for the schema gap but does not.

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

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

The description uses a specific verb ('Mark') and a clear resource ('a capability event') and states the operational outcome ('as delivered to the calling subscriber'). It is immediately distinguishable from the sibling retrieval tools, which are about getting, listing, and searching 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 phrase 'delivered to the calling subscriber' clearly indicates the tool should be used after the subscriber has received the event, distinguishing it from read-only capabilities exploration. It does not explicitly name alternatives or state when not to use it, but the context is strong enough that an agent can infer the intended moment of use.

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

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

With no annotations, the description carries the full burden and does add some behavioral context: it discloses that search is approximate ('not exact') and that results are capped by a limit. However, it omits details like whether matches are case-insensitive, how results are ordered, or what a match object contains. This is moderately transparent but not 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 with no filler. The primary purpose is front-loaded, and the limit behavior follows naturally. Every word 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?

The description covers the input parameters’ roles and the result cap, which is enough for a basic call. But with no output schema and no annotations, it leaves out the return structure (e.g., array of capability objects) and any safety/reversibility considerations. For a simple read-only search tool this is adequate, yet still leaves uncertainty.

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 parameter meaning. It clarifies the `limit` parameter by stating 'Returns up to `limit` matches' and implies that `query` is the text searched across titles/summaries/tags. It does not, however, explain query syntax or matching rules beyond the intuitive meaning.

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

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

The description clearly states a specific verb ('search') and the resource ('capability titles / summaries / tags'), making the primary purpose evident. It implicitly distinguishes itself from siblings like get_capability and list_recent_capabilities, though it does not explicitly name them. The qualifier 'Full-text-ish' adds useful nuance but slightly weakens precision.

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 choose this tool over the sibling alternatives. It does not mention e.g. 'use this to find a capability by keyword, use list_recent_capabilities to browse newest ones.' An agent is left to infer the appropriate context from the tool name and description alone.

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