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

There are no annotations, so the description must carry the burden of behavioral disclosure. It omits important details about whether activation is idempotent, what happens if the workflow is already active, whether permissions are required, or what side effects occur. It only states the basic 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 description is a single efficient sentence that front-loads the action and resource. There is no redundancy or 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?

The tool is simple with one parameter and an output schema, so a short description is acceptable. However, the absence of any behavioral context or usage guidance leaves meaningful gaps about activation semantics, making it only minimally viable.

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, but it only says 'by ID,' which essentially restates the workflow_id property name. It does not clarify ID format, how to obtain a valid ID, or any constraints beyond the schema's string type.

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 ('Activate') and resource ('a workflow') and indicates the key parameter ('by ID'). It is clearly distinguishable from siblings like deactivate_workflow and execute_workflow, though it does not explicitly contrast with them.

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 use this tool versus alternatives such as execute_workflow or update_workflow. The intended context is only implied by the name and verb, with no exclusions or preconditions 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?

With no annotations, the description carries full behavioral burden, and it does well by disclosing the special 'personal' project_id value, the root-vs-nested behavior, and the requirement on project_id. It does not mention permissions or error behavior, but for a straightforward create operation with an output schema these are secondary.

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

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

Three short, information-dense sentences with no filler. The core purpose comes first, followed by the most important parameter behavior, then the required-parameter nuance.

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

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

The tool is simple, has an output schema, and the description covers project_id, parent_folder_id, and placement behavior. Nothing essential to selecting or invoking the tool correctly is missing.

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

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

Schema description coverage is 0%, but the description compensates strongly: it explains project_id's required status and special 'personal' value, and it explains parent_folder_id's nesting semantics. The name parameter is adequately implied by 'Create a folder' and its string type in the 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 names a specific verb and resource ('Create a folder') and immediately scopes it to a project, which clearly separates it from the sibling create_workflow. It also clarifies the two placement modes (project root vs nested) in a way that adds precision beyond the tool name.

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

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

It gives task-specific guidance: pass parent_folder_id to nest, and project_id is required unless using the 'personal' alias. The pointer to list_folders for finding project_id is useful routing advice, but it does not explicitly discuss when not to use the tool versus a sibling.

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 burden. It usefully discloses required fields inside workflow and the default behavior of placing the workflow in the project root or personal project. However, it does not mention permissions, error behavior, or what happens on conflict, which are relevant behavioral traits for a creation 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 compact and front-loaded, beginning with the core action and requirement. Every sentence adds necessary information: required fields, folder placement, and project selection. 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?

The description covers the essential information needed to construct a valid create_workflow call: required fields and optional routing parameters. Since an output schema exists, return values need not be described. It could be more complete by mentioning error cases or permissions, but the main invocation context is sufficiently specified.

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

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

The schema provides only a generic workflow object with additionalProperties true and no property descriptions, so the description must compensate. It does so by enumerating required fields (name, nodes, connections, settings) and optional routing fields (parentFolderId, projectId), adding meaning the schema lacks. It stops short of fully defining the structure of nodes or connections, but the core semantics are covered.

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 ('Create a new workflow') and differentiates it from siblings like update_workflow, activate_workflow, and delete_workflow. It also clarifies the scope by specifying that this is for new workflows, not modifying or executing existing ones.

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 contextual guidance for when to include parentFolderId or projectId, which helps the agent decide how to construct the call. It does not explicitly name alternative tools or state when not to use this tool, but the create verb and the optional conditions make the intended usage clear.

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 implies a state change but does not explain whether deactivation is reversible, whether it stops running executions, or how it differs from deletion, which are important operational traits.

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

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

A single sentence with no filler, front-loading the action and immediately indicating the required parameter. Every word earns its place.

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

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

An output schema exists, so return-value documentation is not required, and the single parameter is simple. However, the absence of behavioral context and usage guidance makes the description incomplete for an agent choosing between deactivation, activation, execution, and deletion.

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. 'By ID' maps cleanly to the sole workflow_id parameter and clarifies that the identifier identifies the target workflow, though it adds little beyond the property name and does not describe ID format or provenance.

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 ('Deactivate') and names the resource ('a workflow') plus the identification method ('by ID'). It is clear and recognizable against siblings like activate_workflow and delete_workflow, though it does not explicitly contrast itself with them.

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

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

No guidance is given about when to deactivate a workflow versus activating, deleting, or executing it. The description simply states the action, leaving the agent to infer the appropriate context from the tool name alone.

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

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

With no annotations and no output schema details, the description must disclose behavioral implications. It states the delete action, but does not explicitly mention irreversibility, cascading effects on executions or folders, authentication requirements, or what happens if the workflow does not exist. These are significant gaps for a destructive 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 description is a single, front-loaded sentence with no extra words. Every part contributes to the core meaning, making it easy to parse and immediately actionable.

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

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

