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

With no annotations, the description carries the full burden and falls short. It never states that cancelling is a graceful/irreversible destructive operation, whether the operation is idempotent, what happens to workflows that don't match, or how failures and results are reported for a batch.

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 scope; nothing is padded. The second sentence is partially redundant with the schema's concurrency description, costing a point.

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 unannotated bulk destructive operation with no output schema, the definition omits too much: no return/result reporting, no partial-failure behavior, no distinction from batch_terminate, and no warning that cancellation is effectively irreversible.

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 four parameters (limit, query, namespace, concurrency) are already documented, including the concurrency default of 50. The description merely restates the concurrency semantics, adding no meaning beyond the schema, which is the expected baseline.

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

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

States a specific verb and resource ('Cancel multiple workflows matching a query'), clearly scoped to bulk operations versus the single-workflow cancel_workflow sibling. It does not, however, distinguish itself from the adjacent batch_terminate / batch_cancel_activities siblings, so the agent must infer which is appropriate.

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 is given: nothing says when to pick batch_cancel over cancel_workflow or batch_terminate, and no prerequisites or cautions are stated. The only directive is how to tune concurrency, which is execution detail rather than selection guidance.

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

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

No annotations exist, so the description carries the full behavioral burden. It discloses the parallelism approach and default concurrency, but says nothing about irreversibility, what happens to partially matched or already-completed activities, failure handling, or what a cancellation actually does to a running activity.

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 the core action front-loaded and the concurrency tip second. No wasted words, though the parenthetical default duplicates the schema.

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

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

For a destructive bulk mutation with no annotations and no output schema, the definition leaves key gaps: whether cancellation is graceful or forced, partial-failure reporting, and the shape of any result. An agent cannot confidently predict outcomes from this alone.

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

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

Schema description coverage is 100%, so all four parameters are already documented, including the concurrency default. The description restates the concurrency default rather than adding new semantics (e.g. query syntax or limit interaction), 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 (cancel) and resource scope (multiple standalone activities matching a query), and adds the concurrency mechanism. It implicitly distinguishes from cancel_activity (single) and batch_terminate_activities (terminate vs cancel), but never names 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 choose this over cancel_activity, batch_cancel, or batch_terminate_activities, and no preconditions stated. The description only implies bulk use via 'multiple ... matching a query'.

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 says signals are sent to a batch but not what happens on partial failure, whether the call is idempotent, what permissions are needed, or whether the signal is fire-and-forget or blocking — all material for a batch mutation tool.

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

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

Two short sentences, front-loaded with the core action and followed by the one parameter nuance worth surfacing. No filler, though the second sentence only echoes a schema default.

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 five-parameter batch mutation tool with a nested args object, no annotations, and no output schema. The description does not address partial-batch outcomes, error behavior, or the args payload shape, leaving significant gaps for an agent deciding how to call and interpret it.

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 schema already documents query, signal_name, args, limit, and namespace. The description only restates the limit default, adding no semantics beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource: 'Send a signal to multiple workflows matching a query.' The 'multiple workflows matching a query' phrasing distinguishes it in spirit from the sibling signal_workflow (singular), though it never names that sibling explicitly.

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

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

Usage is implied by 'matching a query' and the batch/multi-workflow framing, but there is no explicit when-to-use guidance, no exclusions, and no mention of the single-target signal_workflow alternative for non-batch cases.

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 bulk, forced-termination operation it omits critical context: that termination is destructive and irreversible, whether it skips graceful cleanup, permission requirements, and what happens to workflows already in flight. Only the default batch size is disclosed, and that is already in 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?

Two short sentences, front-loaded with the action, no padding. Slight deduction because the second sentence restates a default already present in the schema rather than adding new 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?

A four-parameter destructive batch tool with no annotations and no output schema needs more than this description: it never says what termination does to the target workflows, whether the operation is partial/resumable, or how many matched versus terminated. The agent has no safety or outcome 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 the baseline is 3 and the schema already documents query, reason, namespace, and limit. The description's mention of 'limit' merely restates the schema default (100) rather than adding query syntax or reason 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?

Specific verb and resource: 'Terminate multiple workflows matching a query.' The batch semantics are clear and distinguish it from the singular terminate_workflow, but nothing separates it from the sibling batch_cancel, which implies a different (graceful vs forced) operation.

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 statement of when to use batch_terminate versus batch_cancel, terminate_workflow, or batch_terminate_activities. The only guidance is a schema-duplicating note about 'limit', with no exclusions or context about when a batch termination is appropriate.

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

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

