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

With no annotations, the description does real work: it discloses the return convention (reply includes Name='...'), instructs the agent to persist that exact name for later select/set/delete, and warns about idempotency failures on specific kinds. It does not cover permissions, side effects on existing geometry, or whether the operation is reversible, so it falls short of fully carrying the no-annotation burden.

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 parenthetical scoping clause is front-loaded in the first sentence, followed by the success/name-capture rule and the re-add warning in priority order. No sentence is filler; the docs URL is a compact pointer rather than prose padding.

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 51-value enum creation tool with an output schema and full schema coverage, the description supplies the creation-only semantic, the name-capture workflow, and the non-idempotency warning that structured fields cannot express. Remaining gaps (side effects, failure modes) are modest given the output schema exists.

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 per-parameter enum doc already explains kind categories, SI meter units, planar_solid vertices/facets pairing, and library_object script_id. The tool description does not add syntax or format meaning beyond what the schema already states.

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 ('Add a simulation object') and immediately scopes it against siblings by declaring it is the SimWorks add* family only and that configuration belongs to set_property. An agent can distinguish it from set_property and object_action without reading either schema.

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

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

Gives explicit when-not guidance ('Do not call add again for an object that already exists (especially port_group, mode_port, fdtd)') and names the fallback alternative ('use object_action path forms instead of re-adding') plus the configuration alternative set_property. This is exactly the routing information an agent needs.

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

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

No annotations are provided, so the description carries the full behavioral burden. It says the tool configures a variable but does not disclose side effects, permission requirements, whether existing variables are overwritten, or what happens when value_data is ignored for result variables.

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 immediately conveys the action and target resource.

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

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

An output schema exists, so return values need not be explained. However, for a mutation tool with no annotations, the description is thin on prerequisites, side effects, and behavior when changing existing group variables.

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 kind, value_name, value_data, and value_type. The description mentions the same variable kinds but adds no syntax, formatting, or constraint 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 states a specific action and resource: configuring a setup, parameter, or result variable on the selected group. That is clearer than the tool name alone, but it does not distinguish this tool from siblings such as add or set_property.

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 no explicit guidance on when to use this tool versus alternatives, nor any prerequisites such as needing a group to be selected first. The only usage signal is implied by 'on the selected group.'

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. 'Query' implies a read, but nothing confirms read-only semantics, whether the dataset object must be pre-fetched, or what the call returns; for a zero-annotation tool this is a substantial gap.

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

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

A single short sentence with the resource and scope front-loaded and no filler. It is terse to the point of under-specification, but nothing in it is wasted.

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

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

With no annotations, no output schema, and no explanation of the returned shape, the description is too thin for a 3-parameter query tool. An agent still cannot tell what a listing versus a named lookup yields, or how the dataset_obj must be obtained before calling.

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%, with kind (enum), name ('omit to list'), and dataset_obj ('from get_results/dataset') all documented, so baseline 3 applies. The description adds no syntax or semantic detail 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?

States a specific verb (Query) and resource (parameters or attributes on a dataset object), so the agent knows exactly what is being read. The parenthetical '(not fd_instance)' scopes the target object type, though fd_instance is never defined and is not a sibling tool, so the differentiation is only partly 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?

The description gives no guidance on when to reach for this versus get_info, get_results, or object_action. The only usage hint ('omit to list') lives in the schema, not the description, and there is no statement of prerequisites or exclusions beyond the cryptic fd_instance note.

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. 'Low-level' hints at statefulness and handle-based semantics, but it never states whether open file handles must be tracked across calls, whether write operations truncate or append, whether overwriting existing files destroys data, or what errors look like.

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 front-loaded sentence with no filler, but the brevity is under-specification rather than efficiency for a seven-action, seven-parameter tool. Nothing is padded, yet nothing is prioritized either.

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

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

An output schema exists so return values needn't be described, but for a branching low-level I/O tool with no annotations and one required enum action, the description leaves the action-parameter pairings and I/O state model entirely unexplained.

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 nothing about parameters, and the key gap it should have filled — which of the seven optional parameters apply to each of the seven actions — remains unaddressed.

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 resource (files) and a class of operations (open/close/write), so the general purpose is inferable. But it is vague about scope and never distinguishes this low-level helper from siblings like load_data/save_data, nor does it cover the action enum values write, writem, writeascii, spwrite that dominate the schema.

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

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

