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

With no annotations, the description carries the full behavioral burden. It does disclose the key trait that the action is irreversible, which is genuinely useful, but omits permissions required, what happens to in-flight output on cancel, and whether the run must be in a cancellable state.

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

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

Two short sentences, front-loaded with the action and followed by the risk. No filler, though 'a specific' is slightly redundant for a single-run 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 one-parameter mutation with no annotations and no output schema, disclosing irreversibility covers the most important gap. The remaining omission — how this relates to create_cancellation and when each should be used — leaves the definition only minimally 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?

Only one parameter (runId) with 100% schema description coverage ('The run ID (ULID) to cancel'), so the schema already carries the semantics. The description adds nothing about the identifier beyond what's in the schema, which is the expected baseline here.

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 ('Cancel') and resource ('function run'), which is enough for an agent to know what the tool does. However, it never differentiates from the sibling create_cancellation, which plausibly overlaps in intent, so the agent must open both schemas to tell them apart.

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?

'Use with caution' is a risk warning, not usage guidance — it says nothing about when to call this versus create_cancellation or the other cancellation-adjacent siblings. No prerequisites, no preconditions (e.g., run must be in progress), and no exclusions 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?

No annotations are provided, so the description carries the full behavioral burden for a destructive bulk operation. It never says whether cancellations are reversible, whether already-completed runs are affected, whether there is a cap on matched runs, or that this is irreversible and should be used with care.

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

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

Two short sentences, front-loaded with the bulk scope and followed by the concrete mechanics. There is mild redundancy between 'matching criteria' and the filter clause, but nothing wasteful.

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

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

A destructive mutation tool with no annotations and no output schema needs to disclose blast radius and reversibility; the description says nothing about the number of runs affected, whether the action can be undone, or what is returned. The agent cannot judge the risk of calling it from this text alone.

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

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

Schema coverage is 100% with per-parameter descriptions including ISO 8601 formats and the CEL expression type, so the schema does the heavy lifting. The description restates the time range and optional filter but adds no syntax or constraint detail beyond the schema (e.g., valid CEL fields or inclusive/exclusive bounds).

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 (cancel) and resource (all runs of a function) plus the scoping mechanism (time range + optional expression filter), which separates it from the singular cancel_run sibling. It stops short of naming cancel_run explicitly, so the differentiation is inferable rather than stated.

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 word 'Bulk' plus the matching-criteria framing implies this is for cancelling many runs at once rather than a single run, but the description never states when to prefer this over cancel_run or list_cancellations, nor any prerequisites. Usage is only implied.

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

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

No annotations are provided, so the description carries the full burden. 'Get' implies a read, but it says nothing about what happens on a missing or malformed ID, permission requirements, or whether the event payload is large.

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

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

A single efficient sentence with the resource and key qualifier front-loaded. Nothing is wasted, though there is nothing extra to earn a 5.

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 tool this is minimally adequate, but with no output schema the description gives no hint of what an event object contains or what errors to expect. Adequate but with clear gaps.

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

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

Schema description coverage is 100% and the sole parameter is fully documented in the schema. The description only restates the ULID format already present in the schema, adding no new semantics, so the baseline 3 applies.

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

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

States a specific verb and resource ('Get a single event') plus the identifier type, which is clear. It doesn't differentiate itself from the sibling get_event_runs or get_run, so it falls short of a 5.

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

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

There is no guidance on when to use this versus list_events or get_event_runs, and no prerequisites or failure conditions are mentioned. The description offers only implied 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?

No annotations are provided, so the description carries the full behavioral burden. It implies a read operation via "List" but says nothing about result limits, pagination, ordering, empty-result behavior, or permission requirements for a read across an event's triggered runs.

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 clean sentence with the resource and scoping condition front-loaded and no filler. It is efficient, though its brevity borders on under-specification rather than optimal conciseness.

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

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

With no annotations and no output schema, the description is the only place return-shape information could live, and it does not describe what a run record contains or how results are bounded. For a read-list tool this leaves meaningful gaps.

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

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

Schema description coverage is 100% and there is a single required parameter (eventId, documented as a ULID in the schema). The description only restates the notion of "a specific event" without adding format or lookup details, so the schema does the heavy lifting — a baseline 3.

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

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

The description states a specific verb ("List") and a clearly scoped resource ("function runs triggered by a specific event"), so an agent can tell it apart from get_run (single run) and get_event (the event itself). It is clear, though it never names or contrasts with those siblings explicitly.

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

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

