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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: 'Sets each workflow's status to CANCELLED' and 'Each workflow will stop executing at its next step boundary.' This goes beyond a simple 'cancel' and explains mutation and execution behavior. It could mention prerequisites or failure modes, but the given details are useful.

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 well-structured: a one-sentence summary, a behavioral explanation, an Args list, and a Returns list. Each section earns its place, providing essential information without fluff. It is appropriately sized for a bulk operation tool with three parameters.

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

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

The description covers the tool's function, behavior, parameters, and return values ('message' and 'count'). It does not mention authentication requirements or potential partial-failure scenarios, but these are common to the tool family. Given the presence of a return schema and the clarity of execution semantics, the description is largely complete. A small gap is the lack of note about prerequisites like login, but this is not critical.

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

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

The input schema has no descriptions (0% coverage), but the description's 'Args' section explains each parameter: application_name is 'Name of the DBOS application', workflow_ids are 'IDs of the workflows to cancel', and cancel_children is 'Also cancel child workflows started by these workflows (default: false)'. This adds meaning beyond the schema's titles and fully compensates for the lack of schema descriptions.

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

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

The description starts with a specific verb+resource: 'Cancel multiple workflows at once.' This clearly states the tool's function and distinguishes it from the sibling 'cancel_workflow' (single cancellation). The scope is explicitly batch, which differentiates it effectively.

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

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

The description implies usage context by stating 'Cancel multiple workflows at once,' making it clear this is for bulk operations. However, it does not explicitly name alternatives (e.g., 'use cancel_workflow for a single workflow') or exclusions. The context is clear, but exclusions are absent.

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 explicitly states 'Permanently deletes' and 'execution history', which highlights the destructive and irreversible nature. It also explains the 'delete_children' flag's effect on child workflows. However, it does not mention potential non-atomic behavior or error handling, though the core safety concern is addressed.

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 well-structured with a summary sentence, 'Args' section, and 'Returns' section. It is slightly verbose but each sentence provides necessary detail. The formatting aids comprehension, though it could condense the redundancy between the first sentence and the 'Args' content.

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

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

The description covers the tool's purpose, parameters, return values, and destructive behavior, which is sufficient for a delete operation. It does not mention permissions, rate limits, or what happens if some IDs are invalid, but given the output schema exists and the destructive nature is clear, it is reasonably complete.

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

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

The schema has 0% description coverage, but the description compensates fully by defining each parameter: application_name as 'Name of the DBOS application', workflow_ids as 'IDs of the workflows to delete', and delete_children with its default behavior. This adds meaning beyond the schema's bare type and title.

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

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

The description clearly states 'Delete multiple workflows at once' with a specific verb and resource, and it distinguishes itself from the sibling 'delete_workflow' by including 'multiple' and 'bulk' in both name and description. It also notes the permanent deletion of workflows and their execution history, making the scope unambiguous.

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

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

The description clearly implies use for bulk deletion, but it does not explicitly mention when to use this tool versus the single-delete alternative. It provides context by noting the optional 'delete_children' behavior, but lacks explicit exclusions or alternative recommendations.

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 the valid input states (CANCELLED, ENQUEUED), the effect on queue (bypass or enqueue via queue_name), and the return values. This goes beyond the bare mutation semantics and gives the agent a solid understanding of behavior.

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

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

The description is efficiently structured with a one-sentence summary, a short behavioral paragraph, then clearly labeled 'Args' and 'Returns' sections. Every sentence earns its place, with no redundancy or fluff.

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

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

The description fully explains the tool's purpose, target states, optional queue behavior, all parameters, and the return format. Given the tool's moderate complexity, this is complete and self-contained.

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 'Args' section adds meaning beyond the schema: it labels application_name as required, describes workflow_ids as 'IDs of the workflows to resume,' and for queue_name explains the behavioral consequence ('If provided, enqueue the resumed workflows onto this queue instead of running them immediately'). The schema itself provides only types and titles, so this is valuable.

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

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

The description opens with 'Resume multiple workflows at once,' which is a specific verb+resource statement. It further specifies the target states (CANCELLED and ENQUEUED), which distinguishes it from sibling tools like resume_workflow (singular) and bulk_cancel_workflows.

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

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