There is no statement of when to reach for file_io versus the sibling tools, especially load_data/save_data which sound like the higher-level equivalents. No prerequisites, no exclusions, and no mention that fopen must precede fwrite/close.

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, so the description carries the full burden. It reveals one important behavioral quirk — kind=eme_analysis routes to getemeanalysis(name) rather than object get — which is valuable. But it says nothing about read-only vs mutation, return format, or that other kinds have side-effect-free semantics, leaving gaps for a 13-way dispatcher.

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?

Very short and front-loaded: the purpose sentence comes first, followed by the specific eme_analysis caveat. No filler. The line break mid-sentence is slightly awkward but not wasteful.

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 13-kind dispatcher with 10 parameters, no annotations and no output schema, the description is far too thin. It only addresses two kinds (eme_analysis and sweep via get_results), leaving the other eleven kinds' semantics, required name/name2/name3 combinations, and return shapes entirely to the schema.

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 all 10 parameters and enum values; baseline 3 applies. The description adds routing info for eme_analysis, but doesn't map name/name2/name3 to the remaining kinds, which is exactly the cross-parameter knowledge an agent would need.

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 first sentence states a specific verb+resource: discover properties and metadata. This distinguishes it from set_property and get_results, which are named explicitly. However, the tool actually returns many heterogeneous kinds (work_path, selection_count, homogeneity, source_list), and the description only frames it around properties, so the scope of the tool is understated.

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

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

Gives an explicit when-to-use rule ('Prefer this before inventing property names for set') and names alternatives (getemeanalysis for eme_analysis, get_results for sweeps). Does not cover when-not-to-use for the other 10 kinds, so guidance is partial.

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 usefully discloses the two-phase discovery workflow and the eme_sweep prerequisite, which are non-obvious behaviors. It omits a notable side effect visible only in the schema (results are written to a workspace variable via variable_name) and says nothing about whether calls mutate state or how errors surface for mismatched kind/parameter combinations.

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 core action is front-loaded in one sentence, followed by mode-specific instructions, with no filler. The terse pseudo-signature "getemesweep(dataset_name)" is a bit opaque but is compact enough to be acceptable.

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 10-parameter, 12-mode multiplexer with no annotations, covering only two kinds leaves the agent guessing on how to invoke electric, magnetic, dipole_power, source_*, update_index_monitor, and monitor_to_dataset. The output schema excuses it from explaining return values, but the missing side-effect note (variable_name storage) and uncovered kinds make it only minimally sufficient.

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, and the description earns a bump by explaining how parameters combine per mode: object_name + dataset_name [+ data_name] for kind=data and dataset_name alone for eme_sweep. That cross-parameter pairing logic is not expressed anywhere in the schema's per-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 opens with a specific verb+resource ("Extract simulation results") and its kind-based routing makes the tool's shape clear. It doesn't explicitly differentiate itself from close siblings like dataset_query or load_data, so an agent may still hesitate between them, but the core purpose 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?

It gives genuinely useful sequencing for two kinds: list-mode discovery before kind=data, and calling after run_action(eme_sweep). However, ten of the twelve enum values (raw, electric, magnetic, dipole_power, source_*, monitor_to_dataset, etc.) get no usage guidance at all, and there is no when-not-to-use or alternative-tool routing versus dataset_query.

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 does not state whether a group must already exist, what happens to an object's existing group memberships, whether the operation is reversible, or what permissions are required.

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. Both branches of the operation are expressed 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?

The tool is simple with only two parameters, full schema coverage, and an output schema. However, because it is a mutation with no annotations, the description should clarify prerequisites and side effects; it currently leaves those behavioral details missing.

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

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

Schema description coverage is 100%, so both the action enum and group_name are already fully documented in the schema. The description adds little beyond the schema baseline, which is appropriate but not compensatory.

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 pair (add/remove) applied to a clear resource (group membership), and it explains the selected object context. It does not explicitly distinguish itself from siblings like add_group_variable, but the purpose 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?

