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 output nature ('structured, unambiguous specification') and that it flags missing requirements, but says nothing about whether it interacts with the user, whether it mutates state, or what happens when the input is already complete. Partial behavioral disclosure.

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

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

Two tight sentences with the analysis action and its enumerated outputs front-loaded; no filler. Slightly dense enumeration but nothing wasted.

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

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

An output schema exists, so return values need not be described. However, for a tool sitting in a multi-stage optimization pipeline, the description omits its place in the workflow and how its output feeds formulate_math_model, leaving a gap an agent must guess at.

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% for the single string parameter, so the description must compensate. It does clarify the parameter's content ('raw user optimization problem descriptions'), which is useful, but adds no format, length, or example guidance beyond that.

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 (analyzes) and resource (raw user optimization problem descriptions) plus the concrete artifacts it extracts (constraints, sets, parameters, variables, bounds, objectives). It does not, however, explicitly distinguish itself from near-neighbors like review_requirements or decompose_optimization_query, which a reader must infer from the names alone.

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

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

No guidance on when to invoke this versus review_requirements, decompose_optimization_query, or formulate_math_model. The pipeline position (presumably first, on a raw unformalized description) is implied by the wording 'raw user ... descriptions' but never stated as a condition.

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 burden and does disclose the key non-obvious behavior: it recommends tools rather than executing them, and it is explicitly barred from suggesting run_end_to_end_workflow. It does not state that it is side-effect-free/read-only or how detailed the emitted plan is, leaving a small 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?

Three tightly-scoped sentences with no filler; the routing rule and the negative constraint are front-loaded. Slightly dense with the enumerated tool list, but every clause is load-bearing.

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?

Output schema exists, so the recommendation result need not be described. The behavioral routing rules and exclusions are covered; the only real gap is parameter meaning, which is a schema-level omission rather than a description failure.

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?

Two parameters ('query' required, 'context' optional) with 0% schema description coverage, and the description never explains what either accepts or how they differ. An agent cannot tell whether 'context' is prior conversation, domain constraints, or something else.

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 verb 'analyzes' is vague on its own, but the description immediately clarifies the real function: a router that decomposes open-ended problems into a plan of named modular tools or routes specific requests to a single tool. It is distinguishable from the execution/review siblings by its planning-only role.

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?

Explicit branching guidance: high-level/open-ended → break into a step-by-step plan; already specific → recommend only the single required tool. It also names the excluded alternative ('NEVER recommends the overall end-to-end workflow tool'), which is exactly the when-not guidance an agent needs.

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 does add real value by disclosing sandbox isolation and the returned artifacts (metrics, solver logs, stdout, error status). It stops short of stating side-effect boundaries (e.g. what the sandbox can touch) or how the timeout terminates or reports a hang, which matters for a code-execution 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?

A single front-loaded sentence that puts the verb, the resource, and the execution environment first, then the outputs. No filler, nothing to trim.

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 the return-value enumeration in the description is somewhat redundant, and the status of the two inputs plus timeout behavior is left wholly unaddressed. For a sandboxed code-execution tool with zero annotation coverage, that leaves meaningful gaps.

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

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

Schema description coverage is 0% and there are two parameters, yet the description mentions neither `code` nor `timeout_seconds`. The default timeout of 60 seconds and its effect on long-running solver jobs — a genuinely important semantic for this tool — are documented nowhere.

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 (executes), a specific resource (PySCIPOpt optimization code), and the execution environment (isolated sandbox subprocess), which is far more precise than a generic 'run code'. However, it does not differentiate itself from the near-identical sibling execute_pyscipopt_sandbox, so an agent could reasonably confuse the two.

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

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

The description says what the tool does but never says when to reach for it versus the many siblings in this workflow (generate_model_code, review_model_code, execute_pyscipopt_sandbox, run_end_to_end_workflow). No prerequisites, no exclusions, no alternative routing is given.

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

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

With no annotations, the description carries the full behavioral burden. It usefully states that execution happens in an isolated subprocess and lists return fields, but omits sandbox boundaries, timeout behavior, resource limits, permissions, and potential 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?

Two efficient sentences, front-loaded with the core action and followed by return values. The return list is somewhat redundant given the output schema, but still concise.

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 core purpose and output shape for a code-execution tool, and an output schema exists. However, for a sandbox execution tool with no annotations, it lacks important context about timeout handling, sandbox restrictions, and when to choose it over similar sibling tools.

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%. The description implies the 'code' parameter is a Python/PySCIPOpt script, but says nothing about the 'timeout_seconds' parameter, its default, or behavior when exceeded.

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 ('execution') and resource ('Python / PySCIPOpt scripts') with scope ('isolated subprocess'). It is clear what the tool does, though it does not explicitly differentiate itself from the sibling execute_model_code.

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

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