The description provides clear context on when to use the tool: 'Resumes execution of workflows that are in CANCELLED state' and 'You can also use this on workflows in ENQUEUED state to immediately start them, bypassing their queue.' While it doesn't explicitly mention alternatives like resume_workflow, the bulk nature and state-specific behavior imply the appropriate use case.

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

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

With no annotations provided, the description carries the full burden. It discloses the state change to CANCELLED, the execution-boundary behavior, and the effect of cancel_children. It does not mention permissions or reversibility, but the core side effects are transparent.

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

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

The description is well-structured with an introductory statement, behavioral details, an Args block, and a Returns block. Every sentence serves a purpose, and the information is front-loaded, making it easy to scan.

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

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

For a simple 3-parameter tool with no annotations, the description covers purpose, behavior, all parameters, and return values (message, workflow_id). It provides everything an agent needs to invoke the tool correctly without external 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 0%, so the description must compensate. The Args block fully documents all three parameters: names, types, requiredness, and the default for cancel_children. This adds complete semantic meaning beyond the raw 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?

The description opens with 'Cancel a running workflow' and specifies that it sets the status to CANCELLED and stops at the next step boundary. This provides a specific verb and resource, clearly distinguishing cancellation from resume, delete, or bulk-cancel operations.

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 indicates that the tool applies to running workflows and explains the cancellation behavior, giving clear context for use. It does not explicitly name alternatives or state when not to use it (e.g., for already-completed workflows), but the guidance is sufficient for typical use.

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

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

With no annotations provided, the description carries the full burden. It explicitly warns that the operation is permanent and deletes execution history, and it clarifies the optional delete_children parameter's effect. It does not disclose permission requirements or possible side effects beyond the mentioned ones, but it covers the critical destructive nature well.

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 concise and well-structured: a one-sentence purpose, a clarifying sentence on permanent deletion, a clean Args list, and a Returns list. Every sentence adds value, and the format is easily scannable. There is no redundant information.

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

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

Given that the tool has only three parameters, two required, and an output schema, the description is nearly complete. It covers all parameters and return values. It lacks details on error conditions, permissions, or whether the deletion of children is recursive, but these are not essential for basic invocation. The description is sufficient for correct use.

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

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

The input schema provides only titles with no descriptions (0% schema description coverage). The description's Args section adds essential meaning for all three parameters: application_name, workflow_id, and delete_children, including types, required status, and default values. This fully compensates for the schema's lack of detail.

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

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

The description clearly states the tool's function: 'Delete a workflow from DBOS Conductor' and 'Permanently deletes a workflow and its execution history.' This uses a specific verb and resource, and the permanent deletion detail distinguishes it from sibling tools like cancel_workflow or pause_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 description implies usage when a workflow and its execution history should be permanently removed, but it does not explicitly contrast with alternatives like cancel_workflow or resume_workflow. There is no 'when not to use' guidance, so the usage context is clear but lacks explicit exclusions or alternative recommendations.

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?

Without annotations, the description takes on the full burden. It clearly discloses that new workflows are created, prior step outputs are reused, and exactly one of the from_* parameters must be set. It does not mention permissions, reversibility, or effects on the original workflows, but core behavior is transparent and there is no contradiction.

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 front-loaded with a clear summary, followed by a succinct usage context, a complete parameter list, and return value explanation. Each sentence earns its place without redundancy.

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

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

Given the tool's complexity (9 parameters, no annotations), the description covers purpose, usage, parameters, and return values. It lacks edge-case behaviors like error conditions or prerequisites, but the presence of an output schema and detailed Args make it largely complete.

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

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

The description provides a detailed Args section explaining every parameter, including defaults and semantics, such as 'application_version' defaulting to the current version and 'queue_name' enqueueing forked workflows. This fully compensates for the 0% schema description coverage.

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

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

The description opens with 'Fork multiple failed workflows from a specific point' and elaborates 'Creates new workflows that re-execute from a chosen point, reusing the recorded outputs of all prior steps.' This clearly identifies the verb, resource, and scope, distinguishing it from singular fork_workflow or resume_workflow.

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 explicitly states 'Useful for retrying a batch of failed workflows after deploying a fix' and enforces a critical constraint on the from_* parameters. However, it does not name alternative tools or provide when-not-to-use guidance, so it stops short of a 5.

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

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