There is no guidance on when to use this tool versus alternatives such as add_group_variable, nor are prerequisites or constraints stated. Usage is only implied by the action enum and the one-sentence purpose.

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 but discloses almost nothing: it doesn't say that 'clear' destroys queued jobs, that 'run' executes work (possibly in parallel), whether solver_type filters or selects, or what permissions or side effects apply. For a tool with destructive and execution actions, this is a significant gap.

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

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

The single sentence is front-loaded and free of waste, which is good structure. It is under-specified rather than bloated, so it loses a point for not earning its place with any actionable detail.

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

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

Given four parameters, a multi-action enum with destructive/execution semantics, no annotations, and only a one-line description, the definition is not complete enough for an agent to invoke it confidently. An output schema exists, so return values needn't be explained, but the behavioral gaps around clear/run 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 description coverage is 100%, so each parameter (action enum, file_path, solver_type, parallel_mode) is already documented in the schema. The description adds no meaning beyond that, so the baseline of 3 is appropriate rather than higher.

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?

"Manage the simulation job queue" gives a verb and resource, but "manage" is vague and hides the four distinct operations (add/list/clear/run) that the schema reveals. It does not distinguish this tool from siblings like run_action or add, which could plausibly overlap with queue actions.

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 run_action, add, or the other job-related siblings, nor when each action is appropriate. The agent must infer from the enum that 'add' enqueues and 'run' executes, and nothing says which context selects this over a sibling.

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

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

With no annotations, the description carries the full burden; it does usefully disclose that kind=\"script\" loads and runs a script (an executable side effect) and that other kinds do not. It says nothing about whether loaded data overwrites existing workspace variables, error behavior on missing files, or unit handling for NK files beyond the schema field.

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

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

Three short bullets, front-loaded with the core action and no repeated filler. The SimWorks-specific notational aside (load('file_path'), .msf) is slightly opaque but earns its place by clarifying the script mode.

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 output schema covers return values, so the description need only explain invocation, which it mostly does by naming the primary discriminator (kind) and its two modes plus the project alternative. Given the output schema and 71% parameter coverage, nothing essential for a correct call is missing.

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

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

Schema coverage is 71%, so the schema already documents many parameters; the description only adds meaning for kind (script vs data) and file_path (prefer absolute paths). The remaining 16 parameters, including x/x0/y0/z0, swapb, reverse_index, and file_units, receive no explanation of when they are relevant.

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 concrete verb and resource set: load a script file, data files, or NK/raw arrays into the workspace. It explicitly distinguishes the script case from project files and routes project opening to a named sibling, so an agent can separate this from project_action and file_io without opening the schema.

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

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

Gives an explicit when-not ("To open a project (.sim/.mpps), use project_action(action=\"open\")") and clarifies that only kind=\"script\" executes a script while other kinds merely import data. It does not help choose among the 12 non-script kinds, so guidance is clear but incomplete.

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 lists operation types and warns against inventing names; it does not state that add/set mutate the material library, what permissions are required, whether operations are idempotent, or what happens to existing materials.

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, front-loaded with the tool purpose and followed by a direct caution. It contains no filler, though it is quite terse for a seven-action multiplexed tool.

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

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

An output schema exists and schema coverage is full, so return values and parameter details are covered elsewhere. However, for a multiplexed seven-action material tool with no annotations, the description omits action-dispatch semantics and mutation behavior, leaving the agent to rely heavily on enum names.

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

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

Schema description coverage is 100%, so all parameters are already documented in the schema. The description adds no parameter-level detail beyond operation nouns such as list, add, and set, making the baseline 3 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 the resource (materials) and primary operations (list, add, set, query), so an agent can identify the domain. It does not name the specific action enum values or distinguish this tool from generic siblings like add or set_property, but the material scope provides useful differentiation.

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

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

It gives one concrete workflow rule: 'list first if unsure', which helps avoid inventing material names. However, it does not explain when to use material_action versus sibling tools such as set_property or object_action, nor how to choose among the action variants, so usage guidance remains 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?