There is no guidance on when to use this versus get_run, get_event, or list_events, nor any stated prerequisites. The only implied context is that the caller must already hold an eventId, which is not said outright.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses that the response contains status and output, but says nothing about whether the run must exist be live or completed, whether auth is required, or what happens for an unknown runId.

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 sentence, front-loaded with the verb and resource, with no filler. Nothing in it is redundant with itself.

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

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

For a simple one-parameter lookup with no output schema, the description covers the essentials of what is retrieved. It remains thin on run-state behavior and error conditions, so it is adequate but not 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 100% and the single runId parameter is documented as a ULID, so the schema does the work. The description adds no extra parameter meaning beyond confirming that a single run is targeted, which is the baseline 3 for full schema coverage.

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

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

States a specific verb (Get) and resource (a specific function run) plus what it yields (status and output). It is clear, but it does not differentiate itself from the sibling get_event_runs, which also deals with runs, so it stops 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?

Only the implied usage of 'fetch one specific run' is present. There is no guidance on when to use this instead of get_event_runs, list_functions, or the cancellation tools, and no prerequisites or exclusions are mentioned.

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

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

With no annotations, the description carries the full behavioral burden, and it does disclose one real trait: only ACTIVE rules are returned, implying inactive/paused rules are filtered out. It says nothing about ordering, pagination, volume limits, or permissions, so the disclosure is only partial.

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

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

A single front-loaded sentence with zero filler. The scope word 'active' appears where it matters most, and nothing 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 trivial, parameterless read tool this is nearly sufficient, but with no output schema and no annotations the description leaves the return shape (fields per rule, whether empty results are possible, ordering) entirely unspecified.

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 and the schema is empty, so there is no parameter semantics to document; the baseline for a no-param tool applies. The description appropriately adds no fabricated input details.

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

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

States a specific verb ('List') and resource ('bulk cancellation rules') with a scope qualifier ('active'), so an agent can distinguish it from create_cancellation and cancel_run at a glance. It does not, however, explicitly reference any sibling by name or position itself within the family.

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

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

No when-to-use guidance, no prerequisites, and no alternatives named. The description never tells the agent to reach for this tool to inspect existing rules before calling create_cancellation, nor when not to use it.

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

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

With no annotations, the description carries the burden, and it does disclose the reverse-chronological ordering, which the schema does not. However, it says nothing about pagination behavior, auth requirements, rate limits, or the default 7-day window beyond what the schema already states.

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 padding, and the core behavior (listing + ordering) is front-loaded ahead of the filter hint. Nothing redundant or wasteful.

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 five-parameter paginated list tool with no annotations and no output schema, the description is adequate but thin: it omits pagination workflow, default time-window behavior, and how results relate to get_event. The schema covers parameters, so the gap is mostly about call/return workflow context.

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

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

Schema description coverage is 100%, so all five parameters are already documented with examples, ranges, and defaults. The description restates the name filter's purpose but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('List recent events') plus the ordering semantics ('reverse chronological order'), which distinguishes it from get_event and get_event_runs. It does not explicitly name sibling tools, but the listing-vs-retrieval distinction is clear.

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?

'Use name filter to find specific event types' gives one usage hint, but there is no guidance on when to prefer this over get_event or list_functions, and no exclusions or prerequisites. Usage is implied rather than spelled out.

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

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

No annotations are provided, so the description carries the full burden, and it discloses almost nothing behavioral. It doesn't state whether the result is paginated, whether authentication or app-ownership is required, or what the returned entries contain. For a read-only list tool this is a real gap even if low-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?

A single front-loaded sentence with no filler or redundancy. 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?

For a simple single-param list operation with no output schema, the core intent is conveyed, but with no annotations and no output schema the description should at least hint at return shape or pagination behavior. Adequate but with clear gaps.

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

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

Schema description coverage is 100% and there is a single parameter, so the schema already fully documents appName with an example format. The description adds nothing beyond it, which is the baseline-3 case when the schema does the lifting.

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

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

States a specific verb ('List') and resource ('functions') scoped to 'a given app.' Clear and specific, though it makes no explicit reference to any sibling tool — necessary here only insofar as none of the siblings (list_events, get_run, cancel_run, etc.) overlap with function listing, so confusion risk is low.

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

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

The description offers no when-to-use guidance, no prerequisites, and no mention of alternatives. Usage is only faintly implied by the resource name; an agent gets no help deciding when this tool is appropriate versus other listing tools.

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