For a simple single-parameter delete tool, the core call shape is clear, but contextual details are missing: no usage conditions, no side-effect disclosure, and no mention of irreversibility. An agent invoking safely would benefit from knowing whether deletion is permanent or whether the workflow must be deactivated first.

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

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

The schema provides only a workflow_id string with no further description, and the description adds no new meaning beyond 'by ID.' With 0% schema description coverage, the description needed to clarify the ID format, source, or required state, but it simply restates the parameter name's obvious 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 states a specific verb and resource: 'Delete a workflow by ID.' It clearly identifies the action and the identifying parameter, and it differentiates from sibling tools like update_workflow, get_workflow, and activate_workflow by naming a distinct destructive operation.

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

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

No guidance is provided about when to use this tool versus alternatives such as deactivate_workflow or update_workflow. There is no mention of prerequisites, conditions, or consequences (e.g., whether the workflow must be inactive before deletion), leaving the agent to infer usage context.

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

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

With no annotations, the description carries the full burden, and it discloses important behavioral details: the execution goes through the webhook rather than a generic API, the workflow must be active, and data is placed into the workflow's $json.body. It does not cover error handling or permissions, but the primary constraints and side effects are clearly communicated.

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 focused sentences: the first names the action, the second explains the limitation and activation requirement, and the third explains parameter behavior. There is no filler, repetition, or unnecessary detail.

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 output schema is present and there are no annotations, the description supplies all essential context an agent needs: what the tool does, its scope and prerequisite, the absence of a generic alternative, and the semantics of data. For a two-parameter tool, this is complete.

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

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