With no annotations provided, the description carries the full behavioral burden. It adds useful failure behavior (retry with a fuller path) and a same-group constraint for shift-select, but it does not disclose that delete, delete_all, disable, or vertex deletion are mutating/destructive, nor does it describe reversibility, permissions, or side effects.

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

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

The purpose line is front-loaded and the cheat-sheet is organized with bullets, but the select guidance substantially duplicates the detailed name/action parameter descriptions in the schema. The content is also unbalanced, devoting nearly all space to selection while the other actions go unaddressed.

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 seven-parameter, fourteen-action mutation tool with no annotations and an output schema, the description is incomplete. It thoroughly covers selection paths but says nothing about delete vs delete_all, copy behavior, enable/disable effects, add_vertex ordering semantics, or the destructive nature of several actions.

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 every parameter in detail, including select path rules in the name field. The description condenses the same select-path guidance and repeats the SI-meter note for vertices, adding convenience but little semantic detail 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 states it manipulates "selection and objects in the project tree", which gives a resource but uses the vague verb "manipulate" and does not differentiate from siblings such as set_property, group_membership, or add. The cheat-sheet narrows attention to selection paths, but the tool actually dispatches 14 actions including delete, copy, and vertex edits.

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 explicit when-to-use and when-not-to-use guidance for the selection family: prefer select/select_partial over re-adding, use shift_select to add without clearing, and never re-add or disable after a failed select. It is strong for select actions but silent on when to choose copy, delete, enable/disable, or vertex actions over 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?

No annotations are provided, so the description carries the full burden for a tool that mutates state (save writes a file, new may overwrite one). It says nothing about overwrite behavior, permission requirements, or what happens when open fails on a missing path — only a path-format preference.

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 capability front-loaded and no filler. The trailing path preference is terse and useful, though it dangles without explanation of why relative paths cause trouble.

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

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

An output schema exists and parameter documentation is complete, so return values and argument meaning are covered. However, with zero annotations on a write-capable tool, the description should still say something about save/new side effects or overwrite risk — that gap leaves it only minimally adequate.

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

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

Schema description coverage is 100%: the path parameter already documents 'Required for open; optional for save (omit = save current)' and action enumerates open/save/new. The description's 'Prefer absolute paths' adds a small format hint beyond the schema but no additional semantics, so the baseline 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?

States specific verbs (open, save, create) against a specific resource (simulation project), so an agent can distinguish it from generic file tools like file_io or save_data. It does not explicitly name which sibling handles adjacent cases such as workspace_action, so it falls 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 only guidance is the path tip 'Prefer absolute paths,' which is about parameter form rather than tool selection. Nothing says when to use project_action instead of workspace_action, file_io, load_data, or save_data, and no prerequisites or exclusions are given.

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

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

No annotations are provided, so the description carries the full behavioral burden, and it does disclose the key non-obvious trait: a timeout does not mean the job failed to start, and the solver may still be running in SimWorks. It stops short of saying which actions block versus return immediately, and doesn't cover permission or side-effect scope.

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, front-loaded with the purpose and then the safety rule. There is minor noise from stray quotation marks and a trailing newline, but nothing wasteful in 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 three-parameter multiplexed action tool with a full output schema and per-enum documentation, the description supplies the one thing the structured fields can't: the timeout/retry hazard. Only the absence of sibling routing and blocking-behavior detail keeps it from a 5.

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 action enum is documented per-value, so the baseline is 3. The description reinforces the confirmation requirement for specific action values but adds no syntax or format detail 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?

States a specific verb and resource set: running solvers, sweeps, and analysis scripts. The enum in the schema makes the scope concrete. It does not, however, name which sibling tool to use instead for adjacent jobs (e.g. jobs_action for job management), so differentiation is left to inference.

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

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

Gives a clear conditional rule — confirm with the user before action=run / run_sweep / eme_sweep — and explains the timeout recovery path. What it lacks is routing guidance across siblings or when-not-to-use cases beyond the confirmation gate.

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, and it only discloses what is written (workspace variables) and that a format is chosen. For a filesystem-writing tool it says nothing about overwriting an existing file at file_path, creating missing directories, or what errors look like — the traits an agent most needs before invoking 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?