With no annotations, the description carries the disclosure burden. It explains the key behavior of 'reusing the recorded outputs of all prior steps' and creating a new workflow. It also notes that queue_name causes enqueuing instead of immediate execution, adding meaningful behavioral context beyond the tool's 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 well-structured with a summary, named parameters with inline explanations, and a returns section. Each sentence adds value, and the format makes it easy for an agent to parse quickly.

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

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

The description covers all 7 parameters, explains the return values, and gives usage hints. For a 7-parameter tool with an output schema, this is thorough and complete, leaving no critical gaps for correct invocation.

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

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

The description includes a complete Args section explaining every parameter, including guidance like 'use list_steps to find step IDs' for start_step. Since schema coverage is 0%, this fully compensates for the schema's lack of property descriptions and adds significant meaning.

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

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

The description uses the specific verb 'fork' with the resource 'workflow' and clearly scopes it 'from a specific step.' It distinguishes from the sibling fork_from_failure by emphasizing arbitrary step selection, making the purpose 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 states 'Useful for debugging, testing fixes, or replaying workflows from a specific point,' providing clear usage context. It does not explicitly exclude alternatives like fork_from_failure, but the context is enough for an agent to infer when this tool 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 of behavioral disclosure. The verb 'Get details' and the absence of any mutation language imply a read-only operation, and the Returns section transparently describes what data is returned. However, it does not explicitly state that the operation has no side effects, how errors are handled (e.g., schedule not found), or any authentication requirements. For a read-only lookup this is acceptable but not fully transparent.

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

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

The description is front-loaded with a clear one-sentence purpose, followed by structured Args and Returns sections. However, the Returns section is quite long and largely duplicates the output schema that already exists (context shows has_output_schema: true). While it adds some nuance (e.g., 'omitted for private-mode applications'), the repeated field listing makes the description less concise than it could be. The structure is orderly, but the length is not fully justified given the output 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 simple two-parameter lookup tool with an output schema present, the description is mostly complete: it states the purpose, explains both parameters, and details the return fields with optionality and enums. Minor gaps include lack of explicit usage guidance (when to choose get_schedule over list_schedules) and no mention of error behavior or permissions. These are not critical for a read-only get operation, so the overall completeness is high but not maximal.

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

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

Schema description coverage is 0%, so the input schema provides only names and types with no meaning. The description compensates with an Args section that clearly defines each parameter: 'application_name (string, required): Name of the DBOS application' and 'schedule_name (string, required): Name of the schedule'. This gives enough semantic grounding for an agent to supply the correct values, though it could be enriched with formatting or example values. The compensation is solid but not exhaustive.

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

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

The description opens with a specific verb ('Get') and resource ('details of a specific schedule from DBOS Conductor'). This clearly identifies the operation as a single-item lookup, distinguishing it from sibling tools like list_schedules (which lists schedules) and pause_schedule/resume_schedule/trigger_schedule (which modify schedule state). The word 'specific' reinforces that it targets one schedule, not a collection.

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

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

The description implies when to use the tool: when you need details about a particular schedule identified by application_name and schedule_name. However, it does not explicitly contrast with list_schedules for enumeration or mention any exclusions (e.g., 'use list_schedules to see all schedules'). No alternatives or when-not-to-use guidance is provided, leaving usage context implied rather than explicit.

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

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

Without annotations, the description relies on the word 'Get' to convey a read-only operation, but it does not explicitly state side-effect-free behavior or authorization needs. It compensates with detailed return fields but omits edge-case behavior such as what happens if the workflow ID does not exist.

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 one-sentence purpose is front-loaded, followed by clearly labeled Args and Returns sections. The return list is long, but each field includes explanatory semantics that would not be in a bare output schema, so it 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 single-workflow read, the description covers both parameters and all return fields with human-readable meanings. It is slightly incomplete in that it does not describe error handling or not-found behavior, but these are minor for a simple getter.

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

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

Schema description coverage is 0%, and the description fully compensates by describing each parameter: 'Name of the DBOS application' and 'ID of the workflow to retrieve.' It also clarifies which are required.

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 details of a specific workflow from DBOS Conductor.' This clearly differentiates from siblings like list_workflows, which return multiple workflows, and cancel_workflow, which mutates.

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 explicit guidance on when to use this tool vs alternatives. While the phrase 'specific workflow' implies an ID lookup, it does not mention list_workflows for listing or state when not to use it. The agent is left to infer usage from 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?