No guidance on when to use this tool versus alternatives such as execute_model_code. It implies use for PySCIPOpt scripts, but provides no conditions, prerequisites, 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. It states the output format (LP/MILP/MINLP) and the expected components (sets, parameters, variables, objective, constraints), which is useful. But it does not describe error behavior, input constraints, whether the output is deterministic, or how feedback is applied. For a generation tool with no annotations, more behavioral detail would be expected.

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, well-structured sentence that front-loads the core action and output, then mentions the optional feedback capability. No wasted words; every clause adds 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?

The tool has a relatively simple interface (2 parameters) and an output schema is present, so the description need not explain return values. It covers the essential purpose and output artifact, and mentions the optional feedback path. However, the lack of any parameter format guidance or workflow context leaves minor gaps for an agent to infer.

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

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

Schema description coverage is 0%, meaning the two parameters (`specification` and `feedback`) receive no explanation in the schema. The description mentions 'problem specification' (implying the `specification` parameter) and 'reviewer feedback' (implying `feedback`), but provides no format, content, or expected structure for either. This is inadequate compensation for a 0% coverage 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 contains a specific verb and resource: 'Develops a rigorous mathematical optimization formulation ... in LP/MILP/MINLP format from a problem specification.' This clearly distinguishes it from siblings such as `generate_model_code` (code generation) and `review_math_model` (review). It states the exact output artifact—a formulation with sets, parameters, variables, objective, and constraints.

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 mentions 'from a problem specification' and 'Optionally incorporates reviewer feedback,' which implies usage after a specification is available and optionally after review. However, it does not explicitly state when to choose this tool over siblings like `decompose_optimization_query` or `generate_model_code`, nor does it clarify prerequisites or order in a workflow. Usage is implied but not fully spelled out.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states that the tool generates code and returns metadata, but does not disclose side effects, permission requirements, rate limits, error behavior, or whether the generated code is executed.

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 and front-loads the core action before listing return metadata. It is efficient, though the second sentence partly restates fields already present in 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?

With an output schema present, the description need not fully explain return values, and it does state the tool's role in the pipeline. However, it leaves the optional feedback parameter unexplained and provides no explicit routing guidance relative to sibling tools.

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 there are two parameters. The description implies that the 'formulation' parameter is an approved mathematical formulation, but it says nothing about the optional 'feedback' parameter or its expected format or effect.

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: translating an approved mathematical formulation into PySCIPOpt Python code. It clearly distinguishes this generation step from sibling tools like formulate_math_model and execute_model_code by focusing on code generation from an already-approved formulation.

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 'approved mathematical formulation' implies a prerequisite and workflow position, but the description does not explicitly say when to use this tool versus alternatives such as formulate_math_model or review_model_code. Usage is only implied rather than clearly stated with 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. It discloses the return contract ('REVIEW_STATUS: PASSED/FAILED' with diagnostic analysis), but says nothing about whether the tool is read-only, whether it is expensive, or whether it can modify the execution state. Partial disclosure for a 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?

Two tight sentences, front-loaded with the verb and assessed dimensions, followed by the return contract. No filler or repetition.

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 the return values need not be re-explained, and the description still summarizes them helpfully. However, with a 0%-documented required parameter and no annotations, the definition leaves the log format and the tool's side-effect profile unspecified.

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

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

Schema description coverage is 0% and the single required parameter 'execution_log' is undocumented in both schema and description. The description does not clarify the expected format of the log (raw stdout, JSON, file path), which is the key ambiguity an agent faces here.

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

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

States a specific verb ('Evaluates') and resource ('solver execution logs, solution optimality, status, and feasibility'), so the agent knows exactly what is assessed. It does not explicitly distinguish itself from the other review siblings (review_requirements, review_math_model, review_model_code), which is the only missing piece.

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

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

No when-to-use guidance is given. The agent can infer it belongs after code execution in the pipeline, but the description never says it should follow execute_model_code or what condition triggers a review, nor does it name any alternative.

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

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

No annotations are provided, so the description carries the full burden; it discloses the audit dimensions and the return status tokens ('REVIEW_STATUS: PASSED'/'FAILED'), which is useful. However, it omits whether the check is read-only, deterministic, what a FAILED result contains, and what input format the formulation must take.

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 sentences, zero filler, with the audit scope front-loaded before the return-value statement. Every clause earns its place.

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

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

An output schema exists, so explaining return values is not strictly required, yet the description already covers the status outcome. The only real gap for a single-string audit tool is the expected input format, which is a minor but noticeable omission.

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

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