Two short sentences with no filler: the capability first, then the disambiguation rule. Every clause earns its place.

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

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

An output schema exists, so return values need not be explained, and all three parameters are fully documented in the schema. The remaining gap is overwrite/error behavior for a mutation tool with no annotations — minor but not trivial.

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%, with the enum and the 'omit = all' behavior for var_names documented in the schema itself, so the schema does the heavy lifting. The description adds no format syntax, path conventions, or h5 naming caveats beyond what is already structured, so the baseline 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?

States a specific verb and resource ('Save workspace variables to a file') and immediately contrasts it with the sibling that handles a related but distinct job ('project_action(save) ... .sim project'). An agent can tell save_data (variable export, with format choice) apart from saving the whole project without opening either schema.

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

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

Explicitly names the alternative and the condition that selects it: use project_action(save) when the target is the .sim project, otherwise use this tool for variables. It does not cover when-not-to-use cases such as the target file already existing, but the primary routing decision is resolved.

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 mutation burden and does disclose that this changes a single EME window parameter, does not affect the selected object, and is not reflected in `get_info(kind="property")`. It does not discuss permissions, failure modes, or whether an EME analysis window must already be active, which are meaningful gaps for a write 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 front-loaded with purpose, then usage timing, then disambiguation and follow-up reads. It is appropriately sized and every sentence has a role, though the formatting and multiple sibling references make it slightly busier than strictly necessary.

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

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

An output schema exists, so return-value explanation is unnecessary, and the description correctly focuses on preconditions, disambiguation, and read-back paths. It stops short of stating that an EME Analysis Window must exist or what happens on invalid parameter names, which would complete the picture for a mutation tool with no annotations.

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 schema already documents both parameters thoroughly, including SI units and boolean format. The description adds domain value by naming the kinds of EME settings available (sweep type, wavelength range, cell group span, tolerances, energy conservation), but does not add syntax or format 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 states a specific verb and resource: setting one parameter on the EME Analysis Window. It explicitly distinguishes itself from the closest sibling, `set_property`, and names the underlying operation (`setemeanalysis`), so an agent can identify it without opening the schema.

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

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

It gives explicit timing: use before `run_action(eme_sweep)` / `eme_propagate` when configuring sweep parameters. It also states what this is *not* (`set_property`) and where to read values back (`get_info(kind="eme_analysis")`), leaving little 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, the description carries the full behavioral burden and does well: it discloses SI-only numeric values, failure recovery steps, layout restrictions after simulation, and the side effect that setting ``name`` affects later object_action select calls. It does not discuss permissions, reversibility, or whether setting overwrites existing values, so it stops short of full transparency.

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

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

The purpose is front-loaded in the first sentence, followed by operational guidance and recovery steps in a compact sequence. Every sentence carries useful information about invocation, failure handling, or follow-up behavior, with 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?

Given no annotations and the presence of an output schema, the description covers the key invocation context: exact property names, SI units, selection behavior, design-layout failure recovery, and name persistence. It is nearly complete, though it leaves out permission or reversibility details for a mutating tool.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters including the optional selection index and value formatting. The description reinforces SI-only numbers and exact property names, but adds little beyond the structured schema, making the baseline 3 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 and resource: setting one property on the currently selected object(s). It also distinguishes this from related operations by mentioning object_action select and get_info for property lookup, so an agent can tell what this tool is for without opening the schema.

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

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

It gives explicit usage guidance: call directly when the exact SimWorks property name is known, use get_info on failure, retry only the failed property, and switch to design layout when a design-layout/inactive error occurs. These are concrete when-to-use and recovery instructions rather than implied 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 behavioral burden. It helpfully states that the source must already exist, that the vectors must be equal length, and that `t` should preferably start at 0, but it does not explicitly describe overwrite behavior, reversibility, or other side effects of assigning a new signal.

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, front-loaded, and every sentence contributes: purpose, context, sibling differentiation, vector constraints, units, and a practical default. No sentence is redundant.

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 rich schema and presence of an output schema, the description covers the essential calling context: existing source requirement, vector-length constraint, units, and alternative tool routing. The main remaining gap is explicit mutation/overwrite behavior, which is not covered by annotations.

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 already 100%, so the schema fully documents parameter meanings and units. The description reinforces the equal-length constraint and adds practical guidance to start `t` at 0, but it does not add substantial meaning beyond the schema for the optional `fcentre` and `bandwidth` 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 states a specific verb and resource: assign a user-defined time-domain signal to an existing source. It immediately distinguishes the operation from `set_property`, making the tool's role clear against a key sibling.

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 says the tool is for custom pulses in FDTD/FDFD and clarifies that ordinary wavelength or pulse settings should still use `set_property`. This gives a clear when-to-use and when-not-to-use boundary with an alternative named.

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

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

