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 that the tool creates a file and returns a status with a file path, adding useful context beyond basic functionality. However, it doesn't cover critical behavioral traits like error handling, authentication needs, or rate limits, leaving gaps 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 appropriately sized and front-loaded, starting with the core purpose followed by detailed parameter explanations and an example. While efficient, the example code could be slightly trimmed, but overall, each sentence adds value without unnecessary 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?

Given the tool's complexity as a mutation tool with no annotations and no output schema, the description is moderately complete. It covers parameters well and provides an example, but lacks details on return values beyond a vague 'status', error cases, or integration with sibling tools, leaving room for improvement.

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 adds significant meaning beyond the input schema, which has 0% coverage. It explains that 'name' is used as a filename with an example, 'description' clarifies its purpose, and 'code' specifies required Python structure including a 'run' function, effectively documenting all three parameters where the schema does not.

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

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

The description clearly states the verb 'Create' and the resource 'new Python workflow script', making the purpose evident. However, it doesn't explicitly differentiate from siblings like 'update_workflow' or 'read_workflow', which would require mentioning this is for initial creation only.

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 on when to use this tool versus alternatives like 'update_workflow' or 'execute_workflow'. The description implies usage for creating workflows but lacks explicit context or prerequisites, such as whether it overwrites existing workflows or requires specific permissions.

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 full burden for behavioral disclosure. It states the tool deletes a workflow, implying a destructive mutation, but doesn't specify permissions needed, whether deletion is permanent, error handling, or rate limits. The return value is vaguely described as 'Status of the operation' without detailing success/failure indicators.

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 appropriately sized and front-loaded with the core purpose in the first sentence. The Args and Returns sections are structured but could be more integrated. No redundant information is present, though the return description is vague.

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 destructive nature, no annotations, and no output schema, the description is incomplete. It lacks critical context such as confirmation prompts, side effects (e.g., related data deletion), error scenarios, or output structure details. For a mutation tool with zero annotation coverage, this leaves significant gaps for safe agent 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?

Schema description coverage is 0%, so the description must compensate. It adds that the 'name' parameter refers to 'The name of the workflow to delete', providing basic semantics beyond the schema's title 'Name'. However, it doesn't clarify format constraints (e.g., case-sensitivity, allowed characters) or examples, leaving gaps in parameter understanding.

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 verb ('Delete') and resource ('a workflow script'), making the purpose unambiguous. It distinguishes this tool from siblings like 'create_workflow' or 'update_workflow' by specifying deletion. However, it doesn't explicitly differentiate from other destructive operations beyond naming.

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 on when to use this tool versus alternatives. The description doesn't mention prerequisites (e.g., workflow must exist), consequences (e.g., irreversible deletion), or when to choose deletion over other operations like updating. It relies solely on the tool name for 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 provided, the description carries the full burden of behavioral disclosure. It states the tool executes a workflow and returns a result, but lacks details on permissions needed, side effects (e.g., whether execution is logged or affects system state), error handling, or performance implications. This is inadequate for a mutation tool with zero annotation coverage.

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 core purpose in the first sentence, followed by structured Arg and Return sections. Each sentence earns its place by defining parameters and output without redundancy. It's appropriately sized and well-organized for clarity.

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 complexity of executing workflows, lack of annotations, no output schema, and 2 parameters with nested objects, the description is incomplete. It doesn't explain what a 'workflow' entails, potential risks, authentication needs, or the format of the returned dict. More context is needed for safe and effective 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 description adds meaningful context beyond the input schema, which has 0% description coverage. It explains that 'name' identifies the workflow to execute and 'params' is an optional dictionary passed to the workflow's run() function, clarifying usage and intent. This compensates well for the schema's lack of descriptions, though it doesn't detail param structure or constraints.

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 verb 'execute' and resource 'workflow script by name', making the purpose evident. It distinguishes from siblings like create_workflow or list_workflows by focusing on execution rather than CRUD operations. However, it doesn't explicitly differentiate from potential alternatives like 'run_workflow' if they existed, keeping it at 4 instead 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., workflows must exist), exclusions, or comparisons to sibling tools like update_workflow or read_workflow. Usage is implied through the action but lacks explicit context for selection.

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 states the tool lists workflows and returns metadata, but lacks details on behavioral traits like pagination, sorting, filtering, error conditions, or performance characteristics. This is a significant gap for a tool with no annotation coverage.

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 appropriately sized and front-loaded, with the first sentence stating the core purpose and the second clarifying the return type. Both sentences earn their place by providing essential information without waste.

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 low complexity (0 parameters, no output schema, no annotations), the description is minimally adequate. It covers the basic purpose and return type, but lacks completeness for behavioral aspects like how the list is formatted or any limitations. This meets the minimum viable threshold with clear gaps.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add parameter details beyond the schema, but since there are no parameters, this is acceptable. Baseline is 4 as per rules for 0 parameters.

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 verb ('List') and resource ('workflow scripts'), specifying 'all available' to indicate scope. It distinguishes from siblings like 'execute_workflow' or 'read_workflow' by focusing on enumeration rather than execution or detailed viewing, though it doesn't explicitly differentiate from other list-like operations if they existed.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, such as needing workflows to exist, or compare it to siblings like 'read_workflow' for detailed metadata. Usage is implied by the name and purpose but not explicitly 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 burden of behavioral disclosure. It states the tool reads source code and metadata, implying a read-only operation, but doesn't disclose key traits such as whether it requires authentication, has rate limits, what happens if the workflow doesn't exist (e.g., error handling), or the format of returned metadata. For a read tool with zero annotation coverage, this leaves significant gaps in understanding its 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 appropriately sized and front-loaded, starting with the core purpose. The use of sections for 'Args' and 'Returns' adds structure, but the 'Returns' section could be more detailed given no output schema. There's minimal waste, though it could be slightly more informative without losing conciseness.

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

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