Only one parameter ('formulation') with 0% schema description coverage, so the description must compensate. It names the object being audited but gives no expected format (LaTeX, code, structured text) or size constraints, leaving the sole required parameter underspecified.

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

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

Specific verb ('Audits') plus a precise resource ('mathematical optimization formulation') with enumerated check dimensions: index consistency, variable domains, bounds, objective alignment, constraint correctness. This clearly distinguishes it from siblings like review_model_code and review_requirements.

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 never states when to use this tool versus review_requirements, review_model_code, or formulate_math_model, nor any prerequisites or sequencing. The audit dimensions hint at a post-formulation stage, but no explicit guidance or exclusions are given.

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

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

No annotations provided, so the description carries the full burden. It usefully discloses the outcome contract ('REVIEW_STATUS: PASSED' or 'FAILED' with bugs and corrections), which is real behavioral context. However it says nothing about side effects, whether it is read-only, or how it handles malformed/non-PySCIPOpt input.

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

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

Two tight sentences with zero padding, front-loading the action and scope before the return-value contract. Nothing extraneous.

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 explaining return values is optional and the description does it anyway. But with no annotations and 0% parameter documentation, the definition leaves genuine gaps: usage position in the pipeline, the optional formulation input, and side-effect/permission behavior remain unstated.

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% for both parameters, so the description must compensate and largely does not. It hints at the role of 'formulation' by saying code is reviewed 'against the mathematical formulation' but never clarifies that this parameter is optional with an empty default, nor what format it takes. 'code' is also undocumented beyond the tool 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?

States a specific verb (reviews) and resource (PySCIPOpt Python code), and names the two axes of the review: the mathematical formulation and PySCIPOpt API standards. It distinguishes itself implicitly from review_math_model and review_requirements by scoping to code, though it never explicitly differentiates from those siblings.

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

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

No when-to-use guidance, no prerequisites, and no alternatives named. The pipeline context (siblings like generate_model_code, execute_model_code, review_execution_result) implies this runs after code generation, but the description leaves the agent to infer its position in the workflow.

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 output format ('REVIEW_STATUS: PASSED' or 'FAILED' with critique), which is helpful, but does not state whether the operation modifies any state, what permissions are needed, or that it requires a pre-clarified input. The read-only nature is implied by 'Reviews' but not explicit.

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 sentences, front-loaded with the action and criteria, followed by the return format. No redundant or filler text; every sentence 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 values need not be detailed, and the description does cover the return format. However, for a tool with a completely undocumented input parameter (0% schema coverage), the description does little to clarify what the specification should contain or how it should be formatted, leaving a gap.

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

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

Schema description coverage is 0% and the only parameter is undocumented. The description adds the notion that the input must be a 'clarified problem specification', which is minimal semantic guidance, but it does not describe the expected format, structure, or content, leaving the agent to guess.

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 'Reviews' and resource 'a clarified problem specification', and lists the exact criteria: completeness, consistency, feasibility. This distinguishes it from siblings like review_math_model and review_model_code, which target different artifacts.

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 reference to a 'clarified problem specification' implies it should be used after clarification, but the description does not explicitly state when to use it versus siblings like review_math_model, nor does it name alternatives or give conditions. Usage is only inferable from the input artifact.

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 that the run is autonomous with automated feedback loops and enumerates the stages, which is meaningful behavioral context. However it says nothing about failure handling, cost/latency implications beyond the timeout parameter name, or what a partial run yields, so it is only partially 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?

Two sentences, the pipeline enumeration is compact, and the critical usage constraint is front-loaded and visually flagged. Slightly dense parenthetical listing, but nothing wasted.

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

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

An output schema exists, so return values need not be described, and the usage constraint is covered well. But for a heavyweight autonomous multi-step tool with zero annotation coverage and 0% schema description coverage, the absence of any parameter semantics or failure/termination behavior leaves real gaps.

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

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

Schema description coverage is 0%, so the description must compensate, yet it never mentions problem_description, execution_timeout, or max_node_executions. The pipeline narrative implies a problem goes in, but the timeout and node-execution caps — the parameters that govern a potentially long autonomous run — are left entirely unexplained.

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 ('Executes') and resource ('full autonomous multi-agent optimization workflow graph') and enumerates the pipeline stages (Clarification -> Math Modeling -> Code Generation -> Sandbox Execution). It also explicitly contrasts itself with the individual modular siblings, so an agent can distinguish this orchestration tool from the per-stage tools without opening a schema.

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

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

Gives an explicit gating condition ('ONLY ... when the user EXPLICITLY requests full autonomous end-to-end workflow execution') plus the fallback route ('Otherwise, use individual modular tools'). This is exactly the when-to-use / when-not-to-use guidance a routing decision needs.

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