No annotations are provided, so the description carries the full burden. It mentions a batch size limit and default but does not disclose destructive nature, irreversibility, permission requirements, effect on running activities, or what happens to activities that don't match the query. This is a significant gap for a termination tool.

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

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

Two short sentences, front-loaded with the core action and a useful default. No wasted words, though it could be slightly more informative without becoming verbose.

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 this is a destructive batch operation with no annotations and no output schema, the description is incomplete. It should state that termination is irreversible, whether it affects running activities, and any prerequisite permissions. The current text leaves an agent uncertain about the consequences of calling it.

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 schema already documents all parameters. The description adds a default for 'limit' (100) and mentions batch size control, but it does not explain 'reason', 'concurrency', or 'namespace' beyond what is in the schema. Baseline 3 is appropriate when schema is comprehensive.

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 ('Terminate') and resource ('multiple standalone activities') and clarifies batch scope, distinguishing it from terminate_activity and batch_terminate_workflows by naming 'standalone activities'. It is clear but lacks explicit sibling routing.

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 no guidance on when to use this batch tool versus terminate_activity (singular), batch_cancel_activities, or batch_terminate. The reader must infer that this is for bulk operations, but there is no explicit when-to-use or 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?

No annotations are provided, so the description carries the full behavioral burden and falls short. It does not say whether cancellation is graceful or immediate, whether it is reversible, what permissions are required, or what happens to an activity that has already completed. For a mutation tool with zero annotation coverage this is a meaningful 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?

A single front-loaded sentence with no waste, though it is arguably too terse given the tool's mutation semantics and the crowded sibling set. Efficient but under-informative.

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 destructive-capable tool with no annotations, no output schema, and numerous similar siblings, the description leaves out safety profile, effect on completion, and sibling differentiation. It is not complete enough for an agent to invoke confidently.

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

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

Schema description coverage is 100%, so run_id, namespace, and activity_id are already documented in the schema, and the description adds no syntax, format, or semantic detail beyond it. Baseline 3 applies when structured fields do the heavy lifting.

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

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

States a specific verb and resource ('Cancel a running standalone activity execution'), which is clearer than a bare name restatement. However, it does not distinguish itself from close siblings like terminate_activity, batch_cancel_activities, or cancel_workflow, so an agent cannot tell why to prefer cancel over terminate without opening schemas.

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

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

There is no guidance on when to use this tool versus the many available alternatives (terminate_activity, batch_cancel_activities, cancel_workflow). The word 'running' hints at a precondition but no explicit conditions, exclusions, or prerequisites 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?