With no annotations, the description carries full behavioral disclosure burden and does so thoroughly. It documents required flag combinations, failure behavior, return shape details, and a subtle format caveat that time_bucket values are Unix epoch millisecond strings rather than ISO 8601. This richly exceeds the minimum needed for safe invocation.

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 long but every section earns its place: a front-loaded summary, usage guidance, a complete Args list, and a return-value breakdown. The structured layout makes the high parameter count navigable rather than overwhelming.

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 25 parameters, no annotations, and zero schema descriptions, the description is exceptionally complete. It covers all required invocation constraints, parameter semantics, and return values, leaving no obvious gap an agent would need to guess about.

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

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

Schema description coverage is 0%, and the description compensates fully by documenting all 25 parameters with types, required status, defaults, and semantics. It adds meaningful meaning beyond the bare schema, such as explaining filters like workflow_id_prefix and the meaning of time_bucket_size_ms.

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 the specific verb-resource relationship ('Get workflow aggregate metrics') and clearly distinguishes from siblings like list_workflows or get_workflow by emphasizing grouped, dashboard-oriented summaries. Concrete example questions ('how many workflows failed today?') reinforce the tool's distinct purpose.

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

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

Provides clear context for when to use the tool ('useful for dashboards and understanding workflow status at a glance') and gives mandatory usage rules: at least one select_* flag and at least one group_by_* flag, with the failure consequence for missing group_by. It does not explicitly name alternatives like list_workflows for raw enumeration, but the aggregate-vs-list distinction is strongly 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains the event model, the direction of events, and even notes that a workflow that never received anything can still have events. While it doesn't discuss side effects, it clearly implies a read operation and provides behavioral context beyond a simple 'get'.

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 well-structured with an opening summary, a clarifying note on event direction, an explicit alternative, and clearly labeled Args/Returns sections. It is slightly longer than strictly necessary, but every section adds useful information, and the structure aids comprehension.

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

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

Given the tool's modest complexity, two simple string parameters, and the presence of an output schema, the description is complete. It covers the event model, parameter meanings, return value shape, and the relevant sibling alternative, leaving no critical gap for an agent to invoke the tool 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 0%, so the description fully compensates by documenting both parameters in the Args section: application_name as 'Name of the DBOS application' and workflow_id as 'ID of the workflow'. This gives the agent the semantic meaning needed to populate the required fields correctly.

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

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

The description opens with a specific verb and resource: 'Get events published by a workflow from DBOS Conductor.' It also distinguishes itself from the similar sibling get_workflow_notifications by explicitly contrasting outbound events with messages sent TO a workflow, making its purpose 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 gives clear usage context: events are outbound, published via setEvent, and read via getEvent by anyone holding the workflow ID. It explicitly names the alternative tool for inbound messages ('To see messages sent TO a workflow, use get_workflow_notifications instead.'), giving an agent a direct routing decision.

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

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

With no annotations, the description carries the full burden and mostly succeeds. It explains the inbound send/recv model, highlights a key distinction from events (multiple notifications per topic), and documents the consumed flag in the output. However, it doesn't cover ordering, pagination, or empty-result behavior, leaving minor gaps.

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

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

The description is well-structured and mostly concise, with a clear opening line, an Args section, and a Returns section. The Returns block is a bit verbose given that an output schema exists, but it doesn't feel bloated.

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

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

The description covers the tool's core inputs and output shape sufficiently for an agent to call it correctly. Since the tool has only two simple string parameters and the return structure is documented, missing finer details like error responses or empty-array behavior are acceptable.

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

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

Schema description coverage is 0%, so the description must compensate. The Args section only restates the parameter names as 'Name of the DBOS application' and 'ID of the workflow,' adding little beyond the schema's titles. No format, constraints, or source guidance is provided.

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 notifications received by a workflow from DBOS Conductor.' It then explicitly differentiates the tool from get_workflow_events, so an agent can immediately tell which sibling to use.

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

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

