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

With no annotations provided, the description carries the full burden, and it delivers: it discloses that IC-CAP has no direct DPar constructor, that parameters materialize from $dpar declarations, that circuit='model' affects every DUT while circuit='dut' is DUT Test Circuit only, that prior declarations are replaced, and that parameters are verified after writing. This is thorough behavioral disclosure for a mutation tool.

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

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

The description is economically written: core purpose first, then mechanism, then behavior details, then prerequisite and verification. Every sentence adds necessary information and there is no filler or repetition of schema 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 tool with no output schema and no annotations, the description covers the creation mechanism, circuit semantics, overwrite behavior, post-write verification, and the DUT prerequisite. The only minor gap is lack of explicit return-value or error behavior, but since the tool performs side effects and verifies internally, the description is sufficiently complete for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining what 'circuit' actually means semantically ('model' appears in every DUT's parameter set vs 'dut' DUT Test Circuit only) and how parameters come into existence. Param names/values are already well covered by schema examples.

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

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

The description clearly states the verb and resource: 'Create DUT parameters by declaring them in a circuit page.' It also explains the distinctive mechanism ($dpar declarations) and explicitly distinguishes creation from checking by pointing to dpar_exists/dpar_get for verification, so an agent can tell it apart from related siblings like dpar_set or dpar_get.

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 useful context: which circuit page receives declarations, default behavior for 'model', the prerequisite that the DUT must exist, and a pointer to verify with dpar_exists/dpar_get. However, it never explicitly contrasts this tool with alternatives such as dpar_set for modifying existing parameters or says when not to use it; the usage guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It clearly indicates a read-only existence check with no apparent side effects, but it does not state what happens when the parameter is missing or what return value is produced.

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

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

The description is a single focused sentence with no redundant wording. The action and object are front-loaded, making it easy for an agent to parse quickly.

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

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

For a simple tool with one parameter and no output schema, the description is nearly complete. The only minor gap is the lack of an explicit return-value statement, but 'Check if ... exists' strongly implies a boolean result.

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 already provides full coverage for the single param_path parameter, including an example format. The description adds the semantic context that the path refers to a DUT parameter, but does not need to explain much more given the 100% schema 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?

Description uses a specific verb ('Check') and resource ('DUT parameter'), making the tool's purpose unambiguous. It also distinguishes the tool from generic alternatives like object_exist and from parameter-existence checks for other object types such as mpar_exists or instrvar_exists.

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

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

The description implies the tool should be used when verifying whether a DUT parameter exists. However, it does not explicitly mention when not to use it or point to sibling alternatives such as object_exist, mpar_exists, or dpar_get.

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

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

With no annotations, the description carries the behavioral burden. It discloses the core read operation and minvalmax option support, but it does not describe return type, error behavior, or what Min/Max/Opt Min/Opt Max actually do beyond relying on mpar_get.

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

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

Two short sentences with the core purpose front-loaded and no unnecessary detail. Every word earns its place.

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

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

For a simple two-parameter getter, the description is close to adequate, but it assumes knowledge of mpar_get for minvalmax behavior and, with no output schema, does not state the returned value shape or error behavior.

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?

param_path already has a schema example, and minvalmax already has an enum. The description adds only 'same minvalmax options as mpar_get', which is a cross-reference rather than a full explanation of the parameter 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?

States a specific verb and resource: 'Get a DUT parameter value'. It is clearly distinct from dpar_set and dpar_exists, and referencing mpar_get hints at the DUT-vs-model parameter distinction, though it does not explicitly say when to use this over mpar_get.

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 choose dpar_get versus alternatives like dvar_get, dpar_set, or mpar_get. The mpar_get reference only explains minvalmax option compatibility, not tool selection.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only repeats the tool's name. It does not mention side effects, whether the parameter must already exist, persistence, or return value. The single sentence adds no behavioral insight beyond the tool name.

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

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

The description is a single efficient sentence with no fluff. It is concise and front-loaded, though the brevity borders on under-specification rather than purposeful economy.

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?

This is a mutation tool with no annotations, no output schema, and incomplete parameter documentation. The description does not explain the behavior, prerequisites, or return values, making it insufficient for an agent to call correctly in the presence of many similar setter tools.

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

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

Schema description coverage is only 33% (param_path has an example; value and minvalmax have no description). The description 'Set a DUT parameter value' minimally implies that 'value' is the value to set, but it does nothing to clarify the mysterious 'minvalmax' parameter. It fails to compensate for the low schema 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 identifies a specific verb ('Set') and resource ('a DUT parameter value'), making the tool's basic function clear. However, it does not distinguish dpar_set from many similar sibling setters like mpar_set, dvar_set, or svar_set, so it misses the differentiation needed for a 5.

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

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

There is no guidance about when to use this tool versus the many sibling setter tools (mpar_set, dvar_set, svar_set, ivar_set). The description only states what it does, not when it is the appropriate choice, leaving the agent to infer usage from the tool name alone.

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

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

With no annotations, the description carries the transparency burden. It does disclose the central destructive behavior: an existing DUT is replaced only when overwrite=true. However, it does not explain what happens when the DUT already exists and overwrite is false, nor does it mention the pre-overwrite save/checkpoint behavior signaled by allow_without_checkpoint.

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

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

The description is two short sentences with no filler. The first sentence states the tool's purpose, and the second highlights the single most important usage caveat, making it concise and effectively front-loaded.

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 definition is reasonably complete for a creation tool: the required path parameter, overwrite semantics, and the risky allow_without_checkpoint parameter are all documented. Still, with no output schema and no annotations, it leaves unspecified what occurs when the DUT path already exists and overwrite=false, and what exactly the automatic pre-overwrite save entails.

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 already covers 100% of parameters with detailed descriptions, including an example for dut_path and cautionary semantics for overwrite and allow_without_checkpoint. The main description adds little beyond reinforcing that overwrite must be set explicitly to replace, so the baseline score applies.

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 and resource: 'Create a DUT (Device Under Test) object.' This distinguishes it from generic creators like object_create or model_create by naming the specific object type. It does not explicitly differentiate itself from siblings, but the resource is unambiguous.

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

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

The description gives no guidance on when to choose dut_create over sibling tools such as object_create or model_create. The only usage hint is about setting overwrite=true, which is parameter behavior rather than tool-selection context.

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

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

With no annotations, the description carries the behavioral burden. It clearly conveys a read-only enumeration and the inclusion of values, but it does not disclose return format, behavior for invalid dut_path, or ordering. For a simple getter this is adequate but not rich.

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

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

The description is a single efficient sentence that states the core action and result without redundancy. It is front-loaded with the verb and object.

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

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

For a one-parameter getter, this is minimally complete: the action and returned values are stated and the schema fills in the required string parameter. Missing guidance on path semantics and alternative tools, but complexity is low.

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% and the description does not explain dut_path at all. The tool name and description imply it identifies the DUT whose parameters are retrieved, but no format, source, or usage detail is provided, leaving the agent to infer the meaning.

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

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

The description uses a specific verb ('Get') and resource ('all DUT parameters (DPar) with their values'). The word 'all' and the DPar scoping distinguish it from sibling getters like dpar_get (single parameter) and dut_get_dvars (DUT variables).

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 when-to-use or alternative is given. The phrase 'Get all' implies this is the tool for retrieving the full set of DUT parameters rather than a single one via dpar_get, but the guidance is left to inference.

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 of disclosing behavior. It communicates a read-only retrieval of variables with values, which is the core behavior, but it does not mention return format, error behavior, or whether the DUT must already exist.

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

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

The description is a single front-loaded sentence with no filler. It efficiently conveys the action, target, and expected output.

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 getter with one parameter, the description is minimally viable: it states what is retrieved and that values are included. However, with no output schema and no annotations, it leaves the exact return structure and any preconditions unstated.

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

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

Schema description coverage is 0%, and the description does not explain the single 'dut_path' parameter. The parameter name and tool context imply it identifies the DUT, but the description adds no explicit semantic value 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 states a clear verb ('Get') and resource ('all DUT variables (DVar)'), and adds that it returns their values. It is distinguishable from sibling tools like dvar_get (singular) and dut_get_dpars (parameters), though it does not explicitly name those alternatives.

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

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

The description gives no explicit guidance on when to use this tool versus alternatives such as dvar_get or dut_get_dpars. Usage context is only implied by the tool name and the word 'all', with no stated exclusions or conditions.

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 of explaining behavior. 'Get' conveys a read-only listing action, but there is no explicit statement about return format, ordering, or whether only direct children are returned. It is serviceable for a simple getter but not rich.

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

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

One short sentence with no filler, and the action and object are front-loaded. It loses a point because it omits useful parameter/path detail, not because it is wordy.

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 one-parameter read tool, the description gives the core operation but leaves out path format and return-shape details, and there is no output schema to fill that gap. It is adequate for an agent that already understands the domain, but not 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?

Schema description coverage is 0%, so the description must explain the dut_path parameter. It only says 'under a DUT', which identifies the parameter's role but not how the path should be formatted or what a valid DUT path looks like. The only required parameter remains under-specified.

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

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

States a specific verb (Get), resource (Setup names), and scope (under a DUT). This clearly distinguishes it from sibling tools like setup_get_info or setup_create, which operate on individual setups rather than listing their names.

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 intended use is implied: call it when you need the names of Setups under a DUT. However, it does not explicitly mention when not to use it, nor does it point to related alternatives like object_child_names_of_type or setup_get_info.

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 the full burden of behavioral disclosure. It does not say what happens if var_path already exists, whether creation is destructive or reversible, whether permissions are needed, or what response the caller can expect—only that it creates a DVar with common override use.

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 put the core action and an example use case up front with no redundant filler. The trailing "etc." adds slight vagueness but does not undermine readability.

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

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

For a simple two-parameter create tool with complete schema descriptions, the basic call contract is visible. However, with no annotations and no output schema, the description leaves important operational behavior (duplicate path handling, return value, side effects) unspecified, so it is only 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?

Schema description coverage is 100%, so parameter meaning is already fully documented. The description adds the DUT-level override context but no additional syntax, constraints, or relationships between value and var_path 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 names a specific action (Create) and resource (DUT variable/DVar) and adds a practical use case (DUT-level overrides of SIMULATOR). It is distinguishable from related siblings like dvar_set by the verb, though it does not explicitly call out the 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?

"Common uses" indicates when the tool applies, but it offers no explicit guidance on when to choose dvar_create over alternatives such as dvar_set, dut_create, or other resource-specific create tools. Usage context is implied rather than 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 must carry full behavioral disclosure, but it only states that it 'gets' a value. It does not mention error behavior, return format, side effects, or prerequisites. The verb 'get' implies a read-only operation, but substantial behavioral information is 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 a single, front-loaded sentence with no filler. It is concise and easy to parse, though its brevity sacrifices depth needed for behavioral 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?

For a simple getter with one documented parameter, the description is minimally viable. However, with no output schema and no mention of return value format or failure behavior, the agent lacks important details for confidently invoking the 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 100% with var_path described as 'Full path'. The description adds no additional meaning about path syntax, expected format, or value type, so it does not exceed the baseline provided by 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 the operation ('Get') and the specific resource ('DUT variable value'). This distinguishes it from dvar_set and dvar_create, but it does not explicitly contrast it with other getter siblings like svar_get or object_get_val, making the differentiation implicit rather than explicit.

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. With many sibling getters (svar_get, mvar_get, object_get_val), the description offers no selection criteria or exclusions, leaving the agent to infer usage context.

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

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

No annotations are provided, so the description carries the full behavioral burden. It discloses only the value serialization format and does not mention side effects such as overwriting existing values, error behavior, or what the tool returns.

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

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

The description is a single front-loaded sentence with no filler. Every phrase contributes either the core action or a necessary input-format detail.

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

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

For a simple two-parameter setter, the description covers the main action and value encoding, but the absence of annotations and output schema leaves behavioral expectations and usage context under-specified. An agent would need to infer side effects and when this tool is appropriate relative to sibling tools.

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

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

The description adds useful meaning for the value parameter by explaining scalar values must be strings and arrays must be JSON array strings. However, var_path is only described in the schema as 'Full path', and with 50% schema coverage the description does not fully compensate for the missing var_path 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 'Set a DUT variable value' uses a specific verb and resource, clearly indicating this tool modifies an existing DUT variable. It is distinguishable from related get/create tools, though it does not explicitly name a sibling or contrast its 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?

There is no guidance on when to use dvar_set versus alternatives like dvar_create or dvar_get, and no mention of prerequisites or exclusion conditions. The only guidance is about value formatting, which is a parameter detail rather than usage context.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states that dialogs are dismissed by default, which is a side effect, and it explains the rationale (preventing automation blockage). It does not mention timeout behavior or what is done with the read messages, but the key behavior is transparent.

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

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

The description is a single, well-structured sentence that front-loads the action and includes the purpose. Every word earns its place; there is no 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 is adequate for a simple two-parameter tool, but it leaves 'timeout_seconds' undefined and does not specify what the tool returns when reading dialogs. Since there is no output schema and no annotations, these gaps reduce completeness for an agent trying to invoke it correctly in all situations.

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

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

Schema description coverage is 0%, so the description must compensate for parameter meaning. It adds context for 'dismiss' by noting dialogs are dismissed by default, but it says nothing about 'timeout_seconds' or its semantics. The description only partially explains the parameters.

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

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

The description uses a specific verb ('Read') and a specific resource ('Error Message dialogs from the selected IC-CAP process'), and it clearly conveys the dismiss behavior and the automation-unblocking purpose. This distinguishes it from the many sibling tools that deal with objects, sessions, jobs, or measurements.

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

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

The description clearly implies the scenario: use this tool when error dialogs in the selected IC-CAP process may block automation. It does not explicitly name alternatives or when not to use it, but given the tool's unique role among siblings, 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?

With no annotations provided, the description carries the full burden. 'Check... and report' strongly implies a read-only status operation, but the description does not explicitly state non-destructiveness, what happens if no gateway is selected, or what 'feedback capabilities' means. This leaves behavioral ambiguity.

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

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

A single sentence that front-loads the action and delivers the core information without filler. Every word earns its place, and the structure is easy to parse.

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 no-parameter, no-output-schema tool, the description covers the main aspects (busy/session state and feedback capabilities) but omits important context: how a gateway becomes 'selected,' whether an active session is required, and any error/return behavior. This leaves an agent with some uncertainty about invocation prerequisites.

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 zero parameters, so there are no parameter semantics to document. The description's mention of 'selected' refers to a contextual selection state, not a parameter. With 0 params, the baseline is 4, and the description adds no necessary parameter 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 uses a specific verb ('Check') and names a concrete resource ('the selected IC-CAP gateway'), then further specifies what is reported: 'busy/session state plus feedback capabilities.' This makes the tool's function clear, though it does not explicitly differentiate it from related sibling tools like iccap_status_get or iccap_sessions_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 guidance is given about when to use this tool versus alternatives. The description does not mention prerequisites such as requiring a selected gateway, nor does it contrast this health check with the many iccap status/session/job sibling 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 provided, so the description carries the full burden of behavioral disclosure. It does disclose that failure is reported explicitly, but it does not clarify whether the stop is asynchronous, whether it is reversible, what side effects occur, or what a successful result looks like. This is too thin for a mutation-like control 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 a single front-loaded sentence with no filler. It conveys the target action and a notable behavior (explicit failure reporting) in the fewest words possible.

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

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

With no annotations and no output schema, the description should explain more about what happens when the tool is called, including success/failure semantics and any asynchronous behavior. It gives only a minimal action statement and one behavioral note, leaving important operational context absent for an agent invoking a job-control operation.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented job_id parameter. It only implies that the job_id identifies a running job; it never explicitly explains the parameter, its source, or any formatting requirements. This is minimal added meaning beyond the raw schema.

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

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

The description states a clear action ('Request IC-CAP Stop Activity') and a specific resource ('a running job'), so an agent can tell this tool cancels/stops a job. It does not explicitly differentiate from sibling job tools like iccap_job_get or iccap_job_list, but the cancel/stop intent is unambiguous.

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

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

The phrase 'for a running job' gives clear context about when the tool applies, and the tool name paired with the description implies it is the cancellation counterpart to job listing/retrieval. It does not mention when not to use it or name alternative tools, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that the tool returns an error field and 'latest progress', which hints at asynchronous job tracking, but it does not state whether the call is non-mutating, what happens for an unknown job_id, or whether it blocks.

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 one sentence with no filler, starts with the action, and front-loads the purpose. Every word contributes to defining what the tool returns.

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

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

With no annotations and no output schema, the description properly names the return categories but omits details such as how to obtain a valid job_id and the expected shape of the result/error fields. For a one-parameter getter this is adequate 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 description coverage is 0% for the single job_id parameter, and the description does not compensate by explaining what job_id is, how to obtain it, or its expected format. It only ties the parameter to the tool's general subject by saying 'of a managed IC-CAP job', which adds little beyond the schema's property name.

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

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

The description names a specific verb ('Get'), a concrete resource ('managed IC-CAP job'), and the exact data returned (state, result, error, latest progress). This clearly differentiates it from sibling tools like iccap_job_list, iccap_job_logs, and iccap_job_cancel.

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

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

There is no explicit statement about when to use this tool rather than sibling status-related tools. The verb 'Get' implies it is for inspecting an existing job's status, but the description does not mention how to obtain a job_id or that iccap_job_list is the typical source of job IDs.

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

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

With no annotations, the description carries the behavioral disclosure burden. It states the operation is a read-only-style list and specifies sort order ('newest first'), which is useful. However, it does not mention what fields are returned, whether results are paginated, or whether job status is included.

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

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

The description is a single, efficient sentence with no redundant words. The key behavior ('list recent jobs') and ordering ('newest first') are front-loaded and immediately actionable.

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

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

For a simple list operation with one optional parameter and no required inputs, the description plus schema is sufficient for an agent to invoke the tool correctly. The lack of an output schema and any detail about the returned job entries is a minor gap, but it is not critical for the basic listing use case.

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, 'limit', is fully described by the input schema with type, default, minimum, and maximum. The description does not mention the parameter, but 'recent' and 'list' imply that limit controls how many jobs are returned. Schema coverage is 0%, but the single parameter is self-explanatory enough that the gap is minor.

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

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

The description uses a specific verb ('List') and resource ('recent managed IC-CAP jobs') with an explicit ordering ('newest first'). It is clear and unambiguous, but it does not explicitly differentiate itself from sibling tools like iccap_job_get, iccap_job_logs, or iccap_job_cancel beyond the verb '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?

The description implies the tool is for browsing recent jobs, but it gives no explicit guidance about when to use it instead of related job tools. It lacks exclusions or alternative routing, so an agent must infer usage from the tool name and sibling context.

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

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

With no annotations, the description carries the burden of signaling behavior. It clearly indicates a read-only operation, but it does not explain what 'incremental status output' means, how offset affects results, or what the response contains. Some behavioral context is provided, but meaningful gaps remain.

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

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

The description is a single well-formed sentence with no filler. It front-loads the core purpose and avoids 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?

For a tool with no annotations and no schema descriptions, the description is too thin. It does not clarify offset behavior, output structure, usage context, or how it relates to sibling job/status tools. An agent would likely need to infer important calling 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?

Schema description coverage is 0%, so the description must compensate. It adds no meaning for job_id or offset. The word 'incremental' weakly hints at offset semantics, but the description does not explain whether offset is in bytes, lines, entries, or something else.

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

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

The description uses a specific verb 'Read' and a specific resource: 'incremental IC-CAP status output for a managed job.' It is clear enough to distinguish from general tools like iccap_job_get or iccap_status_get, though it does not explicitly name those siblings.

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

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

No guidance is given about when to use this tool versus alternatives like iccap_job_get, iccap_job_list, or iccap_status_get. The description does not state whether this is for polling, debugging, or what conditions make it the right choice.

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

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

With no annotations, the description carries the burden of disclosing behavior, and it does so by explicitly stating that the tool changes which session subsequent calls target in the current MCP process. It does not detail error handling for invalid session IDs, but the core side effect is transparent.

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

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

The description is a single, front-loaded sentence with no wasted words. It names the action, the target resource, and the scope of the effect efficiently.

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 one-parameter selection tool, the description plus schema is sufficient to invoke it correctly: the session_id is required and its source is specified. It does not describe the return value, but for a session-switching operation this is not a critical omission.

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

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

Schema description coverage is 100%, and the schema already documents session_id as the ID returned by iccap_sessions_list. The tool description adds little beyond the schema, so the baseline of 3 applies.

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 ('Select') and names the resource ('IC-CAP session used by subsequent calls in this MCP process'). It clearly distinguishes this tool from iccap_sessions_list (which lists sessions) by emphasizing the stateful selection behavior.

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

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

The description clearly indicates when to use this tool: before subsequent IC-CAP calls that should operate on a chosen session. The schema's reference to iccap_sessions_list implies the prerequisite workflow of listing sessions first, though no explicit exclusions or alternatives 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 carries the burden of behavioral disclosure. It discloses a meaningful behavior (not exposing authentication tokens) but does not mention whether the operation is read-only, what 'live' precisely entails, or any other side effects or requirements.

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

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

The description is a single, front-loaded sentence that immediately states the action and resource. The extra clause about authentication tokens is relevant and non-redundant, earning its place without adding fluff.

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

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

For a zero-parameter list tool, the description is adequate but not complete. It does not describe the shape of the returned list (e.g., session IDs, names, status) or how the results connect with related tools like iccap_session_select. Since there is no output schema, the description could have provided more context.

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

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

The tool has zero parameters, so the empty input schema fully describes the parameter space. Per the baseline for 0 parameters, the description does not need to compensate for missing parameter documentation, and the score reflects that.

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

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

The description uses a specific verb ('List') and resource ('live IC-CAP sessions'), clearly stating the tool's function. The qualifier 'without exposing authentication tokens' adds a differentiating detail that helps distinguish it from other session-related tools like iccap_session_select.

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 such as iccap_session_select or iccap_job_list. There is no mention of scenarios, prerequisites, or exclusions, leaving the agent to infer usage entirely.

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

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

With no annotations, the description carries the safety disclosure burden and it does so by explicitly stating 'without modifying the project.' It also clarifies that the tool both reads text and parses optimizer progress, making its behavior fairly transparent for a simple read-only tool.

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

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

A single sentence front-loads the action and resource, adds the parsing purpose, and states the non-modifying behavior. There is no redundant or filler content.

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

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

For a one-optional-parameter read tool, the description covers purpose and side-effect profile, but there is no output schema and the description does not explicitly state the return shape (raw text vs parsed progress). An agent must infer the response format.

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 already documents max_chars fully ('Maximum trailing status characters to return'), so description-level parameter guidance is unnecessary. The description adds no parameter semantics beyond the schema, matching the baseline for 100% schema 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 uses a specific verb ('Read') and names a concrete resource ('IC-CAP Status window text') plus a parsing goal. It is clear what the tool does, though it does not explicitly position itself against related status/health tools such as iccap_health or iccap_error_dialog_get.

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 read-only phrasing and 'parse optimizer progress' imply the use case of monitoring optimizer output without side effects. However, no explicit when-to-use/when-not-to-use guidance or alternatives 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?

Since no annotations are provided, the description carries the behavioral disclosure burden. It appropriately conveys that this is a convenience wrapper and describes the data scope, but it does not explicitly state read-only behavior, return format, or potential side effects. This is a moderate gap for a getter tool.

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

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

The description is two concise sentences with no redundancy. The primary action is front-loaded, and the convenience equivalence is stated efficiently without wasting 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?

With no annotations, no output schema, and no parameter explanations, the description omits important details needed to call the tool correctly, especially the meaning of 'imag' and the expected return structure. It is adequate for basic orientation but incomplete for confident invocation.

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

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

Schema description coverage is 0%, and the description does not explain either parameter. 'input_path' is partially inferable as the path to an Input, but 'imag' is completely unexplained. The description does not compensate for the lack of schema field 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 the tool retrieves both measured and simulated data from an Input, using a specific verb and resource. It also distinguishes itself by noting the 'msb=B' equivalence and the convenience-method nature, which differentiates it from siblings like input_M or input_get_data.

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

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

The description gives a clear usage context: use this when you need both measured and simulated data, or as a shortcut for get_data(msb='B'). It does not explicitly mention when not to use it or name alternatives such as input_M or input_S, but the intent is reasonably clear.

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

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

No annotations are provided, so the description carries the full burden. It only says 'Create and configure,' without disclosing the overwrite behavior, checkpoint behavior, what happens if the input already exists, or what the call returns. The schema mentions overwrite and allow_without_checkpoint, but the description itself does not surface these behaviors.

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

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

The description is front-loaded with a clear purpose and then uses well-organized bullet lists to explain mode and sweep-type options. The duplicate 'U: Voltage mode' entry is redundant, but overall the structure makes the large parameter space easier to navigate.

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 21-parameter create operation with no annotations and no output schema, the description leaves significant gaps. It does not explain the required input_path semantics, default behavior, return value, or side effects like overwrite/checkpoint. The mode/sweep information is valuable but incomplete for reliable invocation.

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

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

Schema description coverage is only 10%, so the description must compensate. The mode and sweep-type lists do add meaningful grouping for many parameters, such as plus_node/minus_node for V mode and to_node/from_node for I mode. However, the shorthand names do not always match the JSON property names, 'U' duplicates 'V', 'Dec or Oct' has no corresponding schema field, and W/F/T modes lack detailed parameter guidance.

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

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

The description clearly states the action: 'Create and configure an Input object.' This distinguishes it from the many sibling get/set/query tools that operate on existing inputs. However, it could more explicitly position itself against other input-related creation or modification tools, so it stops short of a 5.

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

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

The description provides no guidance on when to use this tool versus alternatives such as input_set_field, input_get_field, or other create tools. An agent must infer from the name that this is for creating new Input objects. No exclusions or alternative-conditions are stated.

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

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

No annotations are provided, so the description carries the full burden. It adds 'as dictionary' and names the two flags, but does not explain what the imaginary flag does, how msb affects the returned data, or what the dictionary keys/values represent.

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?

Both sentences are compact and the main purpose is front-loaded. The second sentence is somewhat vague but still relevant, so no significant redundancy exists.

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

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

With no output schema and no annotations, the description should clarify return structure, flag effects, and the required input_path, but it does not. The tool is usable at a basic level but an agent is left guessing about key behavioral 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?

Schema description coverage is 0%, yet the description only mentions msb and the imaginary flag without explaining their meaning or the required input_path parameter. This adds little beyond the raw schema, which already lists the enum values, defaults, and types.

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 a specific verb ('Get') on a specific resource ('Input dataset') and the return format ('as dictionary'), which helps distinguish it from siblings like input_get_df and input_get_fields. The mention of msb and imaginary flag gives extra specificity, though it does not explicitly name an alternative.

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 phrasing implies this tool is appropriate when a dictionary representation of an input dataset is needed, possibly with msb or imaginary toggles. It does not state when to prefer this over input_get_df, input_get_fields, or other input-read siblings, so guidance is only implied.

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

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

There are no annotations, so the description carries the behavioral burden. It communicates a read-style operation ('Get') and the output form ('DataFrame'), but it does not explain side effects, error behavior, indexing conventions, or what msb and imag do. This is acceptable for a simple getter but leaves meaningful gaps.

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

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

The description is a single compact sentence with the core purpose front-loaded. There is no redundant text, and every phrase contributes meaning.

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 5 parameters, one required but undocumented parameter, no annotations, and no output schema, this description is too thin for an agent to invoke the tool with confidence. Key semantics around input_path, msb, imag, and indexing behavior are missing.

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

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

Schema coverage is only 40%, so the description must compensate for undocumented parameters. It adds meaning only to m/n through 'optional matrix indexing' and loosely to input_path via 'Input dataset'. The required input_path and the msb/imag parameters remain effectively unexplained, which is a significant gap for a 5-parameter tool.

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 ('Get'), the target resource ('Input dataset'), and the return form ('as DataFrame'), so an agent can tell this returns a dataframe rather than raw data. It does not explicitly differentiate from siblings like input_get_data or input_get_field, but the 'as DataFrame' phrase provides some separation.

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

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

The phrase 'as DataFrame with optional matrix indexing' implies when this tool is useful—when a dataframe or matrix-indexed view is needed—but it does not state alternatives or when not to use it. No explicit routing to input_get_data or output_get_df is provided.

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

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

With no annotations, the description carries the burden of indicating behavior. It clearly signals a non-mutating read via 'Get', but it does not disclose return value format, error behavior for missing fields, or any side effects, leaving gaps for a tool with no output schema.

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

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

The description is a single front-loaded sentence with no redundancy. Examples are embedded efficiently and do not add bulk.

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

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

For a tool with no output schema and no annotations, the lack of input_path semantics and return behavior makes the description incomplete. The sibling context clarifies the domain, but the definition itself leaves too much to inference.

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 only 50%, and the description only reinforces field_name examples while leaving input_path entirely unexplained. The description does not compensate for the undocumented required parameter.

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

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

The description states a specific verb ('Get'), a precise resource ('an Input'), and a specific granularity ('a specific field value') with concrete examples. This makes it easy to distinguish from input_get_fields, which implies retrieving multiple fields.

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 phrasing implies use when a single field value is needed from an Input, but it does not explicitly state when to prefer input_get_fields or other alternatives. No when-not-to-use 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?

No annotations are provided, so the description carries the behavioral burden. It does transparently indicate a read-only retrieval of field names rather than values, which is useful. However, it does not mention behavior for invalid paths, return structure, or failure modes.

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

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

The description is a single, direct sentence with no filler. The action and resource are front-loaded, and every word contributes meaning.

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

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

For a simple single-parameter read tool with no output schema, stating that it returns configurable field names for an Input is close to sufficient. Still, the lack of path-format details, return shape, and usage guidance leaves noticeable gaps for an 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 has a bare input_path string with 0% description coverage. The description adds that the operation is 'for an Input', giving some context, but it never explains path syntax, how to obtain the path, or what counts as a valid Input path.

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

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

The description names a specific operation ('Get'), a specific resource ('all configurable field names'), and an object type ('Input'). The qualifier 'all' and the focus on 'field names' help separate it from siblings like input_get_field, though it does not explicitly name alternatives.

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

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

There is no guidance about when to use this tool versus alternatives, no exclusions, and no prerequisites. The agent must infer usage from the sibling tool names and the description's narrow wording.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates a read-only length fetch and defines what is counted, but it does not mention return type, error behavior, or whether input_path must reference an existing Input dataset.

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

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

A single, front-loaded sentence with no filler. Every word contributes to explaining the operation and its result.

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 one-parameter getter with no annotations and no output schema, the description is nearly complete: it states the resource, the measured quantity, and the result. Minor gaps like exact return type and invalid-path behavior are acceptable given the tool's low complexity.

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

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

The schema provides only the parameter name input_path with type string and no description, so schema coverage is 0%. The description partially compensates by implying input_path identifies the Input dataset, but it does not explicitly document the path format or any 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 states a specific verb ('Get'), a clear resource ('the Input dataset'), and the exact result ('the number of data points'). It clearly distinguishes this from sibling tools like input_get_data or input_get_df, which retrieve data rather than its 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 gives no guidance on when to use this tool versus alternatives such as output_get_length, transform_get_length, or setup_get_length. There is no mention of context, prerequisites, or exclusions, so an agent must infer appropriateness from the name alone.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only says 'Get' and describes the returned payload; it does not confirm read-only behavior, return structure, error handling, or side effects. An agent must infer safety and failure semantics entirely from the verb.

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

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

The description is a single, front-loaded sentence with no wasted words. It states the verb and object immediately and avoids repeating the tool name or schema fields. This is appropriately concise for the amount of information it conveys.

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 one-parameter getter, the description is close to sufficient, but the missing input_path semantics and complete lack of usage guidance leave an agent unsure what value to pass. With no output schema or annotations, the description should provide at least a path convention and a note distinguishing this from output_get_modedict.

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 required parameter, input_path, with 0% description coverage, and the description never mentions it. No explanation is given for what input_path should contain, its format, or how it relates to the mode dictionary. The description fails to compensate for the missing schema documentation.

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

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

The description clearly identifies a 'get' operation on a 'mode dictionary' and specifies its content ('available modes and their required fields'), which separates it from generic input_get_* field/data tools. It does not explicitly contrast with output_get_modedict, but the input_get_ prefix and function name largely disambiguate the resource.

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 usage conditions, exclusions, or alternatives are mentioned. With sibling tools like output_get_modedict and many other input_get_* functions, the agent is not told when to choose this tool over the alternatives. The only guidance is implicit in the tool name and terse description.

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 the tool returns a dictionary of sweep types and required fields, and 'get' implies a non-mutating read. However, because no annotations are provided, the description carries the full behavioral burden and does not mention prerequisites, invalid input_path behavior, or error conditions.

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

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

A single, direct sentence with no wasted words. The core action is front-loaded, and the description stays appropriately minimal for a simple getter.

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

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

For a one-parameter getter with no output schema, the description conveys the primary function and return content. However, the required input_path is not explained, and there is no usage or fallback guidance, leaving the definition only minimally viable.

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

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

Schema description coverage is 0%, so the description must compensate for the undocumented input_path parameter. It does not mention input_path at all, leaving the agent to infer that it is a path to an input object from the parameter name alone.

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

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

The description uses a specific verb ('Get') and identifies a clear resource: the sweep type dictionary. It also states what the dictionary contains ('available sweep types and their required fields'), which distinguishes it from sibling dictionary tools like input_get_modedict.

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 such as input_get_modedict or input_get_fields. The description only states what the tool does, not the conditions under which it is the right choice.

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 behavioral transparency burden. 'Get' clearly indicates a read operation, and the possible return values are disclosed, but there is no explicit statement about side effects, error behavior, or assumptions like input_path needing to exist.

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

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

A single sentence with no wasted words. It fronts the action and answer domain immediately, and every component contributes meaning.

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 one-parameter read tool with no output schema, the description is largely sufficient: it names the resource and the exact return set. The main gaps are explicit parameter semantics and error behavior, but the low complexity keeps the impact modest.

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 does not explain the input_path parameter. The parameter name is somewhat self-explanatory and aligns with 'the Input dataset', but the description adds no explicit meaning about what value to pass or how it is used.

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

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

The description states a specific verb ('Get'), a specific resource ('the Input dataset type'), and enumerates the exact possible result values ('M', 'S', 'B'). This makes the purpose immediately clear and distinguishes it from sibling tools like input_get_field or input_get_data.

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

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

No guidance is given about when to call this tool versus alternatives such as input_M, input_S, or input_B. The description implies its use when a type string is needed, but it does not state any exclusions or contextual conditions.

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

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

With no annotations, the description carries the full behavioral burden. It discloses that this is a convenience wrapper equivalent to get_data(msb='M'), which is useful. However, it does not mention side effects, prerequisites, error behavior, or return format, leaving the agent with limited insight beyond the core operation.

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

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

The description is a single, front-loaded sentence with zero filler. It states the action first, then adds the crucial equivalence detail, making it both concise and 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?

For a tool with two parameters, no annotations, and no output schema, the description is too sparse. It does not explain the imag parameter, the return payload structure, or any conditions required to use the tool correctly. The equivalence to get_data(msb='M') helps, but an agent would still need to consult other documentation to use it fully.

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

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

Schema description coverage is 0%, so the description must compensate by explaining parameters, but it does not. It never mentions input_path or imag, and 'from an Input' only weakly hints at input_path's role. The imag boolean parameter remains completely unexplained, so an agent cannot infer its meaning from the description.

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

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

The description opens with a specific verb and object ('Get measured data from an Input'), making the tool's purpose immediately clear. It further distinguishes itself by noting it is a convenience method equivalent to get_data(msb='M'), which separates it from sibling tools like input_S and input_B.

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 equivalence statement gives clear context: use this instead of calling get_data with msb='M'. The phrase 'Get measured data' implies the intended scenario, but there is no explicit mention of when not to use it or comparison with input_S/input_B.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It conveys that this is a read-style convenience method, but it does not describe return format, error behavior, or whether the Input must already exist. This is minimal even for a simple getter.

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 with no filler. The main purpose is front-loaded, and the equivalence note is a compact, useful addition.

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

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

With no annotations, no output schema, and 0% parameter documentation, the description leaves important invocation details unexplained. It works as a terse hint but is not sufficient for an agent to confidently handle the input_path and imag parameters or understand the return value.

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 adds no explanation for input_path or imag. The mention of msb='S' refers to the underlying call but does not clarify the actual parameters. The boolean 'imag' in particular remains ambiguous.

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

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

The description states a specific verb and resource: 'Get simulated data from an Input.' It also names the underlying method equivalence, get_data(msb='S'), which differentiates this tool from sibling helpers like input_M and input_B by the 'simulated' qualifier.

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

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

The description implies when to use the tool: when simulated data is needed from an Input, and it references get_data(msb='S') as the equivalent general call. However, it does not explicitly contrast with input_M/input_B or state when not to use this tool.

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 burden of behavioral disclosure. It usefully reveals a non-obvious conversion behavior: string keys like '("M", "11")' are converted to tuple keys for IC-CAP. However, it does not explain the meaning of the 'force' parameter, whether existing data is overwritten, or what happens on failure.

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

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

The description is compact and front-loaded with the core action. The key-conversion note and the data format example each add necessary operational detail without unnecessary verbosity.

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 absence of annotations, output schema, and parameter documentation, the description still leaves important gaps. It fully explains the data payload structure but not the target path semantics or the 'force' flag, so an agent may still be uncertain about edge behavior. The core call is likely usable, but not completely specified.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for the 'data' parameter by specifying the expected dictionary shape and key conversion behavior. It does not explain 'input_path' or 'force', leaving those parameters to be inferred from names and defaults.

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

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

The description states a clear verb and resource: 'Set Input data from a dictionary.' It also distinguishes itself from sibling field-level tools like input_set_field by emphasizing bulk dictionary-based data assignment. However, it does not explicitly name or contrast itself with those siblings.

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

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

The usage context is implied: use this tool when you need to assign an entire Input data structure from a Python dictionary. It provides a concrete data format example, which helps correct invocation, but it does not state when to prefer this over alternatives such as input_set_field or input_get_data.

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?

There are no annotations, so the description carries the full burden of behavioral disclosure. It implies mutation but does not state whether the field must already exist, whether existing values are overwritten, or what side effects may occur on the Input.

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

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

The description is concise and front-loaded, but it is under-specified rather than efficiently complete. It is a single clear sentence, yet it omits material behavioral and parameter context that the operation requires.

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 mutation tool with no annotations and no output schema, this description is too thin. It does not explain expected inputs, error conditions, return behavior, or how this set operation relates to the Input 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%, and all three parameters are bare strings with no enumerated values or format hints. The description adds no meaning to input_path, field_name, or value, leaving the agent without essential parameter 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 verb-resource pair: setting a specific field value on an Input. It is distinguishable from sibling tools like input_get_field (read) and input_set_data (bulk data), though it does not explicitly name them.

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

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

No guidance is given on when to use this tool versus alternatives such as input_set_data, input_get_field, or object_set_val. The agent must infer usage entirely from the tool name and description.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. 'Check if...exists' implies a boolean result and a read-only operation, but it does not state the return type, behavior when the field is missing, handling of invalid paths, or whether any errors are raised.

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

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

The description is a single concise sentence with no filler. It front-loads the core purpose, though the phrase 'instrument option field' is slightly vague and could have been clearer.

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 there is no output schema, no annotations, and no parameter documentation, the description is too thin for an agent to confidently call this tool. The agent is left without knowledge of the return format or the meaning of input_output_path, making the tool incomplete in context.

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

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

Schema description coverage is 0%, and the description provides no explanation of the two required parameters, input_output_path and field_name. While 'instrument option field' hints at field_name, input_output_path is completely unexplained, leaving the agent to guess what path structure is expected.

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

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

The description states a clear verb ('Check') and resource ('instrument option field'), so an agent knows this is an existence-check tool. It is not tautological and is distinct enough in intent from instrvar_get and instrvar_set, though it does not explicitly name those alternatives.

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

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

No guidance is given about when to use this tool versus the many related existence-check tools such as object_exist, mpar_exists, dpar_exists, or tablevar_exists. The description does not explain whether this should be called before instrvar_get/instrvar_set or what conditions warrant 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?

With no annotations, the description carries the behavioral burden. The verb 'Get' implies a read-only operation, and the path construction mechanism is disclosed. However, it does not describe return value format, error behavior when the path/field is invalid, or any side effects.

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

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

Two sentences with no filler. The core action is front-loaded, and the path construction detail earns its place as the only non-obvious information an agent needs.

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 getter with two fully documented parameters and no output schema, the description conveys the action, the return concept ('value'), and how the parameters combine. The absence of a defined return type or error semantics is a minor gap for such a straightforward read operation.

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

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

Schema coverage is 100%, so both parameters are already documented. The description adds value beyond the schema by explaining the relationship between the two parameters ('Path is constructed as input_output_path/field_name'), clarifying how field_name composes with the path rather than standing alone.

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

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

The description uses a specific verb and resource ('Get an instrument option field value') and adds the path construction rule, which makes the tool's function concrete. It does not explicitly differentiate from similarly named siblings like ivar_get, but the 'instrument option' phrasing and path detail provide enough 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 is given about when to use this tool versus alternatives such as instrvar_set or instrvar_exists. The description states only what the tool does, leaving the agent to infer the complementary relationship with its write/existence-check 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?

With no annotations, the description must disclose behavioral traits itself. 'Set' conveys mutation, and the description names the target field, but it does not reveal whether the operation overwrites, creates missing fields, requires an existing instrument, or has side effects on other option fields. This is a significant transparency gap for a mutation tool.

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

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

The description is very short and free of fluff, with the action placed first. However, it is under-specified rather than efficiently complete, and the single sentence does not carry enough information to be genuinely useful.

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 three mandatory parameters, zero schema descriptions, no annotations, no output schema, and a large set of sibling tools, this description is far too thin. An agent cannot determine what input_output_path refers to, what values are acceptable, or what the operation does beyond 'set', making correct invocation unlikely.

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 adds no meaning to the three required parameters. 'field_name' and 'value' are vaguely inferable from the description, but 'input_output_path' is completely unexplained. The description does nothing to compensate for the unhelpful 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 states a clear action ('Set') and a resource ('instrument option field value'), so it is not a tautology. However, it does not explain what an instrument option field is or how it differs from instrument variables, and the many sibling setters (ivar_set, dvar_set, input_set_field, output_set_field) make the scope ambiguous.

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

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

There is no guidance about when to use instrvar_set versus alternatives, no prerequisites, and no mention of when this tool is preferred over sibling tools like instrvar_get, ivar_set, or input_set_field. The description simply states the action with no context.

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

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

With no annotations available, the description carries the full burden of behavioral disclosure. It clearly states the core behavior and location, but it does not mention side effects such as whether an existing variable is overwritten, whether creation fails if a variable already exists, or any required parent context beyond 'Main level'. The naming constraint adds useful behavior beyond the tool name.

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

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

The description is a single, focused sentence with no redundant words. The primary action and scope are front-loaded, and the naming warning is placed where it directly supports correct invocation.

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

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

For a simple two-parameter create tool with no output schema, the description covers the essential information: what is created, where it is created, and how parameters should be named. A small gap is the lack of any statement about collision behavior or return value, but the tool is simple enough that the description is nearly 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 100%, so the baseline is 3. The description repeats the var_name restriction already present in the schema, such as 'variable name only (no path prefix)', but adds no new parameter-level meaning. It does not explain value handling or default behavior beyond what the schema already provides.

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

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

The description clearly states a specific action, 'Create a system variable (IVar)', and the target scope, 'at Main level', which distinguishes it from sibling create tools like svar_create or dvar_create. It also clarifies the naming restriction, leaving no ambiguity about what resource is being acted on.

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

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

The description implies usage context by specifying that this creates a Main-level IVar, but it does not explicitly contrast this with alternatives such as svar_create or dvar_create. It gives enough context for an agent to infer the intended use, but it does not provide explicit when-to-use or when-not-to-use 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?

The word 'get' and the mention of returning a 'value' signal a non-mutating read operation, which is the primary behavioral trait an agent needs. However, with no annotations and no output schema, the description does not disclose behavior for missing variables, error conditions, or the exact representation of the returned value.

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

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

The description is a single, front-loaded sentence with no filler. Every word contributes to the action, resource, and scope, making it easy to parse quickly.

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

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

For a one-parameter getter, the description covers the core purpose and scope sufficiently. But the lack of annotations, output schema, and any sibling-routing context leaves minor but real gaps around edge-case behavior and how this tool relates to the numerous other getter 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 100%, so the baseline is 3. The description adds contextual meaning beyond the bare 'Variable name' schema entry by clarifying that var_name must identify a system variable (IVar) at Main level, which helps the agent select an appropriate input.

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

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

The description clearly states a get operation on a specific resource type (system variable/IVar) and identifies the location (Main level). It does not explicitly distinguish IVar from the many sibling variable getters like svar_get or mvar_get, but the 'system variable (IVar)' terminology provides enough specificity.

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

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

No guidance is given about when to use this tool instead of alternative sibling getters such as svar_get, mvar_get, dvar_get, or instrvar_get. The 'at Main level' scope implies a condition, but there is no explicit when-to-use or when-not-to-use 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?

With no annotations provided, the description carries the behavioral disclosure burden. It usefully explains that scalar values are passed as strings and arrays as JSON array strings, which is important encoding behavior. However, it does not mention whether the operation overwrites existing values, requires the variable to already exist, or what side effects or return behavior to expect beyond the set 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 two sentences with no filler. It front-loads the core purpose and immediately provides the most important parameter formatting guidance. Every sentence earns its place.

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

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

For a two-parameter setter with no output schema, the description covers the operation, target level, and value encoding. The only notable gap is the absence of any statement about whether the variable must already exist or whether it is created on demand, but overall the description is sufficiently complete for correct invocation.

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

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

Schema coverage is only 50%, with var_name documented but value lacking any schema description. The description compensates for value by specifying the expected string encoding for scalars and JSON array strings for arrays. This adds meaning beyond the raw schema and helps the agent construct valid 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 identifies the operation as setting a system variable (IVar) at Main level. This distinguishes it from sibling setters like dvar_set, svar_set, and mvar_set, and the explicit 'at Main level' scoping removes ambiguity about where the variable is set.

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

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

The description provides clear contextual guidance by specifying that this sets an IVar at Main level, which helps an agent select it over other variable setters. It does not explicitly name alternatives or exclusion conditions, but the 'Main level' qualifier gives a clear usage context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Create a Macro object' and mentions optional text; it does not disclose overwrite behavior, checkpoint implications, default macro_type, or what happens when a macro already exists. These are important for a potentially destructive create operation.

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

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

The description is a single, direct sentence with no filler or redundant explanation. It is front-loaded with the core action, though it is arguably too terse given the tool's five parameters and safety-related options.

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

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

For a tool with no annotations, no output schema, and five parameters including overwrite and allow_without_checkpoint, this description is incomplete. It omits critical context about macro_path format, default macro type, overwrite safety, and checkpoint behavior. The agent must rely heavily on the schema and outside knowledge to invoke it correctly.

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

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

Schema description coverage is 80%, so the baseline is 3. The description adds minimal value beyond the schema by restating 'text content', but it does not explain the required macro_path parameter, which is the one parameter lacking a schema description. Overall, the schema carries most of the parameter 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 states a specific verb ('Create') and resource ('Macro object'), and mentions the optional text content. It distinguishes this creation tool from siblings like macro_get_text and macro_set_text, though it does not call out object_create as the generic alternative or mention the required macro_path.

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 for when to use this tool versus alternatives such as object_create, macro_set_text, or model_get_macros. The description simply states what it does, leaving the agent to infer when creation is appropriate and what preconditions or path requirements apply.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Execute/Run a Macro' and vaguely mentions a managed observable job for async mode, without stating whether execution is synchronous by default, what side effects occur, what it returns, or how errors are surfaced.

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 core action. Minor redundancy between 'Execute' and 'Run' costs a small amount of precision, but the overall structure is 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 side-effecting execution tool with no output schema and no annotations, this description is under-specified. An agent cannot tell what a successful execution returns, whether it blocks, what 'managed observable job' means, or what failure modes exist.

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. run_async gets a loose semantic via 'managed observable job,' but macro_path is left entirely to inference from its name, and the meaning of 'managed observable job' is not clarified.

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

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

States a specific action, 'Execute/Run a Macro', on a clear resource. It is readily distinguishable from sibling macro tools (macro_create, macro_get_text, macro_set_text) whose operations are creation and text editing, not execution.

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

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

Provides only a parameter-level tip, 'Use run_async=true for a managed observable job,' with no guidance on when to choose macro_execute over other tools or when to avoid it. There is no discussion of alternatives, prerequisites, or 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 present, so the description carries the full disclosure burden. The verb 'Get' suggests a read-only operation, but the description does not state behavior on missing macros, whether the return value is a string, or whether any side effects occur. This is a minimal 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?

The description is concise and front-loaded, but it is too sparse to be considered well-structured. Every word earns its place, yet the single sentence provides no additional context that would help an agent use the tool correctly.

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 getter with one parameter and no output schema, the description should at least clarify the path format and the return value. The absence of any behavioral or path context leaves the tool inadequately specified, though the core action is not misleading.

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, macro_path, has 0% schema description coverage and the tool description does not explain its format, accepted path syntax, or whether it is relative to a model/project. An agent has no way to know how to construct a valid macro_path 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 states a specific action ('Get') and resource ('text content of a Macro'), so an agent knows what the tool returns. It does not explicitly differentiate from sibling getters like object_get_val or macro_set_text, but the pairing with macro_set_text makes the purpose reasonably 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?

There is no guidance about when to use this tool instead of alternatives, such as macro_execute or macro_set_text. The intended use is implied at best: retrieving macro text before editing or inspection. No exclusions or contextual triggers 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 provided, the description carries the full burden of behavioral disclosure, but it only states the mutating operation. It does not mention that existing text is overwritten, whether the macro must exist, or any error or permission behavior, which is important for a write-type tool.

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

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

The description is one short sentence with no wasted words and front-loads the core action. It is efficient, though its brevity contributes to the under-specification reflected in other dimensions.

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 mutating tool with no annotations and no output schema, the description is too thin to fully support correct invocation. An agent cannot confidently know whether the macro must already exist, what macro_type values mean, or how this operation relates to macro_get_text and macro_create.

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, but it adds minimal parameter meaning. It loosely maps 'text content' to the text parameter and 'Macro' to macro_path, while leaving macro_type and its enum semantics completely unexplained.

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

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

The description clearly states a specific verb ('Set') and resource ('text content of a Macro'), so an agent can immediately understand the core operation. It is distinguishable from siblings like macro_get_text and macro_execute at the verb level, though it does not explicitly name or contrast those alternatives.

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

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

No guidance is given about when to use this tool versus macro_create, macro_execute, or macro_get_text. The description also fails to state whether the macro must already exist or how macro_type affects which macro is targeted, leaving key selection and prerequisite decisions to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the action and the optional type filter; it does not mention what happens if the child is not found, whether it returns a single object or list, or any error behavior. This is a thin description for a tool with zero annotation support.

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

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

The description is two short sentences with no filler. The core purpose is front-loaded, and the optional filter is stated in the second sentence. Every word earns its place.

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

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

Given the low complexity (2 params, no nested objects) and complete schema descriptions, the description is nearly sufficient for an agent to invoke the tool correctly. It could be improved by stating the return value or failure behavior, but for a straightforward getter this is not a critical gap.

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

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

Schema description coverage is 100%, so the schema already documents both child_name and child_type. The description adds marginal context by mapping 'by name' to child_name and naming the allowed type values, but it does not add format, syntax, or edge-case details 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 a specific action ('Get a child object from Main by name') and a resource (Main), with an optional filter by type. It is distinguishable from general object_get_child via the 'from Main' qualifier, but it does not explicitly name sibling tools for comparison.

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

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

The description implies when to use this tool: when you need a child object from Main by name and optionally filtered by type. However, it provides no explicit guidance on when not to use it or which alternative tool (e.g., main_get_models, main_get_ivars) to prefer, leaving some room for inference.

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 burden of disclosing behavior. It clearly indicates a read-only listing operation and the output content, but it does not add details about ordering, return structure, or potential errors. This is adequate for a simple list tool but 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?

A single sentence that front-loads the action and resource, with no filler or repetition. Every word earns its place.

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

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

For a parameterless list tool with no output schema, this description is nearly complete: it states the scope ('all') and the output fields ('names and values'). It is slightly thin on return format or ordering details, but nothing essential is missing for invoking 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 tool has zero parameters, so the baseline is 4. The description does not need to explain parameter semantics and no parameter information is missing.

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

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

The description uses a specific verb ('List') with a clear resource ('all system variables (IVar)') and states the returned fields ('names and values'). This distinguishes it from sibling tools like ivar_get, which targets a single variable, and main_get_models, which targets models.

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

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

The phrase 'List all' implies this is the enumeration tool for system variables, but the description does not explicitly state when to prefer it over ivar_get or other variable-access tools. There is no exclusion guidance or mention of alternatives.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. 'List' clearly implies a read-only operation and 'Model names' indicates the returned data shape. It could mention additional details like empty results or ordering, but for a simple session enumeration the behavior is adequately disclosed.

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

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

The description is a single, front-loaded sentence that states exactly what the tool does with no filler. Every word contributes to the agent's 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?

For a no-parameter, no-output-schema list operation, the description is complete: it identifies the resource (Model names), the scope (current IC-CAP session), and the result type (names). No essential behavioral or context information is missing.

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

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

The input schema declares zero properties and the description adds no parameter details because none are needed. Per the rubric, a zero-parameter tool receives a baseline score of 4 since there is no parameter semantics burden to fulfill.

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

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

The description uses a specific verb ('List') and a clear resource ('all Model names') with an explicit scope ('current IC-CAP session'). It is easy to distinguish from sibling tools like model_get_duts or main_get_ivars, which target different object 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?

The description gives clear context by scoping the tool to the current IC-CAP session, which tells an agent when this listing is relevant. It does not explicitly name alternatives or exclusions, but for a zero-parameter enumeration tool the implied usage 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?

It discloses a useful behavioral trait: the hierarchy search order. However, with no annotations, the description carries the full burden and does not state return format, failure behavior when the name is not found, or explicitly confirm the operation is read-only (though 'get' implies it).

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

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

A single sentence with the action and resource front-loaded, followed by a compact parenthetical that adds the search-order detail. No redundant wording.

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 one-parameter getter, the description covers the main purpose and scope well. However, since there is no output schema, the description should more explicitly convey return behavior and what happens when the name is not visible; these 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?

Schema coverage is 100%, so the baseline is 3. The description adds context that the name parameter refers to a Main-visible variable or parameter, but it does not add syntax details like name formatting or path handling beyond what the schema already provides.

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

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

The description states a specific verb ('Get'), a concrete resource ('variable or parameter value'), and a clear scope ('visible from Main'), plus the search hierarchy. This clearly distinguishes it from object-scoped getters like object_get_valof.

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

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

It provides clear context for when to use the tool: when retrieving a value by name from Main across variables, parameters, tablevars, or datasets. It does not explicitly name alternatives or exclusion conditions, but the Main-scoped framing is a sufficient selection signal.

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

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

With no annotations, the description carries the behavioral burden. It discloses path resolution rules, the workspace policy, automatic .mdl extension, and filesystem verification with file_exists/file_size. It could also mention overwrite behavior, but the provided behavior is substantive.

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

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

The description is compact and front-loaded with the core purpose. Every sentence adds needed detail: Save As semantics, path policy, extension handling, verification, and locator usage. There is no filler.

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

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

For a mutating save tool with no annotations and no output schema, the description covers the critical operational details: destination resolution, policy constraint, extension appending, and success verification. Minor gaps remain around overwrite behavior and exact response shape, but the description is largely complete.

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

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

Schema coverage is 67% and the action parameter is not described in the schema. The description compensates by clarifying that Save takes no arg, that arg is only for Save As, and by adding .mdl handling and path policy meaning beyond the schema text.

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

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

The description opens with a specific verb and resource: 'Save an IC-CAP object to disk.' It clearly separates Save As from Save, and the sibling list contains no other save-equivalent tool, so this is unambiguous.

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

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

The description explains destination handling for Save As, notes that Save takes no arg, and instructs when to use locator='/' versus a model path. It does not explicitly name alternative tools or when-not conditions, but the context is clear.

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

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

With no annotations provided, the description carries the full behavioral burden. It clearly discloses the destructive overwrite behavior and requires explicit opt-in ('overwrite=true explicitly'), which is important safety-relevant context. It does not mention other potential side effects like automatic parent creation or failure modes, but the overwrite disclosure is strong for a create 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 two sentences with no filler. The primary action is front-loaded, and the second sentence adds the critical overwrite safety instruction. Every clause earns its place.

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

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

For a create operation with no output schema and no annotations, the description adequately covers purpose, container semantics, and the overwrite caveat. Combined with fully documented parameters, everything needed to invoke the tool correctly is present. It could mention success/error return behavior, but that is not essential for correct invocation.

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

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

Schema description coverage is 100%, so all four parameters (circuit, overwrite, model_path, allow_without_checkpoint) are already documented in the input schema. The description adds context about the Model's role but adds no parameter-level meaning beyond the schema, so the baseline score of 3 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 states a specific verb ('Create'), a specific resource ('Model object'), and explains what a Model is ('top-level container with circuit netlist, DUTs, parameters, and variables'). This distinguishes it from sibling creation tools like dut_create or setup_create, so an agent can identify the right object type to create.

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

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

The description gives a key invocation condition ('Set overwrite=true explicitly to replace an existing Model') but does not provide explicit when-to-use guidance or name alternatives. The context signal of many sibling create tools makes this gap noticeable; the agent must infer when model_create is preferred over object_create or other creation flows.

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

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

With no annotations, the description carries the full burden. It explains what data is included and mentions the workspace path policy for file_path. However, it does not disclose side effects such as file overwriting, whether the JSON file is created atomically, potential size/performance implications, or what the call returns on success/failure. The provided context is meaningful but incomplete for a mutating export 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 dense but well-organized, front-loading the main action and then using a colon-separated list to enumerate contents. The closing sentence on file_path policy is relevant and not redundant. It is longer than typical, but the complexity of the exported structure justifies the detail.

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

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

For a complex export tool with no output schema, the description covers the input model_path and file_path, the detailed structure of the output JSON, and the policy constraint on file_path. It does not state the return value or error behavior, but the extensive enumeration of contents largely compensates. An agent can call this tool with reasonable confidence.

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 100%, with both parameters described in the input schema. The description adds a pointer to the workspace path policy and gives a model_path example, but these are minor additions. Baseline 3 is appropriate since the schema already documents the parameters 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 opens with a specific verb and resource: 'Export a model's full structure to one JSON file in a single call,' then enumerates the contained data in detail. It clearly differentiates from siblings like tablevar_get and the many object_get_* tools by positioning itself as a bulk replacement.

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

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

It explicitly states the use case: 'for knowledge capture and build verification,' and names the alternative pattern it replaces ('thousands of per-field tablevar_get calls'). It does not list exclusions or when not to use it, but the context is clear enough for an agent to select it for bulk export scenarios.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states the getter action and the resource, with no mention of read-only guarantees, return type, error conditions, or any side effects. The word 'Get' hints at non-mutating behavior, but that is not explicitly stated.

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

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

The description is a single concise sentence with no redundant wording. The key action and resource are front-loaded, making it easy to parse quickly.

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

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

For a single-parameter getter with no output schema and no annotations, this description is minimally viable: it tells the agent what the tool returns (the netlist) and what it acts on (the model). However, it lacks details about model_path format and the exact return value structure, leaving some room for guessing.

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 does not elaborate on the only parameter, model_path. It does not explain whether model_path is a file path, object path, or how it identifies the model. The parameter name provides the only clue, and the description fails to compensate for the schema's lack of documentation.

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

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

The description uses the specific verb 'Get' and names the exact resource, 'the Model's SPICE circuit netlist.' This clearly distinguishes it from sibling tools like model_set_circuit and model_get_mvars, which operate on different resources or perform writes.

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 intended use is implied by the tool name and description, but there is no explicit guidance about when to choose this tool over alternatives, no prerequisites, and no mention of when not to use it. An agent must infer that this is simply the getter for the circuit netlist.

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 for behavioral disclosure. It only says 'Get', implying a read operation, but does not disclose return format, ordering, error behavior, or any side effects. This is a meaningful gap for an unannotated tool.

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

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

The description is a single, front-loaded sentence with no filler. Every word adds meaning, and it is as concise as possible while conveying the operation and scope.

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 retrieval tool with one parameter, the core operation is conveyed. However, with no output schema and no annotations, the description leaves return structure, path semantics, and failure behavior unspecified. It is minimally viable 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 must compensate for the undocumented model_path parameter. It adds some meaning by noting the DUTs are 'under a Model', tying model_path to a model context. Still, it does not specify path format, required syntax, or accepted values.

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

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

The description uses a specific verb ('Get'), a clear resource ('DUT names'), and a scope ('under a Model'). It distinguishes this from sibling tools like model_get_mvars or dut_get_setups, which target different objects.

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 intended context is clear: retrieving all DUT names associated with a model. However, it does not explicitly mention alternatives or when-not-to-use cases, so it falls short of full routing 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 supplied, so the description carries the behavioral disclosure burden. It communicates a read-only listing operation and clarifies that the result is names, not macro contents. However, it does not address edge behavior such as invalid model paths, ordering, empty results, or whether only direct child macros are included.

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

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

A single sentence with no filler. The operation, scope, and output kind are front-loaded, and every word contributes to the meaning.

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?

Adequate for a simple getter: it states the input scope and that the output is Macro names. It remains incomplete because there is no output schema and no detail about return type, empty results, or direct versus recursive enumeration, and no annotations cover safety semantics.

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 indicates that the single parameter model_path refers to the Model under which macros are listed, but it does not explain the expected path format or whether a full object path is required.

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

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

States a precise operation: enumerate all Macro names belonging to a Model. The resource and scope ('Macro names under a Model') distinguish it from sibling macro content/execution tools and other model_* getters, so an agent can identify the right tool without opening schemas.

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

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

Provides no guidance about when to choose this tool over alternatives. It does not mention prerequisites, exclusions, or sibling tools such as model_get_mvars, model_get_mpars, or macro_get_text, so the agent must infer usage purely from the tool name and minimal description.

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 available, the description carries the full burden. The verb 'Get' and the phrase 'with their values' convey a read-only operation that returns parameter data, but the description does not disclose return structure, failure behavior, path requirements, or potential side effects.

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

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

The description is a single focused sentence with no filler, front-loading the action ('Get all') and the resource ('Model parameters'). Every word contributes to the core meaning.

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 one-parameter getter, the description states enough to understand the basic invocation: provide a model path and receive all model parameters with values. However, without annotations, output schema, or parameter details, it is not fully complete for an agent that needs precise path syntax or return shape.

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

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

The schema provides no description for model_path and schema coverage is 0%. The description only indirectly suggests that model_path identifies the model whose parameters are fetched; it adds no detail on path format, required value, or constraints, so it does not compensate for the missing schema documentation.

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

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

The description uses a specific verb and resource: 'Get all Model parameters (MPar) with their values.' It clearly states the tool's scope and distinguishes it from mpar_get by emphasizing 'all,' though it does not explicitly name the sibling alternatives.

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

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

There is no guidance about when to use this tool versus mpar_get, model_get_mvars, or other related getters. No prerequisites, exclusions, or alternative recommendations are provided, leaving the agent to infer selection 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?

No annotations are provided, so the description carries the full burden. It implies a read-only operation through 'Get', but it does not disclose error behavior, ordering, whether values are returned for all variables or only defined ones, or any side effects. This is minimal disclosure for an unannotated tool.

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

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

The description is a single short sentence with no filler. It is front-loaded with the key action and resource, making it easy for an agent to quickly parse.

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 getter with one parameter and no output schema, the description covers the core purpose, but it omits parameter semantics, return format, and usage context relative to sibling tools. It is minimally viable but leaves notable gaps.

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

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

The schema has 0% description coverage, and the description does not explain the required model_path parameter. The parameter name is somewhat self-explanatory, but the description adds no meaning about what path format, scope, or resolution behavior is expected.

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-resource pair: 'Get all Model variables (MVar) with their values.' It clearly states the operation and scope, and the MVar label distinguishes it from sibling tools like model_get_mpars, though it does not explicitly contrast with alternatives.

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

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

There is no guidance on when to use this tool versus mvar_get, model_get_mpars, or other inspection tools. It also does not state prerequisites such as the model needing to exist or how the model_path should be 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the operation but does not mention whether the existing circuit is overwritten, whether the model must already exist, whether the netlist is validated, or what side effects occur on simulation or model state.

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

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

The description is a single short sentence with no unnecessary words, and the core action is front-loaded. However, it is so terse that it omits important context, so it is concise but not optimally informative.

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

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

With no annotations, no output schema, and only 0% schema description coverage, this minimal description leaves significant gaps: it does not explain prerequisites, overwrite behavior, circuit format, or expected return value. For a mutation tool, this is insufficient context for reliable invocation.

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

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

Schema coverage is 0% and the description only loosely identifies the 'circuit' parameter as a SPICE circuit netlist. It does not explain how model_path should be specified, what format the circuit string expects, or how the two parameters relate, so an agent has limited additional semantic grounding beyond parameter names.

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

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

The description states a specific verb ('Set') and resource ('Model's SPICE circuit netlist'), making the tool's function immediately clear. It also distinguishes itself from the sibling tool model_get_circuit by direction of operation, so an agent can identify the right tool.

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

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

The description gives no guidance about when to use this tool versus alternatives such as model_get_circuit or model_create. No conditions, prerequisites, or exclusions are provided, leaving usage entirely inferred from the verb 'Set'.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Check if...exists' communicates a safe, read-only predicate, but it does not specify the return type, whether a missing parameter yields false versus an error, or how param_path is interpreted. This is adequate but leaves minor gaps.

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

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

Two short sentences with no filler. The core action is front-loaded, and the use case sentence earns its place by adding context 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?

For a single-parameter existence check, the description plus schema is nearly complete. The main gap is the lack of an output schema and no explicit statement of return behavior, but the predicate semantics make the tool's likely behavior clear enough for most agents.

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 already documents param_path with an example and has 100% coverage. The description adds semantic value by clarifying that the path refers to a Model parameter within a circuit netlist, which helps an agent understand the intended path 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?

The description states a specific verb ('Check if...exists') and a specific resource ('Model parameter'), which clearly distinguishes it from sibling tools like dpar_exists (device parameter) and object_exist. The 'circuit netlist' context further defines the intended 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?

The description provides a clear use case: verifying that a circuit netlist defines an expected parameter. It does not explicitly contrast this tool with sibling existence checks or state when not to use it, but the context is sufficient for an agent to infer the primary scenario.

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, so the description carries the transparency burden. It does add useful context about the object lifecycle and minvalmax selection behavior, but it does not explicitly state that the operation has no side effects or what happens when param_path does not exist.

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

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

Two short sentences plus a tight bulleted option list. The core purpose is front-loaded and every sentence contributes useful information without repetition.

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

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

For a simple 2-parameter getter with no output schema, the description covers purpose, object constraints, and all minvalmax choices. It could be slightly more explicit about the expected return value or format, but 'value' is sufficient for a basic read 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?

The description adds meaningful semantics for the minvalmax parameter (Value, Min/Max, Opt Min/Opt Max), which the schema only exposes as bare enum strings. The param_path parameter is already documented in the schema with examples, so no additional path explanation is needed.

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

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

The description states a specific action and resource: 'Get a Model parameter value' and names the object type MPar. It also clarifies that MPar objects are netlist-defined and cannot be created or deleted, which distinguishes this read tool from mutation siblings.

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

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

The description implies read-only use ('Get') and warns that MPar objects cannot be created/deleted, but it never explicitly names alternatives or exclusions. An agent must infer from the tool name that setting or creating MPar values belongs elsewhere, such as mpar_set or mpar_set_bounds.

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

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

With no annotations, the description must carry the burden of explaining behavior. It transparently discloses the mutating nature of the call and that bounds can be targeted instead of the current value, but it remains silent on side effects, validation, or how existing bound values are replaced.

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

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

Two sentences with no filler; the primary operation is first and the optional bounds behavior is second. Every word adds necessary meaning.

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 three-parameter setter with no output schema, the core call can be made correctly from this text plus schema. Still, the lack of guidance about mpar_set_bounds and the absence of behavioral/result context leave meaningful gaps for an agent choosing among siblings.

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

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

Schema description coverage is only 33%, so the description must compensate. It usefully explains that value sets the current value and minvalmax selects a bound, but it leaves param_path with only the schema example and provides no detail on value constraints or path resolution.

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

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

The description states a specific action ('Set a Model parameter value') and clarifies the critical distinction between setting the current value and setting bounds via minvalmax. It is clear enough to identify this as the parameter setter, though it does not explicitly reference the dedicated sibling mpar_set_bounds.

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

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

It gives one direct usage directive: use minvalmax for Min/Max/Opt Min/Opt Max instead of the current value. However, it does not explain when to prefer this tool over mpar_set_bounds or other setters, leaving the selection among siblings partially to inference.

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 behavioral disclosure burden. It clearly states the MPar-only limitation and that it operates in batch mode, but does not disclose details like whether unspecified bounds are left unchanged, whether invalid paths fail silently, or whether this overwrites existing bounds. No annotation contradiction.

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

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

Two sentences, no fluff, and the MPar-specific limitation is stated prominently at the end. Every sentence adds signal.

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 batch setter with no output schema, the description covers the main eligibility constraint (MPar only) and the batch nature. It could be more complete by noting whether this replaces all bounds on the parameter or merges with existing values, but the schema and tool name cover most of the remaining context.

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

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

Schema description coverage is 0%, so the description must compensate. It names the bound fields (Min, Max, Opt Min, Opt Max) which maps to the input schema, and points to MPar parameters. However, it does not explain that 'path' is required per item or that each item can contain a subset of bounds; the schema's example path helps but the description adds the key MPar-specific context.

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 specific verb 'Batch-set' with resource 'MPar parameters' and clarifies scope ('Min, Max, Opt Min, Opt Max'), clearly distinguishing it from single-parameter setters like mpar_set.

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

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

The description states it 'Only works for MPar, not DPar', providing an explicit exclusion that guides the agent away from DPar parameters. It does not name alternatives like mpar_set or dpar_set explicitly, but the MPar/DPar distinction is sufficient context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only says 'create' and lists common uses. It does not mention whether the tool errors on duplicate paths, whether the parent model must already exist, whether the optional value defaults, or what side effects occur beyond creation.

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

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

The description is compact, front-loads the core purpose, and includes only useful examples of common MVar names. Every sentence contributes value without repetition or filler.

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

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

As a simple creation tool with complete parameter schema, the description is minimally adequate for invoking the tool. However, with no annotations and no output schema, it does not explain return values, error behavior, or preconditions, leaving some contextual gaps.

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

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

Schema description coverage is 100%, and both parameters have clear descriptions in the schema itself. The tool description adds no additional parameter-level meaning, so the baseline score of 3 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 names a specific verb and resource: 'Create a Model variable (MVar).' This clearly distinguishes it from sibling creation tools like dvar_create, svar_create, and ivar_create. The common-use examples further disambiguate the intended purpose.

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

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

The description implies usage by listing common MVar purposes such as SIMULATOR, PARAMETER_PRECISION, and WORKING_PRECISION. However, it does not explicitly state when to prefer this tool over alternatives or when not to use it, leaving the routing partially to inference.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only indicates a read operation ('Get') and says nothing about return format, error handling, or absence of side effects. This is minimal for a tool with no annotation support.

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

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

The description is a single six-word sentence with no filler or redundancy. It is appropriately short and front-loaded for a simple getter, with every word contributing to the stated purpose.

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

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

With no output schema and no annotations, the description should clarify what kind of value is returned and how it relates to sibling getters. It does neither, so an agent may call it correctly from the schema but cannot confidently interpret the result or choose it over 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?

Schema description coverage is 100%, and the var_path parameter is already documented with an example path. The tool description adds only the 'Model variable' context and does not meaningfully enrich the parameter meaning beyond what the schema provides.

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

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

States a specific verb ('Get') and resource ('Model variable value'), so the core action is clear. It does not explicitly distinguish itself from sibling getters like object_get_val or object_get_valof, but 'Model variable' narrows the scope enough to be useful.

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

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

No guidance is given about when to use mvar_get versus alternatives such as object_get_val or var_get_table_size. The description provides no context about the intended scenario or exclusions, leaving selection to inference.

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