Given the tool's moderate complexity (reading source code with metadata), no annotations, no output schema, and low schema coverage, the description is incomplete. It doesn't explain the return value format beyond 'dict: The workflow source code and metadata,' leaving ambiguity. For a tool that likely returns structured data, more context is needed to be fully helpful to an AI agent.

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 adds meaning beyond the input schema by specifying that the 'name' parameter refers to 'The name of the workflow to read,' which clarifies its purpose. However, with 1 parameter and 0% schema description coverage, the schema provides no details, and the description doesn't fully compensate—it lacks information on name format, constraints, or examples. The baseline is adjusted due to low coverage, but the description offers some semantic value.

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 purpose as 'Read the source code of a workflow script,' which is a specific verb (read) and resource (workflow script). It distinguishes from siblings like create_workflow, delete_workflow, execute_workflow, list_workflows, and update_workflow by focusing on reading source code, but doesn't explicitly differentiate from list_workflows which might also involve reading metadata. The description avoids tautology and is not misleading.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention when to choose read_workflow over list_workflows (e.g., for detailed source vs. summary list) or other siblings, nor does it specify prerequisites like needing an existing workflow name. Usage is implied by the purpose but lacks explicit 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 burden of behavioral disclosure. It mentions that updates are partial (optional parameters keep existing values if not provided), which is useful. However, it lacks critical details: it doesn't specify if this requires specific permissions, whether changes are reversible, what happens on errors, or any rate limits. For a mutation tool with zero annotation coverage, this is a significant 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?

The description is well-structured and concise. It starts with a clear purpose statement, followed by bullet points for arguments and returns, with no wasted words. Every sentence adds value, and it's appropriately sized for the tool's complexity.

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 (3 parameters, mutation operation), no annotations, and no output schema, the description is partially complete. It covers the basic operation and parameters but lacks behavioral details like error handling, permissions, or return value specifics. It's adequate as a minimum but has clear gaps for safe and effective 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 description adds meaningful context beyond the input schema. The schema has 0% description coverage, but the description explains each parameter: 'name' identifies the workflow, 'description' is optional and retains existing if omitted, and 'code' is optional Python code that replaces existing if provided. This compensates well for the low schema coverage, though it doesn't detail format constraints (e.g., code syntax).

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 purpose: 'Update an existing workflow script.' It specifies the verb ('update') and resource ('workflow script'), making the action clear. However, it doesn't explicitly differentiate from sibling tools like 'create_workflow' or 'modify_workflow' if they existed, though the distinction is implied by 'existing'.

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

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., workflow must exist), compare to siblings like 'create_workflow' or 'delete_workflow', or specify contexts where it's appropriate. Usage is implied by the action but not explicitly stated.

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