The description gives explicit usage guidance: 'This is the tool to use for "what did this workflow receive?"' and directs users to get_workflow_events for the opposite case. This is exactly the kind of when-to-use vs. alternative guidance that helps an agent select correctly.

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 disclosure burden. It does state the output shape in detail (applications array and count) and implies a read-only, unfiltered operation. However, it does not mention authentication, pagination/limits, or ordering, and it never explicitly states that the operation has no side effects.

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 intent line is concise and front-loaded. The long Returns block is well-structured but largely duplicates the available output schema, so many lines do not earn their place in the description. It would be stronger if it cut to the scope statement and only noted non-obvious output details.

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

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

For a zero-parameter read-only list with an output schema, the description covers the essential scope and return container. It lacks usage guidance and behavior caveats like pagination, but those are less critical given the tool's simplicity. Overall it provides enough context for an 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?

The input schema is empty and schema coverage is 100%, so there are no parameter semantics to document. The baseline for zero-parameter tools is 4, and the description adds nothing misleading. No extra parameter information is needed.

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

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

The description opens with a specific verb and resource: 'List all applications registered with DBOS Conductor.' It clearly identifies the operation and scope. It does not explicitly distinguish this from siblings such as list_application_versions, so it lacks direct 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?

No guidance is provided about when to choose this tool over siblings such as list_application_versions, list_workflows, or list_executors. The description only says what it does, not the context or exclusions. An agent must infer usage from the name and sibling list.

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

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

With no annotations, the description carries the behavioral disclosure burden. It explains the version-recording behavior, the read-only nature implied by 'List all versions,' and the exact return shape. It does not cover pagination, ordering, or error behavior, but those are minor for this simple list 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?

The purpose is front-loaded in the first sentence, followed by a compact Args/Returns structure with no redundant information. Every line adds value.

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

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

For a one-parameter, no-nested-objects list operation with an output schema, the description is complete. It provides the application name semantics, the version-creation rule, and detailed return fields, so an agent has everything needed to call and interpret the tool 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 0%, so the description must fully define the parameter. It does: 'application_name (string, required): Name of the DBOS application.' This adds precise meaning beyond the schema's bare property title.

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

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

The description uses a specific verb and resource: 'List all versions of an application from DBOS Conductor.' It clearly identifies the tool's output and distinguishes itself from related version-control behavior by referencing set_latest_application_version.

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 when versions are recorded and points to a sibling tool, set_latest_application_version, for controlling the current version. It provides useful context but does not explicitly contrast this tool with other listing tools such as list_applications.

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 behavioral disclosure burden. 'List' clearly signals a read-only enumeration, and the description adds context about what executors are and their possible statuses. However, it does not explicitly state that the operation has no side effects, nor does it mention authentication, rate limits, or pagination behavior.

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

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

The description is front-loaded with the main purpose and then organized under Args and Returns headings, making it easy to scan. The Returns section is extensive, but it provides field-level semantics that an agent would need if the output schema lacked descriptions. No sentence is purely filler.

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

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

For a simple list operation with one required parameter and an output schema available, the description covers the essential invocation knowledge: what the tool does, what argument to provide, and what shape the result takes. It lacks explicit guidance on when to prefer this over sibling tools, but the distinct resource type makes that less critical here.

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

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

Schema description coverage is 0%, so the description must compensate for the schema's bare property definition. It does so by documenting application_name as '(string, required): Name of the DBOS application,' adding semantic meaning beyond the type and title. For a single-parameter tool, this is sufficient.

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

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

The description opens with a specific verb-resource pairing: 'List executors for an application from DBOS Conductor.' It clearly identifies the resource (executors), the scope (per application), and the system (Conductor), which distinguishes it from sibling list tools like list_applications, list_workflows, and list_steps.

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 establishes clear context: use this tool to retrieve executors running for a specific DBOS application. It does not explicitly name alternative tools or conditions for exclusion, so it stops short of a 5, but the 'for an application' qualifier makes the usage scenario unambiguous.

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

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

With no annotations provided, the description carries the full behavioral burden and handles it well: it discloses the return envelope (schedules/count/application), field-level semantics, and the private-mode omission of the context field. It does not disclose pagination/limits, result ordering, or authentication requirements, which are relevant for a listing tool in an API with login-gated siblings.

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?

Purpose is front-loaded and the layout is scannable: purpose, domain context, args, then returns. The Returns block is long, but nearly every field carries a type and a semantic note, so it earns its place, even though some of it duplicates what the available output schema already provides.

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?