No annotations are provided, so the description carries the full behavioral burden and falls well short. It does not explain that cancel is a cooperative/graceful request that the workflow may handle or ignore (as opposed to terminate's forced stop), nor reversibility, permissions, or required 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?

A single, front-loaded sentence with zero filler. It is efficient, though the terseness is partly a symptom of what is missing rather than pure economy.

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 mutating operation with no annotations, no output schema, and a sibling that does a similar-but-different thing, the description should clarify cancellation semantics and the cancel-vs-terminate distinction. It leaves an agent unable to call this correctly with confidence.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema. The description adds no syntax, format, or constraint detail beyond the schema, which is the baseline-3 outcome when the schema does the heavy lifting.

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

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

States a specific verb (cancel) and resource (workflow execution), so the agent knows exactly what the tool does. However, it does not differentiate from the highly similar sibling terminate_workflow, which an agent must choose between.

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 on when to use cancel_workflow versus terminate_workflow, batch_cancel, or cancel_activity. The description gives no prerequisites, no conditions, and no alternatives despite a sibling set full of near-duplicates.

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

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

With no annotations, the description carries the full burden. It does disclose a real behavioral trait – the workflow restarts while preserving a history link – which is valuable. However, it omits permissions, whether the operation is asynchronous, and what happens if the signal is unhandled.

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 the key behavioral clarification in parentheses. Zero filler, and the most important information (what happens to the workflow) comes immediately after 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?

A mutation tool with no annotations and no output schema, but with full schema coverage on four parameters. The description explains the effect on the workflow but leaves gaps around authorization, async behavior, and how it relates to the plain signal_workflow sibling.

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 every parameter is already documented in the schema, making 3 the baseline. The description adds only the framing that signal_args are inputs for the triggering signal, which is largely redundant with the schema text.

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

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

States a specific verb ('signal') and resource ('workflow') and explains the mechanism: restart with new inputs while preserving a history link. This differentiates it from the generic signal_workflow sibling, though it never names that sibling or explicitly contrasts the two.

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 parenthetical (restart with new inputs), but there is no explicit when-to-use, when-not-to-use, or named alternative among siblings like signal_workflow, terminate_workflow, or cancel_workflow. The agent must infer when continue-as-new is preferable to termination.

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 but discloses little: it implies a read-only count but says nothing about permissions, result format, rate limits, or whether 'standalone' excludes workflow-scoped activities. The definition leaves meaningful behavioral questions unanswered.

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

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

A single front-loaded sentence with no filler; the verb, scope, and filter condition all appear immediately with zero wasted words.

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

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

For a simple two-parameter read tool with no output schema and full schema coverage, the essentials are present. However, the description never clarifies what 'standalone' means relative to the many workflow/activity siblings or what the count result represents, leaving gaps an agent must 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 coverage is 100%, so the schema already documents both the query filter (with an example) and the namespace enum. The description adds no syntax or format detail beyond 'matching a query', 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 ('Count ... activity executions') plus scope ('standalone', 'matching a query'), which is clearer than a bare restatement. It distinguishes the counting purpose from the listing sibling list_activities, but never names that sibling explicitly.

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

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

No when-to-use guidance is given. The agent is not told when to prefer count_activities over list_activities or query_workflow, nor whether it requires a query to be meaningful. Usage is only implied by 'matching a query'.

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-disclosure burden. It implies a mutation that creates persistent state but omits permissions/auth requirements, duplicate schedule behavior, namespace defaults, return semantics, and whether the schedule starts immediately or must be triggered.

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

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

A single front-loaded sentence with no filler. The core action and resource appear immediately, and every word contributes to the stated purpose.

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

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

For a 6-parameter mutation tool with no annotations and no output schema, one sentence is insufficient. The schema documents fields, but the description omits behavioral context such as duplicate-schedule handling, required permissions, namespace/default behavior, and cron semantics.

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 every property has a schema-level description. The tool description adds no parameter-level meaning beyond what the schema already provides, so the baseline of 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 and resource: 'Create a new schedule for periodic workflow execution.' The purpose is clear, but it does not explicitly differentiate this create operation from sibling schedule tools such as trigger_schedule, pause_schedule, or list_schedules.

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

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

Provides no when-to-use or when-not-to-use guidance, no prerequisites, and no alternatives. The agent is left to infer that this should be used instead of trigger_schedule or unpause_schedule when a new recurring schedule is needed.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state whether deletion is permanent, idempotent, whether it fails if the schedule is already gone or currently running, what permissions are required, or what happens to in-flight executions. Only the bare implication of a destructive write is conveyed.

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 single sentence is front-loaded and wastes no words, but it is under-specified rather than genuinely concise. There is no filler, yet also no useful content beyond restating the name.

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 destructive mutation tool with no annotations and no output schema, the description should cover permanence, error/idempotency behavior, and permission requirements. None of this is present, leaving an agent unable to call it safely with confidence.

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

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

Schema description coverage is 100%, so both parameters (schedule_id and namespace) are already documented in the schema itself. The description adds no format, syntax, or constraint detail beyond that, 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 clear verb and resource ('Delete a schedule'), so an agent can tell what it does. However, it adds nothing beyond the tool name and gives no differentiation from sibling operations like cancel_workflow, terminate_workflow, or pause_schedule, leaving the precise semantic (permanent removal vs. cancellation of running executions) 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?

No guidance on when to use this tool versus alternatives. With siblings such as pause_schedule, trigger_schedule, and terminate_workflow, an agent gets no signal about whether deletion is permanent, whether it should be preferred over pausing, or what prerequisites exist.

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. 'Get' implies a read, but the description says nothing about permissions, error behavior when the activity_id is unknown, or what the returned detail 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?

A single efficient sentence with the resource front-loaded and no filler. Nothing is padded, though there is little structure to speak of beyond the one clause.

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 to convey behavior and return shape, and it does neither. For a describe-style tool returning detail, 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% — all three parameters (activity_id, run_id, namespace) are documented in the schema, including the enum on namespace. The description adds no parameter meaning beyond the resource name, 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 ('Get') and resource ('detailed information about a standalone activity execution'), which is clearly narrower than list_activities or get_activity_result. It does not explicitly differentiate itself from those siblings, 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?

No guidance on when to use this versus get_activity_result, list_activities, or describe_workflow, and no prerequisites or exclusions stated. The agent must infer the selection criteria from the name alone.

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

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

With no annotations, the description must carry the behavioral burden. It does disclose the return contents (config, runtime state, recent executions, upcoming action times), which is genuinely useful, but it omits that this is a non-mutating read, says nothing about permissions, and says nothing about how many executions or how far ahead the 'upcoming' times extend.

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 that lists the returned fields without padding or repetition. 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 2-parameter read tool with no output schema, the description usefully summarizes the return payload, which is the main gap an output schema would have filled. It could still say more about scope/limits, but it is adequate to call correctly.

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

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

Schema description coverage is 100%, so both schedule_id and namespace are already documented in the schema. The description adds no format, syntax, or namespace semantics beyond that, 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 (Get) and resource (a schedule) and enumerates what is returned: spec, action, state, recent executions, upcoming action times. This clearly separates it from list_schedules and from the describe_workflow/describe_activity siblings, though it never names those 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?

There is no explicit when-to-use guidance, no prerequisites, and no mention of the surrounding sibling tools (list_schedules, pause_schedule, etc.). An agent can infer this is the read/inspect operation, but nothing is stated.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it says almost nothing: no confirmation that this is a read-only, non-destructive operation, no auth or namespace prerequisites, no note on failure behavior for unknown workflow IDs. For an unannotated tool, this is a thin 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?

A single front-loaded sentence with no filler or repetition. It is efficiently written, though the brevity reflects under-specification rather than true crispness of a complete definition.

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 source of behavioral and return-shape information, yet 'detailed information' never says what is returned (status, config, timing, etc.) or how it relates to sibling read tools. For a describe tool lacking an output schema, this leaves a 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 100%, so both parameters (workflow_id and namespace, including its enum and server-default behavior) are already fully documented in the schema. The description adds no extra meaning about parameter format or accepted values, 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 gives a clear verb ('Get') and resource ('a workflow execution') with the added qualifier 'detailed information', so the agent knows this is a retrieval tool rather than a mutation. However, it does nothing to separate itself from close siblings like get_workflow_result, get_workflow_history, and get_workflow_event, all of which also return workflow execution data.

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

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

There is no guidance on when to use this tool versus the many alternatives in the sibling list. Nothing tells the agent whether this is the right call for inspecting status/config versus retrieving output, event history, or results.

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 mention the blocking behavior of waiting for a result, which is useful, but omits critical traits such as authorization requirements, timeout semantics, error handling, and whether the activity execution is idempotent or creates new state. Much remains undisclosed.

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

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

The description is a single, front-loaded sentence with no wasted words. It efficiently conveys the core action and the key behavioral hint of waiting for a result.

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 six parameters, no output schema, and no annotations, the description is too thin. It does not explain return value format, error or timeout behavior, or how the result is delivered, leaving significant gaps that an agent would need to call it correctly in non-trivial cases.

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 schema already documents all six parameters thoroughly. The description adds no additional parameter meaning, so the baseline of 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 states a specific verb ('Execute') and resource ('standalone Temporal activity') and adds the scope behavior 'wait for result'. However, it does not differentiate itself from the sibling tools start_activity or get_activity_result, leaving the agent to infer the distinction from the name alone.

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 about when to use this tool versus alternatives like start_activity or get_activity_result. The words 'standalone' and 'wait for result' imply a synchronous use case but fall short of explicit when-to-use or 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?

No annotations are provided, so the description carries the full behavioral burden. It only implies a read operation via 'Get' but does not disclose blocking/waiting behavior, how the timeout parameter changes behavior, error conditions, or permissions.

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

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

A single, front-loaded sentence with no wasted words. However, its extreme brevity leaves it underspecified for a tool with a timeout parameter and no annotations.

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 explain result format, waiting semantics, and timeout interaction. It does none of these, leaving significant gaps for a tool that retrieves a standalone activity result.

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 schema already documents all four parameters. The description adds no additional parameter meaning, which is the expected baseline when schema coverage is complete.

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 (result of a standalone activity), with scope limited to standalone activities. This distinguishes it from the workflow-focused sibling get_workflow_result without needing to read 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?

No when-to-use guidance, no alternatives named, and no prerequisites. An agent cannot tell from this description whether to call this after start_activity, whether execute_activity already returns results, or when the activity must be complete.

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

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

No annotations are provided, so the description carries the full burden. It does disclose one useful behavioral trait, that payload fields are decoded when present, which tells the agent the response may or may not contain decoded data. However it says nothing about permissions, behavior for a missing event ID, or pagination/truncation of large payloads.

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

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

A single front-loaded sentence with no wasted words, leading with the verb and resource and appending the qualifier about decoded payloads. Nothing is repeated or padded.

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 must carry more weight. It mentions decoded payload fields but does not describe the shape of a returned event, error behavior for an unknown event_id, or any mutation/safety context; for a read-only getter this is adequate but thin.

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

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

Schema description coverage is 100%, so all four parameters (run_id, event_id, namespace, workflow_id) are already documented in the schema with their types and the optional/required split. The description adds no parameter-level meaning beyond what the schema provides, 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 states a specific verb and resource: 'Get a single workflow history event.' The word 'single' implies retrieval of one event rather than a list, but it never names the sibling get_workflow_history, which is the tool an agent is most likely to confuse it with, so it falls short of full sibling differentiation.

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

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

There is no guidance on when to fetch a single event instead of calling get_workflow_history or get_workflow_result, and no stated prerequisites or conditions. The agent must infer the choice entirely from the name and description.

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. 'Get' implies a read, but nothing is said about permissions required, whether results are ordered, whether history is truncated/retained, or how the limit interacts with pagination. The default value of 1000 is disclosed, which is the one concrete behavioral fact offered.

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

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

Two short sentences, front-loaded with the core purpose and followed by the one parameter worth calling out. No filler, though the second sentence is largely redundant with the schema.

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

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

With no annotations and no output schema, the description should explain more about the read operation and its result shape. The fully-covered input schema compensates for parameter documentation, but the missing differentiation from get_workflow_event leaves a real gap for an agent choosing between history-level and event-level retrieval.

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 schema already documents all four parameters, including run_id and namespace. The description only restates the 'limit' parameter and its default, adding no syntax or format detail beyond the schema; baseline 3 applies when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: 'Get the complete event history of a workflow execution.' That is clear enough for an agent to understand the operation. However, it does not distinguish itself from the sibling get_workflow_event (single event) or query_workflow, so the agent gets no help telling these 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?

There is no statement of when to use this tool versus alternatives such as get_workflow_event or query_workflow, and no preconditions are given. The only guidance is the incidental mention of 'limit', which is a parameter detail rather than usage context.

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

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

No annotations are provided, so the description carries the full behavioral burden. "Completed workflow" hints that the call may fail or block on an unfinished execution, but it never says what happens in that case, whether the call blocks, or what the returned result contains. For a read tool with zero annotation coverage this is a real 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?

A single eight-word sentence with the resource and scope front-loaded and no filler. Nothing could be removed without losing meaning.

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

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

There is no output schema, so the description should at least sketch what "the result" is (payload shape, terminal-state requirement, error on incomplete runs). It stays at minimum viable for a simple two-parameter read tool but leaves the return contract entirely unexplained.

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

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

Schema description coverage is 100%, with both workflow_id and namespace documented inline (including the namespace omit-default behavior), so the baseline of 3 applies. The description adds nothing about parameter format or required ID source.

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

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

States a specific verb+resource: retrieving the result of a workflow. The word "completed" narrows scope and implicitly distinguishes it from get_workflow_event and get_activity_result. It does not explicitly name a sibling or state scope beyond that, so it falls short of 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?

No guidance on when to call this versus get_workflow_event, get_workflow_history, or describe_workflow, and no stated precondition (e.g. only after the workflow reaches a terminal state). The agent must infer the timing constraint from the word "completed" alone.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'List' implies a read, but the description never confirms non-mutation, says nothing about permissions, defaults behavior, or what the returned executions look like, and never explains what makes an execution 'standalone'.

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 that front-load the purpose before the parameter notes, with no filler. Slightly redundant given the schema already documents limit and skip, which keeps it from 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?

There is no output schema and no annotations, so the description should ideally describe the shape of returned executions and confirm the read-only nature. It stops at purpose plus pagination, leaving an agent to guess the return format and how 'standalone' is determined.

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 four parameters are already documented in the schema with defaults and an example query. The description restates limit and skip without adding format, syntax, or constraint detail beyond that baseline.

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

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

States a specific verb and resource ('List standalone activity executions'), and the word 'standalone' usefully distinguishes this from activity executions tied to a workflow. It does not name or contrast with the closest siblings (count_activities, list_workflows), so an agent must infer the boundary itself.

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

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

The description explains how to control results with limit/skip, which is pagination mechanics rather than usage guidance. It gives no when-to-use condition, no exclusions, and no pointer to count_activities or other listing tools when the agent only needs a total.

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 pagination behavior and default page size (100), but does not state that this is a read-only, non-mutating operation, nor does it describe ordering or what happens if limit exceeds available schedules.

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 primary action followed by pagination controls. Every sentence carries information and 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 parameterless list tool with full schema coverage, the description covers the essentials, but with no output schema and no annotations it omits return shape and ordering. It is adequate but leaves modest gaps for an agent deciding how to page through results.

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 schema already documents skip, limit, and namespace fully. The description only restates limit and skip defaults, adding no meaning beyond the schema; this is the baseline 3 case.

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 ('List all schedules'), which is distinguishable from siblings like list_workflows, list_activities, and describe_schedule. It does not, however, explicitly contrast itself with describe_schedule, which is the closest alternative.

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

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

Pagination guidance is given (limit, skip), but there is no explicit when-to-use guidance relative to alternatives such as describe_schedule for single-schedule details or list_workflows. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full behavioral burden. It hints at result-count control but does not state that this is a read-only listing, whether pagination is cursor- or offset-based across calls, or what the response contains. For a tool with zero annotation coverage this is a notable 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?

Two tightly written sentences with the purpose front-loaded and pagination guidance following. No filler, though the phrasing is slightly cramped.

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 four parameters, no annotations, and no output schema, the description leaves the return shape and read-only nature unexplained and offers no routing among the many sibling listing and query tools. It is adequate for pagination defaults but incomplete for correct invocation in this crowded toolset.

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 schema already documents all four parameters and the baseline is 3. The description adds one genuinely new detail, the max recommended limit of 1000, but says nothing about the query filter syntax or the namespace parameter beyond what the schema 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?

States a specific verb and resource ('List workflow executions') that distinguishes it from siblings like list_activities and list_schedules. The qualifier 'based on a query' is vague but the core object of the operation is unambiguous.

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

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

The description explains how to use limit and skip but never says when this tool should be chosen over alternatives such as query_workflow or get_workflow_history. No prerequisites, context, or exclusions are given, leaving tool selection to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not state what pausing does, whether it is reversible, what permissions are required, or how it affects running workflows. The description adds no behavioral context beyond the action implied by the name.

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, under-specified sentence. While it is brief and front-loaded, it is too terse to be appropriately sized for a mutation tool that lacks annotations and needs to convey operational context.

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

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

With no annotations and no output schema, the description should explain behavioral context such as reversibility, side effects, or prerequisites. It omits all such information, leaving the agent with only the input schema to understand the tool's impact.

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

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

Schema description coverage is 100%, so all three parameters are fully documented in the schema. The description adds no parameter details, but the baseline for high coverage is 3 even without description-level parameter information.

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 restates the tool name ('pause_schedule' → 'Pause a schedule') without adding scope, prerequisites, or differentiation from siblings like unpause_schedule. It states a verb and resource but is essentially a tautology, providing no information beyond the name itself.

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

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

There is no guidance on when to use this tool versus alternatives such as unpause_schedule, delete_schedule, or trigger_schedule. The agent must infer context solely from the tool name, with no explicit when/when-not conditions.

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 implies a read of a running workflow's state but omits key behavioral details: whether it blocks, what happens if the workflow is not running, error handling, or whether it is read-only. Only the 'running workflow' constraint 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?

The description is a single, front-loaded sentence with no waste. It is appropriately concise, though arguably too terse for a complex operation, which prevents a perfect score.

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 involves a workflow query with nested arguments and no output schema. The description fails to explain return values, query semantics (e.g., built-in queries), or how to structure the args object, leaving significant gaps for an AI agent to invoke it correctly.

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

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

Schema coverage is 100%, so each parameter is documented in the schema. The description adds no additional meaning beyond what the schema provides, 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?

States a specific verb ('Query') and resource ('a running workflow'), and clarifies the scope as 'current state'. However, it does not explicitly differentiate from siblings like get_workflow_result or describe_workflow, 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?

No guidance on when to use this tool versus alternatives (e.g., get_workflow_result for final results, describe_workflow for metadata). The description provides no context 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?

No annotations are provided, so the description carries the full behavioral burden. It does not disclose whether signal delivery is synchronous or queued, what happens if the workflow has already completed or been terminated, whether signals are idempotent/deduplicated, or what a failure looks like. For a mutation tool with zero annotation coverage this is a substantial 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?

A single, front-loaded sentence with no filler. It is efficient, though its brevity contributes to the gaps noted in other dimensions rather than adding structure.

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 signal-delivery mutation with no annotations, no output schema, and a nested args object, the description is too thin. It omits delivery semantics, failure modes, and prerequisite workflow state, leaving the agent to infer behavior it cannot verify.

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% (every parameter, including the nested args object and namespace enum, is documented in the schema), so the baseline is 3. The description adds nothing beyond the schema, but the schema already does the work.

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: 'Send a signal to a running workflow.' An agent can distinguish it from read-oriented siblings like get_workflow_result or query_workflow. It does not, however, differentiate itself from batch_signal, with which it shares the core action.

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

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

There is no guidance on when to use this tool versus alternatives such as batch_signal (multiple targets) or start_workflow. No preconditions (e.g., the workflow must be running and not completed) or error handling 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?

No annotations are supplied, so the description carries the full behavioral burden. It only says it starts an activity; it does not disclose idempotency/duplicate-activity_id behavior, error handling, whether the activity runs detached from any workflow, or what the call returns for a mutation-style operation.

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, which is efficient. It is arguably too terse given the tool's complexity, but as pure conciseness it wastes nothing.

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

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

A mutation/execution tool with six parameters, a nested args object, no annotations, and no output schema demands more than one sentence. Key facts an agent needs — whether it is safe to retry, how this differs from execute_activity, and what timeout defaults apply — are absent.

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

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

Schema description coverage is 100%, so all six parameters including args, namespace, and the timeout are already documented in the schema. The description adds nothing beyond the schema, which is the expected baseline when the schema does the heavy lifting.

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

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

States a specific verb and resource ('Start a new standalone Temporal activity execution') and the word 'standalone' hints at a distinction from a workflow-bound execution. However, it never names or contrasts the sibling execute_activity, so an agent cannot be fully sure which of the two activity-starting tools to pick.

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 on when to use this versus execute_activity, start_workflow, or the batch variants. The 'standalone' hint is the only contextual cue and no exclusions or prerequisites 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?

No annotations are provided, so the description carries the full behavioral burden, yet it only says 'Start a new'. It says nothing about idempotency, what happens on workflow_id collision, whether the call blocks until completion, or what the execution returns. For a workflow-launching mutation with no annotation coverage, this is a substantial 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?

A single front-loaded sentence with no wasted words. It is concise and well-structured, though its brevity leaves much unsaid rather than being over-padded.

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 mutation tool with a nested 'args' object, no output schema, and no annotations, the description is too thin. It omits return/run semantics, execution blocking behavior, failure modes, and any usage context an agent would need to call it correctly.

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

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

Schema description coverage is 100%, so every parameter is already documented in the schema, including the nested 'args' JSON object and the namespace default. The description adds no parameter-level detail beyond the schema, making the baseline 3 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 (start) and resource (Temporal workflow execution), so an agent can distinguish it from query_workflow, signal_workflow, cancel_workflow, etc. It does not explicitly name sibling alternatives, but the operation is unambiguous.

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

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

No when-to-use guidance, prerequisites, or alternatives are given. The description does not explain when to use start_workflow versus start_activity/execute_activity, or what conditions must be met (e.g., a running Temporal server, namespace setup).

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. 'Forcefully terminate' implies abrupt, likely irreversible destruction, but it says nothing about what happens to a running activity's state, whether results are discarded, permission requirements, or idempotency.

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

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

A single front-loaded sentence with no filler. It is efficient, though its brevity borders on under-specification for a destructive mutation rather than genuine tightness.

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 destructive operation with no annotations, no output schema, and a required identifier plus run_id that must be matched to the right execution, the description is too thin. It omits what termination does to in-flight state and how it relates to cancel_activity.

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 four parameters (activity_id, run_id, namespace, reason) are already documented in the schema. The description adds no syntax, format, or interaction detail beyond that, which is the expected baseline when the schema does the work.

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 ('terminate') and resource ('standalone activity execution'), and the adverb 'forcefully' hints at the abrupt nature. It does not, however, name or differentiate itself from the sibling cancel_activity, which is the near-identical alternate an agent must choose between.

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 mention of cancel_activity as the graceful alternative. The agent is left to infer that 'forcefully' means this is the escalation path over cancellation.

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. 'Forcefully' hints at a non-graceful path but does not state irreversibility, whether cleanup/compensation runs, whether the call is idempotent, or what happens to an already-completed workflow. For a destructive operation with zero structured safety hints, this is inadequate.

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 waste. It is efficient but arguably too terse for a destructive tool where a second sentence on consequences would earn 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?

A destructive, irreversible-style operation with no annotations, no output schema, and a close sibling (cancel_workflow) that demands differentiation. The description omits the consequences and routing logic an agent needs to call it safely and correctly.

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

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

Schema description coverage is 100%, documenting workflow_id, reason, and namespace (including enum and default behavior). The description adds no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('terminate') and resource ('workflow execution'), and 'Forcefully' signals a distinct intensity. However, it does not differentiate from the sibling cancel_workflow, which is the key conceptual neighbor for this operation, leaving the agent to infer the distinction.

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 on when to terminate vs. cancel_workflow, which coexists in the sibling list and differs only in gracefulness. For a destructive terminal operation, the absence of any when-to-use or when-not-to-use statement is a meaningful gap.

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

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

No annotations exist, so the description carries the full behavioral burden, yet it only says a run is triggered. It is silent on whether the trigger is fire-and-forget or returns a run handle, whether the schedule's next run time is reset, and whether permissions or a paused schedule block the call.

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

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

A single front-loaded sentence with the verb, resource, and immediacy qualifier; nothing extraneous and nothing buried.

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

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

For a mutation-style tool with no annotations, no output schema, and no sibling-context notes, the description is too thin: an agent cannot tell what the call returns or whether it interacts with pause/unpause state. The schema covers inputs, but the behavioral envelope 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 description coverage is 100%, with both namespace and schedule_id documented inline, so the schema does the heavy lifting. The description adds no meaning beyond that, giving the baseline 3 for a fully-documented 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 (trigger) and resource (scheduled workflow) plus the immediate-execution nuance, which distinguishes it from list_schedules, delete_schedule, and pause_schedule. It does not, however, distinguish it from unpause_schedule, which can also cause a run, so sibling differentiation is incomplete.

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 is given: nothing says whether this runs the workflow once in addition to the normal schedule, whether it requires the schedule to be unpaused (cf. unpause_schedule), or what errors occur if the schedule is paused. Usage must be inferred entirely from the name.

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

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

No annotations are provided, so the description carries the full behavioral-disclosure burden. It states the state transition but omits permissions required, idempotency, error behavior if the schedule is not paused, and any side effects of resuming.

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

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

The description is a single, front-loaded sentence with no wasted words. However, for a mutation tool with no annotations and no output schema, it is too sparse to be considered appropriately sized.

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 a state-changing operation with no annotations and no output schema, so the description should compensate by explaining operational behavior. It only states the basic action, leaving permissions, failure modes, and side effects unaddressed.

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

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

Schema description coverage is 100%, so the input schema already documents schedule_id, note, and namespace. The description adds no additional parameter meaning, which matches the baseline of 3 when the schema does the heavy lifting.

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

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

The description states a specific verb and resource: 'Resume a paused schedule.' It clearly identifies the operation as the inverse of pausing and the target as a schedule, but it does not explicitly differentiate itself from siblings like pause_schedule or trigger_schedule.

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 'paused schedule' implies the precondition for use, so an agent can infer it should only be called on an already-paused schedule. However, there is no explicit guidance on when to use this versus pause_schedule, trigger_schedule, or other schedule lifecycle tools.

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