With no annotations, the description carries the full burden and does well: it discloses that layout is a persistent state that gates other operations, and that edits fail in run layout. It omits that 'design' may discard existing results (that warning lives only in the schema), and says nothing about permissions or how the switch is reflected in responses.

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?

Front-loaded one-sentence purpose followed by a compact workflow line and a single sharp warning — no filler. Minor redundancy with the schema's enum description, and the critical result-discard caveat is split away from the main body.

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

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

Output schema exists, so return values need not be explained, and the single required parameter is fully covered. The remaining gap is relational: nothing clarifies when to reach for switch_view instead, which matters given how similar the sibling name is.

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 enum values are already richly documented in the schema, including the result-discard warning. The description adds workflow framing but no new meaning about the 'layout' parameter itself, so the baseline 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?

States a specific verb and resource: switching between the 'run' and 'design' layout modes, and enumerates both target states. It's clear what the tool does, though it never distinguishes itself from the sibling switch_view, which an agent could easily confuse with 'layout' switching.

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

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

Gives an explicit workflow sequence (run simulation → extract results → switch_layout('design') → switch_layout('run') only when the run/results UI is needed again) plus a concrete prohibition: never assume set_property works while in run layout after a solve. When-to-use and when-not-to-use are both stated with the triggering condition.

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

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

With no annotations, the description carries full behavioral burden and does not say whether the switch applies to the active viewport or all views, whether it persists in the document, or whether it resets zoom/selection. Only the basic action is conveyed.

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 short sentence, front-loaded with the verb and the two relevant targets. It is efficient, though it is a bare fragment with no additional context.

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 tool with full enum documentation and an output schema, the description is minimally adequate. It leaves open scope questions (active viewport vs. all views) that matter 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 100%, and the enum for view is fully documented in the schema, so the description needn't repeat it. It adds no meaning beyond the schema, which is acceptable at baseline for full 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?

States a specific verb (switch) and resource (CAD camera or view plane), which is clear enough to tell it apart from most siblings such as dataset_query or run_action. It does not explicitly distinguish itself from switch_layout, which an agent could plausibly confuse with a view change.

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 versus switch_layout or other view-related siblings, and no prerequisites or exclusions. The agent must infer usage 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?

With no annotations, the description carries the full burden and falls short: it does not disclose that clearing is destructive and irreversible, whether any confirmation or undo exists, or how targeted clearing (name/names) differs from clear_all. Only the plain verb "clear" signals mutability, and nothing warns that user data may be lost.

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, so it is efficiently sized. It is arguably too terse for a destructive tool, but no sentence is wasted or padded.

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

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

The tool has a five-value action enum and is destructive by nature, yet with no annotations and an output schema that only covers returns, the description should explain what each action destroys and whether operations are reversible. Omitting globals entirely and giving no risk framing leaves the definition incomplete for a data-destroying 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%, so the schema already documents name, names, and the action enum with its own description ("Clear workspace / console / globals"). The description adds no interpretation of the enum values or how name/names interact with each action, 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 gives a specific verb ("Clear") and resources ("workspace variables", "the script console"), which is far more informative than the generic name/title "Workspace". However, it omits the globals-clearing capability that accounts for three of the five enum values (clear_global, clear_all_global), so the stated purpose under-describes the tool's actual 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 this versus siblings like object_action, run_action, or add, nor any conditions or exclusions. The description only implies usage through the verb "Clear", leaving the agent to infer how to choose among the five actions and among the ~19 siblings.

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