Core invocation is fully specified: one required parameter and three optional filters with clear semantics. Missing pieces for a list tool are pagination/limit behavior, authentication prerequisites given the login/login_complete siblings, and differentiation from get_schedule. Return values are over-covered since an output schema already exists.

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

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

Schema description coverage is 0%, and the Args section fully compensates: all four parameters receive semantics beyond their bare type/title, application_name is flagged as required, and status gets example values ('ACTIVE', 'PAUSED') since the schema defines no enums. The only gap is that status values are not exhaustively enumerated.

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 opening sentence names a specific verb ('List'), resource ('schedules'), and scope ('for an application from DBOS Conductor'). The follow-up sentence explains the domain concept — schedules automatically trigger workflows on a cron-based schedule — which helps an agent distinguish this from workflow-listing or mutation siblings like 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?

No guidance distinguishes this tool from the singular get_schedule sibling or the schedule mutation tools (pause_schedule, resume_schedule, trigger_schedule) that appear in the sibling list. The filter documentation implies usage scenarios but provides no when-to-use vs. when-not-to-use direction, and no alternatives are named.

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

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

With no annotations provided, the description carries the full burden of disclosing behavior. It clearly discloses a read-only 'Get' operation, pagination parameters, and detailed return fields, which sets proper expectations about what the tool does and returns.

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 well-structured with a clear first sentence followed by Args and Returns sections. The Returns section is somewhat redundant since an output schema exists, but the overall length is reasonable and the information is organized.

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

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

The description covers all parameters, optionality, and return shape, and an output schema exists to supplement return details. It is missing explicit guidance on ordering, pagination defaults, or error behavior, but these are minor gaps for a straightforward listing operation.

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

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

The input schema has 0% description coverage, but the description fully compensates by explaining every parameter: application_name, workflow_id, limit, and offset, including types and optionality. This is exactly the semantic detail an agent needs to invoke the tool correctly.

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

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

The description opens with 'Get execution steps for a workflow from DBOS Conductor', which clearly names the verb, resource, and context. This distinguishes it from siblings like list_workflows and get_workflow.

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

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

The description implies this tool is for retrieving steps of a specific workflow, and the sibling list shows related tools. However, it does not explicitly state when to use this tool versus alternatives such as get_workflow or list_workflows, nor does it mention exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly: it documents defaults (sort_desc default false/ascending), private-mode constraints ('always false for private-mode applications'), nuanced filter semantics for was_forked_from (true/false behavior plus pointer to forked_from), and cross-tool notes like 'get_workflow always returns it'. This goes far beyond a minimal statement of side effects.

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 long (~60 lines) but well-structured with clear Args and Returns sections and no filler prose. The purpose line is front-loaded, and parameter lines are consistently formatted. The return-field enumeration is extensive but necessary given the lack of output schema details; overall the length is justified by the 26-parameter, 30-field surface.

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

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

Given the tool's complexity and the absence of annotations and schema descriptions, this description is essentially complete: it covers all parameters, defaults, return fields, conditional output behavior, and special cases like private-mode applications and fork/parent semantics. The only missing element is explicit sibling-tool routing, which is already scored under usage guidelines.

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

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

Schema description coverage is 0%, so the description must fully compensate, and it does. All 26 parameters receive type, optionality, default, and behavioral detail (e.g., status lists valid enum values, was_forked_from clarifies fork-source semantics, limit/offset explain pagination). This is a model of how parameter descriptions should augment an empty 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?

The description opens with 'List workflows from DBOS Conductor with optional filters' – a specific verb, resource, and scope. It clearly separates this from sibling tools like get_workflow (singular) and list_applications/list_steps (other resources), even without naming them. The purpose is immediately understandable.

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 guidance about when to use this tool versus siblings such as get_workflow, list_workflow_aggregates, or list_executors. The optional filters suggest a search/browse use case, but no when-to-use context or exclusion conditions are given. The agent must infer usage solely from the tool name and verb.

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

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

With no annotations provided, the description discloses that the tool returns a URL that must be opened in a browser and that authentication must be completed via a separate call. It also states the return format as a dictionary with URL and instructions. This is transparent about the tool's role and limitations, though it omits details like error handling or token expiration.

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

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

The description is three short, clearly separated sentences/paragraphs. It front-loads the purpose, then gives flow details and return info. Every sentence is useful; no redundancy or fluff.

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

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

