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 fails to mention potential side effects, error conditions for invalid input, or return behavior. Examples only hint at syntax but not operational transparency.

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. The purpose is stated in the first sentence, followed by relevant examples in a code block. Every sentence contributes meaning 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 simplicity of the tool and presence of an output schema, the description provides sufficient context for basic usage. However, it could be improved by mentioning that control rules can be viewed with 'get_controls' or deleted with 'delete_control'.

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 moderate value beyond the input schema, which has 0% coverage. Examples illustrate the format of 'control_string', but 'network_id' is only described as 'Session id', which is vague. Overall, partial clarification.

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: 'Add a new simple control rule.' It uses a specific verb ('Add') and resource ('simple control rule'), and it distinguishes itself from sibling tools like 'delete_control' and 'get_controls'.

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 does not provide guidance on when to use this tool versus alternatives. It only gives example control strings, but no context about prerequisites or when to choose 'add_control' over other control-related tools.

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 description must carry full burden. States 'Add' but does not disclose side effects, uniqueness of pattern_id, or that it modifies the currently loaded network. Minimal behavioral context.

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?

Description is short and includes a docstring-style argument list. No unnecessary words. However, the structure could be improved by front-loading the main sentence before the args.

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?

Despite having an output schema, the description omits important context: that the network must be loaded first, that pattern_id must be unique, and that it modifies the in-memory network. Incomplete for a mutation tool.

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%, but description adds basic explanations for each parameter: network_id as 'Session id', pattern_id as 'Unique name', values as 'Multiplier values'. This is adequate but still minimal; could include value range or format.

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 states 'Add a new demand / operational pattern to the network.' Identifies action (add), resource (pattern), and context (network). Distinguishes from siblings like set_pattern (modify) and get_patterns (list).

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. Does not mention prerequisites (e.g., network must be loaded) or conditions for use. Implied usage from description, but no exclusions or alternatives listed.

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 adds transparency by mentioning cloning of the source network and automatic quality type setting. However, it does not discuss reversibility, error conditions, or what happens with the scenario_id if not provided.

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 high-level summary, important behavioral notes, then a clear argument list. Every sentence adds value 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 complexity (8 parameters, many sibling tools, output schema exists), the description covers core functionality but omits details like return value description, scenario_id behavior, and potential restrictions (e.g., node type). It is minimally adequate but could be more 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?