Schema description coverage is 0%, so the description must add meaning, and it does. It explains that data is sent as the JSON request body and lands in $json.body, which is not apparent from the schema alone. The optionality of data is conveyed with 'if given,' matching the schema's default null.

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 pair ('Trigger a workflow's execution') and immediately narrows the mechanism to a Webhook trigger node. This clearly distinguishes it from workflow CRUD siblings like get_workflow or update_workflow by identifying both the action and its prerequisite.

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

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

It explicitly states the key precondition: the tool only works for workflows that contain a Webhook trigger node, and the workflow must be active for the webhook to respond. It also explains the API limitation (no generic 'run workflow by ID' endpoint), setting clear expectations, though it does not enumerate explicit alternatives or when-not-to-use cases beyond that.

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 reveals one useful behavioral trait: input/output data is excluded unless include_data=True. However, it does not state whether this is a read-only operation, how it handles missing IDs, or what happens if include_data is requested for an execution with no data.

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 concise sentences: the first states the primary action and target, the second explains the optional flag. There is no filler or redundant phrasing.

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 get-by-ID tool with two parameters and an output schema, the description covers the main actions and the optional data-inclusion behavior. It is adequate for a first-time caller, though it could be more complete by noting that get_execution is a read-only lookup, distinct from execution-triggering siblings.

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 explains execution_id as the identifier of the execution and clarifies that include_data=True controls inclusion of input/output data. This adds meaning beyond the raw schema, though execution_id's semantics are largely inferable from the parameter name.

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

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

The description clearly states a specific verb ('Get') and resource ('details of a specific execution by ID'), which is enough to understand the tool's core function. It does not explicitly name sibling alternatives like list_executions, so it stops short of full sibling differentiation.

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

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

The description provides no guidance on when to use this tool versus list_executions, execute_workflow, or get_workflow. The only usage-related hint is the include_data flag, which explains an option rather than when the tool should be chosen.

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 itself communicates that this is a read-only retrieval operation and that the response contains the workflow's definition. It doesn't discuss auth requirements or not-found behavior, but the 'Get' framing makes the non-mutating intent clear.

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

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

A single sentence that is front-loaded with the action, names the target resource, and adds the useful detail about what the definition includes. There is no redundant wording or repetition of schema fields.

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-parameter, get-by-ID tool with an output schema, the description is sufficient. It clearly states what will be returned and covers the essential retrieval semantics without needing to enumerate error cases or return fields.

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?

Although the schema provides no descriptive text for workflow_id, the description explicitly says 'by ID', which clarifies the parameter's role. With only one required parameter, there is little room for ambiguity, though no ID format or example is given.

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 ('Get'), a clear resource ('a workflow'), and identifies the retrieval key ('by ID'). It also specifies the content scope ('nodes, connections, settings'), which distinguishes it from tools like get_execution or list_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 implies usage: call this tool when you need the full definition of a specific workflow. It does not explicitly contrast with get_execution or list_workflows, but the singular 'a workflow by ID' conveys the intended 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 of behavioral disclosure. It usefully reveals the default limit of 100, the n8n cap of 250, and the possibility of truncated results, which are important behavioral traits beyond a simple 'list' statement. It does not mention ordering or pagination details, but the output schema covers return shape.

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 compact and efficient, with the main purpose front-loaded and the limit/cap guidance placed in a natural follow-up. Every sentence adds useful information without redundancy or 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 list tool with three optional parameters and an output schema, the description covers the essential operational details: what is listed, how to filter, and the default/cap behavior. It does not address alternative tool selection explicitly, but the main gaps are minor and the presence of an output schema reduces the need to describe return values.

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, and it does: it interprets the status parameter by listing valid values (success, error, running, waiting), explains the limit parameter's default and cap, and clarifies workflow_id as a filter. The workflow_id description could be more detailed on format, but all three parameters receive some meaningful semantic guidance.

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 the exact operation ('List workflow executions') and names the resource explicitly. It also specifies the available filters (workflow ID or status) and lists the valid status values, making the tool's purpose unambiguous and distinguishable from sibling tools like get_execution or list_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 gives clear context on when to use this tool and how to configure it, including optional filters and limit behavior. It does not explicitly compare against alternatives such as get_execution, but the 'List' scope is clear enough that an agent will understand this is for multiple executions rather than a single one.

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

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

With no annotations, the description carries the full burden and does an excellent job. It discloses the API limitation around project_id discovery, the default 10-per-page behavior, and the critical silent truncation of results, which an agent must know to avoid missing data.

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 opening sentence followed by tightly scoped paragraphs on required context and pagination. Every sentence adds value, 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 5-parameter tool with no annotations and an output schema present, the description covers all the essential behavioral and usage context an agent needs: required parameter, discovery fallback, filtering options, and pagination pitfalls. Nothing critical appears missing.

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

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

Schema coverage is 0%, so the description must explain all parameters, and it does. It explains project_id's necessity and discovery path, name and parent_folder_id as filters, and take/skip for pagination, adding significant 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 uses a specific verb ('List folders within a project') and names the resource and available filters, making the purpose immediately clear. It also differentiates from sibling tools by scoping to folders and noting optional filtering by parent folder or name.

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 practical guidance: project_id is required, how to discover it if unknown, and when to increase take or use skip. It does not explicitly list when not to use the tool or name an alternative listing tool, but the context is strong enough for an agent to select it appropriately.

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

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

With no annotations, the description carries the behavioral burden. It adds meaningful details beyond the schema: the default of 100 results, n8n's hard cap of 250 per request, and a caveat about truncated results. This gives the agent useful expectations about limiting and 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 compact and front-loaded. The first sentence states the core purpose and filters; the following sentences add only necessary behavioral caveats. Every sentence earns its place and there is no 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 low-complexity list tool with an output schema, the description covers everything needed to call it correctly: what it lists, how to filter, how many results to expect, and the hard limit caveat. No required parameters exist, so no prerequisite guidance is needed.

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 explain the parameters, and it does. It maps 'name' to a filter, 'tags' to comma-separated tag filtering, 'active' to active-status filtering, and 'limit' to result count with the 250 cap. This fully compensates for the schema's lack of 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 uses a specific verb and resource: 'List n8n workflows.' It also names the filtering dimensions (active status, name, tags), making the operation unambiguous and clearly distinct from siblings like get_workflow or list_executions.

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 its use case: retrieving a collection of workflows with optional filters. It does not explicitly name alternatives or exclusion criteria, but the context is clear enough that an agent can select it for listing workflows without confusing it with other operations.

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

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

With no annotations, the description carries the full burden and does state that this is a full replacement of the workflow definition, not a partial patch. It also names the required structural fields. It does not disclose side effects such as overwriting prior settings, impact on running executions, or permission requirements.

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

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

Two concise sentences deliver the main action first and then the critical payload constraint. There is no filler or redundant restatement of the schema.

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

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

The description covers the essential invocation details and the output schema handles return values. What is missing is explicit sibling routing and fuller disclosure of what replacing a workflow entails at runtime, which matters more because no annotations are present.

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 is the only source of parameter meaning. It usefully clarifies that the `workflow` object must contain name, nodes, connections, and settings. `workflow_id` is not elaborated, but its meaning is reasonably clear from 'existing workflow'.

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 'Replace' with the resource 'existing workflow's definition', so the core action is unmistakable. It also lists the required fields for the replacement workflow, which adds precision. It does not explicitly name sibling tools, but the 'existing' wording distinguishes it from create_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 phrase 'existing workflow's definition' implies this tool is for modifying an already-created workflow rather than creating a new one. However, there is no explicit guidance about when to prefer this over create_workflow, get_workflow, or other siblings, and no exclusions are given.

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