For a simple zero-parameter tool with no annotations, the description covers the essential workflow, return value, and the required next step. The presence of an output schema is noted, and the description's mention of the dictionary return is sufficient. The only minor gap is the content of 'instructions,' but this is not critical for invocation.

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

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

The input schema has no parameters, so the description has nothing to add. Per the baseline for zero-parameter tools, this earns a 4. The description correctly avoids inventing parameter documentation.

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 first sentence clearly states the tool 'Start DBOS Cloud login flow,' using a specific verb and resource. It distinguishes from the sibling tool login_complete by explicitly mentioning the follow-up step. The description also specifies the return value, making the purpose 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 implies usage by explaining the two-step process: call this tool to get a URL, then call login_complete after authenticating. This provides clear context for when this tool is needed and its relationship to the sibling login_complete, though it does not explicitly list 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 full burden. It discloses the success return value (dictionary with userName and organization) but does not mention failure behavior, idempotency, or what happens if called prematurely. This is adequate but not rich.

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

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

The description is two sentences plus a return-value note, with the action verb and target stated upfront. Every sentence adds necessary context, and there is no redundant or filler content.

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

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

For a zero-parameter tool with an output schema, the description adequately covers purpose, sequencing, and return values. It is sufficiently complete for the agent to invoke it correctly within the login flow.

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 has zero parameters, so schema coverage is 100% and the description correctly focuses on usage context rather than parameter details. The baseline for zero-parameter tools is 4, and the description fulfills that by explaining the flow.

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?

Clearly identifies the action as completing the DBOS Cloud login flow after browser authentication. The verb 'complete' plus the specific resource 'DBOS Cloud login' distinguishes it from the sibling 'login' tool, which presumably initiates the flow.

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 explicit sequencing guidance: 'Call this after you have opened the login URL and authenticated.' This clearly states when to use the tool, though it doesn't explicitly mention alternatives or exclusions. The sibling 'login' is implicitly the prerequisite.

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 reveals the core effect (stops triggering new workflows) and reversibility (can be resumed later), which is helpful. However, it omits details such as whether in-flight workflows are affected, idempotency, or required permissions, leaving notable gaps.

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

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

The description is well-structured: a concise summary sentence, a useful cross-reference to resume_schedule, and clearly formatted Args/Returns sections. Every sentence earns its place with no redundancy or fluff.

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

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

For a simple two-parameter tool, the description is largely complete. It covers the action, its effect, the key counterpart tool, parameter meanings, and the return format. It lacks edge-case details (e.g., error conditions, behavior when already paused), but given the tool's simplicity and existing output schema, these omissions are acceptable.

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

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

The input schema has no descriptions (coverage 0%), so the description must compensate. It does so by providing meaningful definitions for both parameters: 'Name of the DBOS application' and 'Name of the schedule to pause.' This adds clear value beyond the schema's bare titles, though it could go further with guidance on sourcing these values.

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

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

The description uses a specific verb and resource ('Pause a schedule') and adds the clarifying effect 'stopping it from triggering new workflows.' This clearly distinguishes it from sibling tools like resume_schedule and trigger_schedule, making the purpose 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 provides clear context by noting the schedule 'can be resumed later with resume_schedule,' giving the agent a direct counterpart and implying the appropriate use case. However, it does not explicitly state when not to use it or list alternatives like cancel_workflow, so it stops short of a 5.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention side effects, prerequisites (e.g., schedule must exist or be paused), idempotency, permissions, or behavior if the schedule is already running. This lack of edge-case behavior transparency is a significant gap for a 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?

The description is a single sentence followed by a structured Args/Returns block. It is concise, front-loaded with the purpose, and contains no redundant or extraneous information. Every element contributes value.

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

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

The operation is simple (resume a schedule), and the description covers the core purpose, parameters, and return values. An output schema exists, so return details are not required. However, missing edge-case behavior and prerequisites prevent a perfect score, though these are less critical for a straightforward action.

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

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

The schema provides no descriptions (0% coverage), so the description's Args section fully compensates by explaining each parameter: application_name as 'Name of the DBOS application' and schedule_name as 'Name of the schedule to resume.' This adds crucial meaning beyond the raw 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?