Since schema description coverage is 0%, the description must explain parameters. It provides basic explanations for all 8 parameters, including the source_type enum values. However, details are minimal (e.g., no constraints on time 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 clearly states 'Inject a contaminant at a node for a specified time window and simulate.' It also specifies that a clone is created and quality type set to CHEM, distinguishing it from sibling tools like create_leakage_event or create_demand_perturbation.

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 for contamination scenarios but does not explicitly state when to use this tool versus alternatives. There is no mention of 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?

The description discloses that a clone is created (no modification to original) and that simulation can be optionally run. With no annotations, this provides useful behavioral context, though it omits details like prerequisites or return format.

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, front-loading the purpose and using a clear Args list. Every sentence serves a purpose 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 parameter count and lack of schema descriptions, the description covers the essential inputs and behavior. It does not mention the output schema (though one exists), but for a mutation tool the focus on inputs and side effects is adequate.

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 compensates by explaining all four parameters: network_id, node_demands (with example format), scenario_id (auto-generated if omitted), and run_simulation (default true). This adds significant meaning beyond the bare 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 applies base-demand multipliers to nodes and optionally simulates. It explicitly mentions creating a clone, distinguishing it from sibling tools like create_leakage_event or set_node_base_demand.

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 notes that a clone is created (so no permanent changes) and that simulation is optional. However, it does not explicitly state when to prefer this over related tools or when not to use it, leaving some inference to the agent.

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 so well: it discloses cloning, pipe splitting, midpoint junction addition, and optional simulation run. No behavioral contradictions.

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 succinct (8 lines) with a clear structure: purpose sentence, behavioral notes, then parameter list. Every sentence provides value 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 complexity (cloning, pipe modification) and the existence of an output schema, the description adequately covers the tool's effect and parameter usage. No obvious gaps for 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 input schema has 0% description coverage, but the tool's description includes an Args block that explains each parameter's meaning (e.g., 'Fraction of flow that leaks'), adding significant semantic value beyond the schema titles.

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 simulates a pipe burst by adding a leakage emitter at the pipe midpoint. This specific verb-resource combination distinguishes it from sibling tools like create_contamination_event or create_pressure_change_scenario.

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 that a clone of the source network is created, implying the original is unchanged. This gives context on when to use the tool (for safe simulation) but does not explicitly mention when not to use it or suggest alternatives among siblings.

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 must cover behavioral traits. It notes that a clone is created and the original is unchanged, which is helpful. However, it omits details like what happens when run_simulation is false, error conditions, or persistence of cloned scenarios.

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 extremely concise: two sentences plus a bulleted argument list. The purpose is front-loaded, and every element adds value with no redundant or filler text.

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 (5 parameters, output schema exists), the description covers the core purpose, clone behavior, and parameter meanings. It does not explain return values, but the presence of an output schema makes that less critical. Minor gaps exist regarding optional parameter effects and scenario lifecycle.

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 adds meaningful explanations for all five parameters (e.g., 'Source network id', 'List of pipe ids to close'). This significantly clarifies the parameters beyond the schema's type/title-only definitions, though it could note defaults and optionality.

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 simulates simultaneous pipe and/or pump failures (closure) and creates a cloned scenario, which distinguishes it from sibling tools like create_leakage_event or create_pressure_change_scenario. The verb 'create' and resource 'multi_failure_scenario' are specific and match 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?

The description implies use for simulating multiple pipe or pump failures but does not explicitly state when to use versus alternatives. There is no guidance on prerequisites or when not to use the tool, so it relies on context from sibling names.

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?

Key behavior disclosed: 'A clone of the source network is created; the original is unchanged.' No annotations provided, so description carries burden. However, it lacks details on side effects (e.g., run_simulation duration, unique scenario_id requirements) or error handling.

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?

Extremely concise: two introductory sentences plus a lean bullet list of arguments. Every sentence serves a purpose with no redundancy. Front-loaded with purpose and key cloning behavior.

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?

Covers the essential cloning and parameter semantics, but omits return value description (despite output schema existing) and prerequisites like network existence or valid reservoir IDs. No error condition hints.

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?

Despite 0% schema description coverage, the description compensates well by defining each parameter, including syntax example for reservoir_heads and clarifying run_simulation behavior. The example reduces ambiguity for the nested object.

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?

Description clearly states the tool's verb and resource: 'Study pressure changes by modifying reservoir heads.' This differentiates it from sibling scenario tools that handle demand perturbations, leaks, contamination, etc.

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 versus the many other scenario creation siblings. The description implies usage for pressure studies, but does not state conditions or 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?

The description discloses key behavioral traits: it creates a clone of the source network, leaving the original unchanged. No annotations are provided, so the description carries the burden; it covers the important cloning behavior but does not detail other aspects like permissions or 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 well-structured with a clear purpose sentence, then details on cloning and parameter format. It is slightly lengthy due to the example, but every sentence adds value. The front-loaded purpose is clear.

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 (4 parameters, nested objects, output schema exists), the description adequately covers cloning behavior, schedule format, simulation option, and parameter semantics. The return value is likely described in the output schema, so not needed 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?

With 0% schema description coverage, the description adds significant meaning: it explains the pump_schedule format with an example, clarifies network_id as source id, scenario_id as cloned session id, and defaults for run_simulation. This surpasses the baseline of 3 for high 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 clearly states it applies a time-based pump schedule and simulates, using a specific verb-resource combination. It distinguishes from sibling tools like 'set_pump_speed' or 'create_valve_control_scenario' by focusing on pump scheduling and cloning.

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 for creating pump schedules but does not explicitly state when to use this tool versus alternatives like 'set_pump_speed' or other scenario tools. No exclusions or context for when not to use are 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 discloses the key behavioral trait of cloning (original unchanged) and optional simulation. However, it omits details like clone lifecycle or persistence.

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, with a clear purpose line, a key behavior sentence, and structured Args list. 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 the presence of an output schema, the description sufficiently covers parameters and core behavior. It could mention return value context, but not required.

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?

Despite 0% schema coverage, the description explains each parameter meaningfully, especially valve_settings as a map of valve_id to new_setting, adding value beyond 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 uses a specific verb ('apply') and resource ('valve-setting changes'), clearly stating the action and result ('simulate'). It distinguishes from siblings like set_valve_setting by explicitly mentioning cloning.

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 for experimental changes without affecting the original (clone behavior), but does not explicitly define when-not-to-use or compare with alternatives like set_valve_setting.

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 is the sole source. It identifies the tool as destructive ('Delete') but lacks details on side effects, permissions, reversibility, or whether deletion is irrevocable. The existing output schema partially mitigates missing return info, but behavioral traits remain under-specified.

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

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

Two short sentences right at the start: one for purpose, one for parameter guidance. No fluff, every sentence adds value, making it highly scannable.

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 (not shown but indicated), so return value clarification is less needed. However, for a deletion tool, the description omits success/failure behavior and conflict handling. With low complexity, the minimal info is borderline acceptable but incomplete for robust 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 coverage is 0%, so description must compensate. It adds meaning for 'control_index' (1-based, use get_controls to list) but only labels 'network_id' as 'Session id' – somewhat vague. This provides partial guidance but not full clarity for both 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?

Description clearly states the action ('Delete a simple control by its 1-based index') with a specific verb and resource, and distinguishes from sibling 'add_control' implicitly by being the inverse 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?

Hints at proper usage by referencing 'get_controls' to list controls before deleting, providing valuable context. However, does not explicitly state when not to use this tool or compare with other deletion tools, leaving gaps in guidance.

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

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

No annotations are provided, so the description must carry the full burden. It only states the tool returns controls, but fails to disclose whether the operation is read-only, idempotent, or requires special permissions. The behavioral traits are insufficiently described.

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 very short (two sentences) with no redundancy. It is front-loaded with the main action. However, it could be expanded with more detail 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?

The tool is simple with one parameter and an output schema (not shown). The description is adequate for basic understanding but lacks details on what constitutes a 'simple control', the return format, or any limitations. Given the complexity, it is minimally 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 single parameter 'network_id' is described as 'Session id of the network to inspect', adding context beyond its name. However, with 0% schema description coverage and a minimal description, the added value is modest.

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 'Return' and resource 'simple controls', making the purpose evident. It distinguishes itself from sibling tools like add_control, delete_control, and retrieval tools like get_nodes, but the term 'simple controls' could be more specific.

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 on when to use this tool versus alternatives like get_patterns or get_nodes. There is no mention of context, 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 must fully disclose behavior. However, it only states the return value without mentioning side effects, permissions, error conditions, or dependencies (e.g., that a network must be loaded).

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: one for the tool's purpose and one for the parameter. No unnecessary 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?

An output schema exists, so return values are covered. However, the description lacks prerequisites, error conditions, and integration context with siblings like load_network.

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 adds essential meaning by explaining that network_id is the 'Session id of the network to inspect', going beyond the schema's bare 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 specifies the verb 'Return' and the resource 'all curves (pump head, efficiency, volume, valve) in the network', making it highly specific and distinguishable from sibling tools.

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 implicitly indicates usage by requiring a network_id, but it does not explicitly state when to use this tool versus alternatives or provide any exclusions or prerequisites.

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 description carries full burden. It mentions 'at (or nearest to)' but does not clarify behavior if exact time not present, error cases, or side effects. Lacks details on permissions or impact.

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?

Description is concise with two sentences plus parameter descriptions. Front-loaded with main action. However, the parameter descriptions repeat schema info; could be more efficient but overall well-structured.

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 an output schema exists, return value explanation is not needed. But description lacks context about prerequisites (e.g., network must be loaded before calling) and does not clarify 'nearest to' behavior. Adequate for a simple query tool but not 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 coverage is 0%, so description adds full meaning: 'network_id: Session id of the network' and 'time_s: Simulation time in seconds.' This clarifies the purpose of each parameter beyond the schema's titles.

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?

Description clearly states 'Return link flows at (or nearest to) a specific simulation time.' This is a specific verb (return), resource (link flows), and scope (at a time). It distinguishes itself from siblings like get_pressure_at_time and run_simulation by focusing on flow retrieval.

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 or when not to use this tool over alternatives. The description implies usage for getting flow data at a time point, but lacks context like prerequisites (e.g., network must be loaded) or comparison to similar tools.

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 present, and the description only states that it returns links with attributes. It does not disclose any behavioral traits such as permissions, performance, or side effects. For a simple read operation, minimal transparency is provided.

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 with two sentences and an Args line. It is front-loaded with the main purpose and contains no 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 presence of an output schema, the description adequately explains the tool's purpose and the attributes returned. It could explicitly state that the request is for a specific network_id, but overall it 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 compensate. It provides a brief but clear explanation of the single parameter 'network_id' as 'Session id of the network to inspect,' adding meaning beyond the schema's 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 it returns all links (pipes, pumps, valves) with their attributes. The verb 'Return' and the resource 'links' are specific, and it distinguishes this tool from siblings like get_nodes or get_controls.

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. There are no prerequisites, exclusions, or context for its 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, the description should disclose behavioral traits. The verb 'return' suggests a read-only operation, but it does not explicitly state that the tool does not modify state, nor does it mention performance implications, authorization needs, or error handling. The transparency is adequate for a simple read tool but could be more 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?

The description is extremely concise, consisting of two sentences plus an Arg line. It immediately states the purpose, lists what is included, and explains the single parameter. Every sentence contributes value with no redundancy or tangents.

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 simplicity (one parameter, no annotations) and the presence of an output schema (which reduces the need to describe return values), the description covers the essential aspects: the tool's purpose, the content of the summary, and the parameter meaning. It is complete enough for an agent to use the tool correctly, though it could mention error conditions.

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 one parameter (network_id) with no description, and the input schema coverage is 0%. The description adds that the parameter is a 'session id of the network to inspect', providing necessary context. However, it lacks format details or validation hints, and does not clarify that the ID must correspond to a currently loaded network. This is mediocre but functional.

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 returns a high-level summary of a loaded network, listing specific elements it includes (node/link counts, flow units, etc.). This is distinct from sibling tools like list_networks, get_nodes, or get_links, which provide lists or individual elements, not an overview.

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 does not provide explicit guidance on when to use this tool versus alternatives. It implies the network must be loaded (via the network_id parameter) but does not specify prerequisites, exclusions, or contexts where other tools like get_nodes might be more 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 provided, so the description bears full responsibility. It implies read-only behavior ('Return'), but does not explicitly state safety, permissions, or side effects. It adds tank-specific attribute details but lacks full 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?

Extremely concise: two sentences for purpose and attributes, then a parameter line. Front-loaded with main action, no 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?

Given an output schema exists, the description need not detail return values. It covers what nodes are returned and common attributes, plus the required parameter. Slightly lacking mention of optional attributes or pagination, but adequate for the tool's simplicity.

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 adds a brief explanation for the single parameter: 'network_id: Session id of the network to inspect.' This provides essential context beyond the schema's title and 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?

Description specifies the verb 'Return' and the resource 'nodes (junctions, tanks, reservoirs)' with their attributes. It clearly distinguishes from siblings like get_links (which returns pipe/valve/pump elements) by focusing on node types.

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 vs alternatives such as get_links or get_network_summary. The description only states what the tool does, not the context where it's 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?

With no annotations provided, the description should fully disclose behavioral traits. It correctly implies a read-only operation but does not explicitly state side effects or safety. For a simple getter, this is adequate but not exceptional.

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 extremely concise, with each sentence serving a purpose: one lists the output, one explains the parameter. Front-loaded with key info, no 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?

Given the tool has an output schema (not shown), the description need not explain return values. It lists the returned options and explains the parameter, making it sufficiently complete 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%, but the description adds context for the only parameter (network_id) by calling it a 'session id' for the network to inspect. This compensates for missing schema descriptions, though the added detail is minimal.

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 explicitly states it returns simulation options such as timesteps, units, quality settings, head-loss formula, and demand model. This clearly distinguishes it from sibling tools like get_nodes or get_patterns, which return different entities.

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 versus alternatives is provided. While the purpose is clear, it does not mention when not to use it or suggest alternatives for similar queries.

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 were provided, so the description carries full burden. It states the tool returns patterns but does not disclose read-only nature, permissions, or any behavioral traits beyond the 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?

Extremely concise: two sentences and an Args list. Front-loaded with the core purpose, no wasted words or 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?

The description covers the basic operation and parameter, but omits context like network state requirements, error cases, or what the return format looks like. Given an output schema exists, it's adequate but not fully 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?

With 0% schema description coverage, the description explains network_id as 'Session id of the network to inspect', adding meaning beyond the schema's title. It clarifies the parameter's role, compensating for the schema gap.

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 returns all demand/operational patterns for a network, with a specific verb ('return') and resource ('patterns'). It distinguishes from sibling tools that return other entities like nodes or links.

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 vs alternatives, nor prerequisites like the network being loaded. The description only implies usage by stating what it returns, but lacks explicit context.

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

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

No annotations are provided, so the description carries the burden. It explicitly mentions 'at (or nearest to)', indicating fallback behavior, and the verb 'Return' implies a read-only operation. It does not disclose error cases but adequately covers the main 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 very concise: a single-sentence purpose followed by two bullet-style argument descriptions. No wasted words, and it is front-loaded with the most important 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 the tool has two parameters, an output schema, and no annotations, the description is complete. It explains the purpose and arguments adequately, and the output schema covers 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%, and the description compensates fully by explaining both parameters: network_id is the session id and time_s is simulation time in seconds. This adds meaning beyond the schema's 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 the tool returns node pressures at a specific simulation time, distinguishing it from siblings like get_nodes (general node info) and get_flow_at_time (flows). It uses a specific verb (Return) and resource (node pressures).

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 for obtaining pressure data at a given time but does not explicitly exclude alternatives. However, the context of siblings and the tool name provide clear guidance.

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

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

No annotations provided, but tool is a simple read-only list with no side effects. Description accurately conveys the action without hidden concerns.

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?

Single sentence front-loading the key action, with clarifying parentheses. No superfluous 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?

Given zero parameters and existence of output schema, description sufficiently covers what the tool does. Could mention output type, but not required.

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?

No parameters, so description does not need to add param details. Provides context that files are usable with load_network, which adds value beyond schema.

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

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

States 'list every .inp example file bundled with ePyT' with clear verb and resource. However, sibling 'list_networks' exists and the description does not differentiate, leaving ambiguity.

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?

Implies usage scenario via 'usable with load_network', but no explicit when/when-not or alternatives guidance.

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

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

No annotations provided, and the description does not disclose behavioral traits such as whether it's read-only (assumed) or any side effects. It gives minimal insight beyond the obvious.

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?

Single sentence, front-loaded with the action and resource. No wasted words; every part is essential.

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 no parameters and the presence of an output schema, the description is sufficient for understanding the tool's core function. It covers the scope of 'currently loaded' without needing further details.

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?

There are no parameters, so the input schema covers 100%. The description does not need to add parameter meaning. Baseline of 4 is appropriate.

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

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

The description clearly states the action ('Return') and the resource ('ids of all currently loaded networks'). It differentiates itself from siblings like 'load_network' and 'list_bundled_networks' by specifying 'currently loaded'.

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 versus alternatives. The purpose is implied but lacks context like prerequisites or when not to 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?

No annotations exist, so the description carries the full burden. It discloses that the path can be resolved from bundled networks, and it returns a summary. However, it doesn't mention side effects like overwriting existing sessions or error handling for missing files.

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 with three clear sections: first line purpose, Args, Returns. No unnecessary text, every sentence 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?

Given the tool has 2 parameters and an output schema, the description covers the purpose, parameter format, and return structure completely. It provides all necessary information for an agent to use 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 coverage is 0%, so the description fully explains the parameters: path (absolute/relative/bare filename, searched in bundled networks) and network_id (optional, defaults to file base name). This adds crucial meaning beyond 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 clearly states it loads an EPANET .inp file into a named session, which is a specific verb+resource. It distinguishes from sibling tools like get_nodes or run_simulation, as loading is the initial step.

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 before other operations but does not explicitly state when to use this tool versus alternatives like list_networks or unload_network. No when-not 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 bears full burden. It discloses that the tool runs both simulations and returns combined time-series results, which covers its core behavior. No mention of side effects or prerequisites, but the operation is straightforward.

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 extremely concise: one sentence for purpose, one for parameter. No wasted words, and the structure is clear.

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 simplicity (one required parameter) and the existence of an output schema, the description is mostly complete. It lacks a note that the network must be loaded first, but this is implied by 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 coverage is 0%, so the description must add meaning. The description explains network_id as 'Session id of the network to simulate,' providing necessary context beyond the schema's 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 it runs both hydraulic and water-quality simulations and returns combined time-series results. This distinguishes it from sibling tools run_hydraulic_simulation and run_quality_simulation, which each handle only one aspect.

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 for combined simulation needs, but does not explicitly state when to use this versus the separate simulation tools. However, the purpose is clear enough to infer correct usage.

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 bears full burden. It does not disclose side effects, permissions, or whether the simulation is destructive. It only lists output types, missing critical behavioral context like requiring a loaded network.

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, with a clear opening sentence and a structured Args section. Every sentence adds value, though the Args section could be integrated more naturally.

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 many sibling tools and no output schema shown (though present), the description does not explain when to use this particular simulation type or how it relates to others. It lists output types but lacks context on prerequisites or alternatives.

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 defines 'network_id' as 'Session id of the network', adding context beyond the schema's type and title. However, with 0% schema description coverage, more explicit details (e.g., format, ownership) would be helpful.

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 'Run' and the resource 'hydraulic simulation', and specifies that it returns time-series results. This distinguishes it from siblings like run_quality_simulation, but not from run_full_simulation, which may be synonymous.

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 versus alternatives like run_full_simulation or run_quality_simulation. It also does not mention prerequisites like loading a network, which is suggested by the sibling load_network.

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 must fully convey behavioral traits. It mentions the tool runs a simulation and returns results, but omits any side effects, performance implications, or auth requirements. The scope of 'all hydraulic results' is vague.

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 extremely concise: two sentences plus a one-line args section. The main action is front-loaded, and every word adds value. No unnecessary 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 the presence of an output schema (not shown), return values are covered. The description mentions including hydraulic results and the need to configure quality type, but does not clarify how this tool relates to the sibling 'run_full_simulation' or what distinguishes it from a hydraulic-only simulation. This lack of differentiation reduces completeness.

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 only parameter 'network_id' is described as 'Session id of the network to simulate', which adds meaningful context beyond the schema's title 'Network Id'. With 0% schema coverage, this compensates adequately.

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 it runs a full water-quality simulation and returns time-series results, including node/link quality concentrations plus hydraulic results. It doesn't explicitly differentiate from the sibling 'run_full_simulation', which could cause confusion, but the focus on quality simulation is distinct from 'run_hydraulic_simulation'.

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 a prerequisite: configure quality type with 'set_quality_type' before running. However, it lacks guidance on when to choose this tool over alternatives like 'run_hydraulic_simulation' or 'run_full_simulation', and gives no 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 provided. Description does not disclose error handling (e.g., invalid network_id, existing file), return value, or whether saving modifies the in-memory state. It only states the basic action.

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?

Description is concise with a main sentence and an Args list. Front-loaded with purpose. Minor improvement: could consolidate Args into table or bullet points, but no wasted prose.

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 save operation with 2 required params and no annotations, the description covers basic semantics but lacks return value description (output schema exists but not described), error cases, and behavior on existing files. Adequate but not comprehensive.

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 includes an Args section explaining each parameter: network_id as 'Session id of the network to save' and output_path as 'Destination file path (should end in .inp).' This adds meaning beyond the schema's type/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?

Description clearly states 'Save the current (possibly modified) network to a new .inp file.' The verb 'save', resource 'network', and output format are specific. This distinguishes it from siblings like load_network and unload_network.

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. It implies saving after modifications but doesn't mention prerequisites, scenarios where other tools (like load_network) should be used first, or when not to use it.

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, and the description does not disclose behavioral traits beyond the fact that it 'sets' a value. It omits information about side effects, required permissions, or whether the change is applied immediately or requires a subsequent simulation. The description carries the full burden but fails to provide sufficient transparency.

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 very short (two lines), which is concise but at the expense of necessary detail. It front-loads the purpose but lacks structure for explaining parameters or usage. It is not overly verbose, but its brevity results in significant gaps.

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 is a simple setter with a required session ID, the description is incomplete. It does not mention that the change will affect subsequent simulations, nor does it describe the output schema (though one exists). For a mutation tool with no annotations, more context is needed about when and how the time step takes effect.

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%, meaning the description does not elaborate on parameters beyond repeating their titles. For 'network_id', it adds 'Session id.' which is minimal; for 'timestep_s', it says 'Hydraulic time step in seconds,' which adds some meaning over the schema's type and title. However, with zero coverage, the description should compensate more thoroughly—e.g., specifying valid ranges or units beyond 'seconds'.

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 'Set the hydraulic time step,' which is a specific verb and resource. However, it does not distinguish from sibling tools like set_quality_timestep or set_simulation_duration, which also set time steps for different aspects. The name itself provides differentiation, but the description could explicitly clarify its unique scope.

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 on when to use this tool versus alternatives or what prerequisites exist (e.g., needing a loaded network). The description lacks context on typical workflow placement, such as before running a hydraulic simulation.

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; the description does not disclose side effects, permissions, or constraints beyond stating that it sets demand. The docstring adds parameter descriptions but no behavioral context.

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, using a standard docstring format with bullet-like parameter lists. It is not overly long and front-loads the core action.

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

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

The description covers parameters well but does not mention return values or post-conditions, despite an output schema existing. It also lacks constraints like 'node must be a junction'.

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 detailed explanations for each parameter, such as 'demand: New base demand in the network's flow units', which compensates for the 0% schema description coverage. This adds significant meaning beyond 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 clearly states 'Set the base demand for a junction node', specifying a verb and resource. It is distinct from sibling tools like 'create_demand_perturbation' but does not explicitly differentiate itself.

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

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

No guidance on when to use this tool versus alternatives, nor any prerequisites or conditions are mentioned. The description only explains what the tool does.

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 mentions 'overwrite all multiplier values', implying destructive behavior, but lacks details on side effects, reversibility, or required permissions. The description is minimal.

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 short and front-loaded with the key purpose. However, it uses an 'Args' block which is unnecessary in a JSON context. Every sentence is useful but could be streamlined.

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 no annotations and 0% schema coverage, the description is insufficient. It does not explain return values (output schema exists but is ignored), prerequisites, or error conditions. Compared to sibling tools, this description is too brief.

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%, but the description briefly explains each parameter: network_id is 'session id', pattern_id is 'name of an existing pattern', values is 'new list of multiplier values'. This adds some meaning beyond schema titles, but no constraints or formatting hints.

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 action ('overwrite') and the resource ('multiplier values for a named demand pattern'). It is specific and distinguishes from siblings like add_pattern (create) and get_patterns (read).

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 does not mention prerequisites (e.g., pattern must exist) or contrast with similar tools like add_pattern.

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. It discloses the mutation effect but does not explain what happens on invalid input (e.g., negative diameter) or network state requirements. Basic but sufficient for a simple setter.

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 very concise, using a single sentence for purpose and an Args block for parameters. No unnecessary words; every part 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 simple setter tool, the description covers purpose and parameters adequately. The existence of an output schema excuses explaining return values. Minor omission: no mention of network loading prerequisite, but siblings also lack this.

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%, but the description provides meaningful context for all three parameters: network_id is 'Session id', pipe_id is 'Pipe name/ID', diameter includes units ('mm or inches'). This adds value beyond the 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 clearly states 'Set the diameter of a pipe,' specifying the exact action and resource. It distinguishes from sibling tools that modify other pipe properties like roughness, status, or length.

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 use when changing pipe diameter but provides no explicit guidance on prerequisites (e.g., network must be loaded) or when not to use. No alternatives are mentioned, but the tool is straightforward.

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, and the description only states the function without disclosing behavioral traits like whether it modifies the network in memory, requires a loaded network, or has side effects on simulations.

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 with a clear main sentence and an Args section that efficiently documents parameters. However, it could be slightly more integrated.

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 modifies a network pipe, the description does not explain the implications (e.g., need for subsequent simulation) or how it fits into a workflow. The output schema exists but is not referenced.

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 documentation coverage is 0%, but the description adds meaningful context: network_id as session id, pipe_id as name/ID, and length in network's units. This significantly aids parameter understanding beyond 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 clearly states 'Set the length of a pipe' with a specific verb and resource. It distinguishes from sibling tools like set_pipe_diameter and set_pipe_roughness by focusing on length.

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 does not provide any guidance on when to use this tool versus alternatives, such as other set_pipe_* tools, nor does it mention any prerequisites or scenarios where 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 bears full responsibility. It discloses the parameter meanings (e.g., roughness units) but does not mention side effects, permissions, constraints, or whether changes are reversible. Moderate transparency.

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 succinct, with a one-line purpose and clear argument definitions. It is front-loaded and free of fluff, though it could benefit from slightly more structured formatting.

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 simplicity (3 required params, output schema exists), the description covers purpose and parameter semantics adequately. However, it lacks usage guidelines and behavioral details, leaving some gaps for an agent to decide when to invoke this tool.

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 adds meaningful details: 'network_id: Session id', 'pipe_id: Pipe name/ID', 'roughness: Hazen-Williams C factor (or Darcy-Weisbach roughness height).' This significantly compensates for the missing 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 clearly states 'Set the roughness coefficient of a pipe,' specifying the verb 'Set' and the resource 'roughness coefficient of a pipe.' This distinguishes it from sibling tools like set_pipe_diameter, set_pipe_status, etc.

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 versus alternatives. The description does not mention prerequisites, conditions, or when-not-to-use scenarios. The context is implied by the name but not elaborated.

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 available, and the description does not disclose behavioral traits beyond the basic action. It lacks information about side effects, permissions, or consequences of opening/closing a pipe.

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 very short and front-loaded with 'Open or close a pipe.' The Args section is structured but lacks unnecessary detail, making it efficient.

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 tool with 3 required parameters and no annotations, the description provides the essential purpose and parameter meanings but omits behavioral context. Given the presence of an output schema, return values are not needed, but completeness is average.

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 compensate. It explains each parameter briefly: network_id is 'Session id', pipe_id is 'Pipe name/ID', status has values 'OPEN' or 'CLOSED'. This adds some meaning but does not elaborate on formats 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 tool's purpose: 'Open or close a pipe.' It uses a specific verb and resource, and the sibling tools include set_pump_status and set_valve_status, so the tool is well-distinguished for pipe status 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?

No guidance is provided on when to use this tool versus alternatives, nor are there any prerequisites or contextual cues. The description simply states the action without addressing selection criteria.

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

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

No annotations exist, so the description must disclose behavioral traits. It only says 'set (replace)' implying overwrite, but no details on side effects, permissions, or irreversibility. Minimal behavioral context.

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 relatively concise but includes a redundant bullet list that largely mirrors the schema. Could be more efficient without losing 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?

The tool modifies the network (a mutation) but no output schema details or side effects are mentioned. Given no annotations and high complexity (4 required params), the description lacks completeness for safe usage.

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 adds meaning by explaining each parameter: network_id as 'Session id', pump_id as 'Pump link name/ID', flow_values as 'X-axis (flow) values', head_values as 'Y-axis (head) values'. This clarifies the role of each parameter beyond the schema's titles.

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 action 'Set (replace)' and the specific resource 'head-flow curve of a pump'. It distinguishes from sibling tools like set_pump_speed and set_valve_setting by specifying the curve.

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. No prerequisites, exclusions, or context provided. The description only states the function and lists arguments.

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 description carries full burden. It only describes the action and parameter meanings but omits side effects, idempotency, or whether the network must be loaded. Insufficient 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?

Concise: two sentences and a parameter list. Purpose is front-loaded. No extraneous words, but could be more structured with explicit sections.

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?

Minimal context given the complexity and many sibling tools. Does not mention return values (output schema exists but unused), prerequisites, or error conditions. Incomplete for a safe agent workflow.

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 0%, but description adds meaning: 'network_id: Session id', 'pump_id: Pump link name/ID', 'speed: Speed ratio (1.0 = design speed, 0.5 = half speed)'. This compensates partially, but no details on constraints or allowed ranges.

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 'Set the relative speed setting of a pump' with a specific verb and resource. It distinguishes from siblings like ‘set_pump_status’ and ‘set_pump_head_curve’, though not explicitly. The meaning is clear.

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. It does not mention prerequisites, scenarios, or exclusions. Without context, the agent must infer usage.

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 alone must convey behavior. It fails to disclose important details such as whether the operation is idempotent, if there are side effects (e.g., affecting network simulation), or what happens if the pump is already in the requested state. The description only states the action without behavioral context.

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 extremely concise: one sentence for the action followed by three parameter explanations. It is well-structured and front-loaded, with no superfluous words. Every element contributes to understanding.

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?

Despite having an output schema (not shown), the description does not mention return values or confirmation of the status change. It also lacks context about required prior steps (e.g., load_network) or that this tool is part of a simulation lifecycle. The description is too minimal to be fully 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?

With 0% schema description coverage, the description adds meaningful context to all three parameters: network_id as 'Session id.', pump_id as 'Pump link name/ID.', and status with explicit mappings 'OPEN (running) or CLOSED (stopped).' This goes beyond the schema titles, which are minimal.

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 explicitly states 'Start or stop a pump,' which is a specific verb and resource. It provides the status parameter with values OPEN (running) and CLOSED (stopped), clearly defining the action. This differentiates it from sibling tools like set_pump_speed or set_pump_head_curve, which handle different aspects of pump control.

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 does not provide explicit guidance on when to use this tool versus alternatives. While the name and parameters imply it is for toggling pump operation, there is no mention of prerequisites, such as having the network loaded, or comparisons with other pump-related tools. The usage context is weakly implied but not 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 burden for behavioral disclosure. It does not state side effects, state requirements, or whether the tool is destructive. Only states the basic action.

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 extremely concise with no wasted words. Two lines for args and a one-line purpose. Front-loaded with the key action.

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

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

Given the tool's simplicity and presence of an output schema, the description is adequate but lacks context on when to use (e.g., after setting quality type) or behavioral effects (e.g., impact on simulation).

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 bare schema: clarifies network_id as 'Session id' and timestep_s as 'Quality time step in seconds', providing units and context. Schema coverage was 0%, 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 clearly states the verb 'Set' and the resource 'water-quality simulation time step'. It distinguishes this tool from siblings like set_hydraulic_timestep and set_simulation_duration by specifying 'water-quality'.

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 on when to use this tool versus alternatives, nor are prerequisites or exclusions mentioned. The description provides no context for invocation decisions.

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 behavioral traits. It does not mention side effects, permissions required, or the impact on the network simulation. For a tool that modifies simulation settings, these details are important but missing.

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 extremely concise, using a docstring format that lists parameters with brief explanations. Every sentence serves a purpose, and there is no redundant or extraneous text.

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 (5 parameters, no annotations) and the presence of an output schema, the description covers the basic parameter semantics but lacks overall context. It does not explain the return value (though output schema may handle that), nor does it provide usage context or behavioral implications. It is minimally adequate for a knowledgeable 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 schema coverage is 0%, so the description must compensate. It provides meaningful explanations for all five parameters: network_id as session id, quality_type with enumerated options, tracer_node as source node for TRACE, chemical_name as species name for CHEM, and units as concentration units. This adds significant value beyond the schema titles, though it could specify valid units 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 clearly states the tool's function: 'Set the water-quality analysis type.' The verb 'set' combined with the specific resource 'water-quality analysis type' makes the purpose unambiguous. This distinguishes it from sibling tools like 'set_node_base_demand' or 'set_pattern'.

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 does not provide any guidance on when to use this tool versus alternatives, such as when to choose 'AGE' vs 'TRACE' quality analysis. No prerequisites or context for using the tool are given. This forces the agent to infer usage from parameter names 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 provided, the description must cover behavioral traits. It explains that the tool modifies the reservoir head, but does not disclose side effects, validation rules, authorization requirements, or what happens on failure. It is minimally adequate for a simple setter.

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 extremely concise: one declarative sentence plus a bulleted list of parameters. Every element adds value, and the structure is front-loaded with the primary purpose. No 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?

Given the simplicity of the tool (three required parameters, no nested objects, simple scalar head value) and the existence of an output schema (which covers return values), the description is complete. It explains what the tool does and what each parameter means, sufficient for an agent to use 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 description includes an Args section that explains each parameter beyond the schema types: network_id as 'Session id', reservoir_id as 'Reservoir node name/ID', and head as 'Total head value in the network's pressure-head units'. Since the schema itself has 0% description coverage, this fully compensates and provides clear semantics.

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

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

The description clearly states the tool's purpose: setting the total head (water-surface elevation) of a reservoir. The verb 'Set' combined with the specific resource 'reservoir head' makes the action unambiguous, and it is easily distinguished from sibling setter tools that target different properties (e.g., diameter, roughness).

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, nor does it mention prerequisites or context. It only states the action, leaving the agent to infer usage without any explicit 'when' or 'when-not' instructions.

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 should disclose behavioral traits but only states the action without side effects, ordering constraints, or impact on other settings. It omits whether setting duration before running simulation is required or if it can be changed mid-simulation.

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 with two sentences, front-loading the purpose. However, it sacrifices completeness for brevity, missing contextual 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?

Despite having an output schema, the description lacks context about the tool's role in the simulation lifecycle, prerequisites, or behavioral implications. It feels incomplete for a tool that modifies simulation state.

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 bears the full burden. It adds meaning: network_id as 'Session id' and duration_s as 'Duration in seconds (e.g. 86400 = 24 h)'. This provides unit and example but lacks clarity on what constitutes a valid session id.

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 it sets the total simulation duration, which is clear but essentially restates the function name without adding meaningful differentiation from siblings like 'set_hydraulic_timestep' or 'set_quality_timestep'. It is minimal and not distinguishing.

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 or when not to use this tool. It does not mention prerequisites (e.g., must have a loaded network) or compare with alternatives like 'run_simulation' that implicitly determine duration.

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?

The description discloses that 'Only provided parameters are changed; others retain their current values', which is a key behavioral trait. However, no annotations exist to provide safety or destructiveness hints, and the description omits potential side effects or prerequisites.

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 with a front-loaded purpose and a single behavioral detail. The parameter list is necessary given schema coverage, so it's appropriately structured with no 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?

For a simple update tool, the description explains partial update behavior. However, it lacks mention of prerequisites (e.g., tank existence), validation, or output format. With an output schema present, the omission of return details is acceptable, but other contextual gaps remain.

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 parameter list in the description adds minimal meaning (e.g., 'network_id: Session id.'). While it clarifies each parameter, the explanations are terse and lack constraints or format details.

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 'Update one or more parameters of a tank node', providing a specific verb and resource. However, it does not differentiate from sibling set_* tools beyond the parameter list, which limits distinction.

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

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

No guidance on when to use this tool versus alternatives. While sibling tools are distinct by object type, the description 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 must disclose behavioral traits. It states the tool 'Set the initial setting' implying a mutation, but does not describe side effects (e.g., impact on simulation results), prerequisites (e.g., network must be loaded), or the return value despite an output schema existing.

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 front-loaded with the main purpose. The Args section is somewhat redundant but brief. Overall, it is efficient without unnecessary 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 3-parameter tool with no annotations and 0% schema coverage, the description adequately explains the parameters' meaning, especially the setting value. However, it lacks details about return values and prerequisites (e.g., network ID validity), leaving some 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?

With 0% schema coverage, the description adds significant value by explaining the 'setting' parameter per valve type (pressure setpoint for PRV/PSV/PBV, flow rate for FCV, loss coefficient for TCV). The Args section names parameters but adds minor value beyond schema titles.

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 'Set' and the resource 'valve setting', and it distinguishes from siblings like 'set_valve_status' by specifying that it sets a numeric parameter (pressure setpoint, flow rate, loss coefficient) rather than a status.

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 guidance by mapping valve types to their respective setting units, explaining what the 'setting' parameter means for different valves. However, it does not explicitly state when to avoid using this tool or suggest alternatives, but the context is clear enough.

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?

The description does not disclose side effects, prerequisites, or whether the operation is reversible. With no annotations provided, the description carries full responsibility for behavioral transparency but only states the action without any deeper context.

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 extremely concise, with a front-loaded purpose statement and a succinct parameter list, containing no unnecessary 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?

Despite the simplicity of the tool, the description lacks usage guidelines and behavioral transparency, leaving the agent without sufficient context to use it correctly, especially given the many sibling tools with similar names.

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 brief explanations for each parameter (e.g., network_id as session id, valve_id as link name/ID, status values as 'OPEN' or 'CLOSED'), but with 0% schema coverage, it does not fully compensate by providing additional meaning 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 'Open or close a valve' using a specific verb and resource, effectively distinguishing it from sibling tools like set_valve_setting and set_pipe_status.

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 such as set_valve_setting, nor are prerequisites or context for usage mentioned.

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

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

No annotations are provided, so the description carries the full burden. It only says 'unload and free resources', with no mention of side effects, idempotency, or behavior on invalid network_id. Missing important behavioral details for a cleanup 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 exceptionally concise: two sentences plus a one-line args explanation. It is front-loaded with the main purpose and contains no unnecessary words. Every sentence 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?

Given the tool's simplicity (one parameter) and the existence of an output schema, the description is fairly complete. It covers the purpose and parameter. However, it could add a note about unsaved changes or that unloading is only in memory.

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%, but the description explains that 'network_id' is the session id returned by 'load_network'. This adds meaningful context beyond the schema's type and name, helping the agent know where to get the 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 unloads a previously loaded network and frees resources, using a specific verb 'unload' and resource 'network'. It distinguishes from siblings like 'load_network' (inverse) and 'list_networks' (listing).

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 specifies that the tool is for a previously loaded network and expects the session ID from 'load_network'. This provides clear context, though it does not explicitly state when not to use or list alternatives.

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