The description clearly states the specific action: 'Resume a paused schedule, allowing it to trigger workflows again.' It identifies the resource (schedule) and the effect, distinguishing it from sibling tools like resume_workflow (resumes a workflow) and trigger_schedule (triggers a schedule immediately).

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

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

The description implies the tool is used when a schedule is paused, but it does not explicitly state when not to use it or mention alternatives. For instance, it does not say 'to resume a workflow, use resume_workflow' or 'to trigger immediately, use trigger_schedule.' The context is clear from the name and phrasing, but no explicit guidance is provided.

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 explains state requirements, the effect of queue_name (enqueue vs immediate), and the bypass behavior for ENQUEUED workflows. This is solid behavioral disclosure, though it doesn't cover potential edge cases like idempotency or failure behavior.

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

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

The description is concise and well-structured, with a clear main sentence, usage constraints, Args section, and Returns section. Every sentence earns its place, and the format aids readability.

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

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

Given the tool's moderate complexity, the description covers purpose, usage, parameters, and return values. The output schema and parameter documentation make it self-sufficient. It provides enough context for an agent to invoke the tool correctly without needing external information.

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

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

Schema description coverage is 0%, so the description must fully explain parameters. The Args section does exactly that, providing names, types, requiredness, and meaning (e.g., 'If provided, enqueue the resumed workflow onto this queue instead of running it immediately'). This adds significant value beyond the raw 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?

The description clearly states the tool's function: 'Resume a workflow' with specific conditions ('in CANCELLED state'). It distinguishes from sibling tools like cancel_workflow and bulk_resume_workflows by focusing on a single workflow 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?

Provides explicit when-to-use guidance: resumes CANCELLED workflows and can start ENQUEUED ones immediately. Also states exclusions ('You cannot resume a workflow in any other state'). However, it does not mention alternative sibling tools like bulk_resume_workflows, so it lacks explicit alternatives.

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 full burden. It does disclose the core behavioral effect ('controls which version is considered current') and lists return values, but omits potential side effects like reversibility, what happens to previous 'latest' versions, or any required permissions. This is adequate but not comprehensive.

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

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

The description is well-structured: a clear one-sentence purpose, a brief explanation of behavior, and neatly separated Args and Returns sections. Every sentence adds value, with no extraneous content.

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

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

For a simple two-parameter setter with an output schema, the description covers parameters, return values, and use cases. It lacks explicit guidance about how this tool relates to listing versions or any prerequisites, but overall it is sufficiently complete for a tool of this complexity.

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

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

The input schema has 0% description coverage, but the description's Args section thoroughly explains both parameters: application_name is 'Name of the DBOS application' and version_name is 'The version string to set as latest.' This fully compensates for the schema's lack of detail.

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

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

The description opens with 'Set the latest version for an application in DBOS Conductor,' a specific verb+resource statement. It further explains that this controls which version is considered current, which clearly distinguishes it from sibling tool 'list_application_versions'.

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 states 'Useful for rolling back to a previous version or promoting a specific version,' giving clear context for when to use the tool. However, it does not explicitly mention alternatives or when not to use it, so it stops short of a 5.

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

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

Since no annotations are provided, the description carries the full burden. It discloses that the trigger does not alter the schedule's regular cron timing and that workflow_id is optional ('if one was created'), adding valuable behavioral context beyond the basic operation. It lacks some edge-case details, but the main behavioral traits are covered.

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 concise and well-structured: a clear intro sentence, a valuable clarifying caveat, and labeled Args/Returns sections. Every sentence provides useful information, with no redundancy or 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 trigger tool, the description covers the essential aspects: action, parameters, and return values. It does not address potential edge cases (e.g., error behavior when schedule is paused) but remains reasonably complete given the scope and absence of annotations.

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

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

With 0% schema description coverage, the description must compensate. It does so by listing both parameters with clear descriptions: 'Name of the DBOS application' and 'Name of the schedule to trigger'. This provides the meaning needed to populate the arguments, although it adds no extra nuance like format or examples.

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

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

The description clearly specifies the action: 'Manually trigger a schedule to run its workflow immediately.' This identifies the verb (trigger), resource (schedule), and outcome (run workflow), effectively distinguishing it from siblings like 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?

The description implies when to use it (for immediate manual runs) and includes a key caveat that it does not affect cron timing. However, it does not explicitly name alternatives or state when not to use this tool, so guidance is implied rather than explicit.

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