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 is a mutation tool, yet nothing is said about where the material is written, whether it overwrites an existing material_id, what 'reimport-check' actually verifies, or what happens when PyDYNA is unavailable. Only the bare 'create' verb and the optional-dependency hint are 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?

A single tight sentence with the action front-loaded, no filler or redundancy. It is arguably over-compressed, but every word is doing work rather than 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 mutation tool with no annotations, no output schema, and five undocumented required parameters, the description is far too thin. It does not state the effect of the write, the units convention, or the meaning of the reimport-check, all of which an agent needs before invoking it.

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?

Five required parameters with 0% schema description coverage, and the description supplies no meaning for any of them (units convention, density/young_modulus/poisson_ratio expectations, material_id semantics). The description fails entirely to compensate for the schema gap, leaving an agent to guess units and value conventions.

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 (create) and resource (a MAT_001 elastic material fragment), which is more than a tautology. However, 'fragment' and 'reimport-check' are domain jargon that may not be self-explanatory, and it does not contrast itself with the sibling update_elastic_material, so the agent must infer that this is the creation path for new materials.

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

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

No when-to-use guidance is given. The obvious alternative, update_elastic_material, is never mentioned, nor is the condition that should route an agent to create instead of update. The phrase 'optional PyDYNA' hints at a conditional execution path but does not state when to enable or skip it.

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

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

No annotations are provided, so the description carries the full burden. It discloses a meaningful side effect (it saves a new keyword mesh, i.e. writes output) and the internal verification step, and it scopes the tool as not a complete deck. However it omits where the mesh is written, required environment/auth, and whether existing files are overwritten.

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 action and resource, with the scope caveat last. Efficient with no filler, though it is quite terse given the schema complexity it must support.

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 8 undocumented parameters, no annotations, and no output schema, the description is too thin. It conveys the operation's outcome but nothing about parameter meaning or write behavior that an agent needs to call 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 0% across 8 parameters; nothing in the schema explains nx, ny, size, units, origin, or the start-index fields. The description mentions an 'XY' mesh but adds no meaning about grid counts, sizing, units, or indexing conventions, leaving the agent to infer all 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: 'Create an XY shell mesh in native LS-PrePost', and adds that it verifies counts and saves a keyword mesh. This clearly distinguishes it from siblings like create_elastic_material or inspect_model, 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 scope caveat 'Not a complete analysis deck' gives implied usage context about what the tool produces, but there is no explicit when-to-use guidance nor any named alternative for building a full deck.

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 disclose two useful behaviors: the export creates a new owned job, and include-bearing exports are rejected. It omits permissions/auth requirements, reversibility, and what happens to the produced job, so it is only partially transparent 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?

Two short, front-loaded sentences with no filler; the main action is stated first and the constraint second. It is terse to the point of under-specification, but nothing 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?

For a write tool with no annotations, no output schema, and one undocumented parameter, the definition should say more about the model input and the resulting job. As written an agent lacks enough context to invoke it confidently.

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 required 'model' parameter. The description alludes to 'a standalone keyword model' but never clarifies whether the parameter is a path, id, or name, so it does not compensate for the undocumented 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 (Save/export) and resource (a standalone keyword model into a new owned job), which is clearer than most siblings such as inspect_keyword_deck or list_jobs. It does not explicitly name how it differs from those siblings, but the action and output (new owned job) are 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?

No when-to-use guidance or alternative tools are named; an agent cannot tell from this text why it would export rather than inspect a keyword deck. The only constraint given is that an include-bearing export is rejected, which is a precondition rather than usage routing.

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

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

No annotations are provided, so the description carries the full behavioral burden. It states the tool exports through LASSO, but says nothing about permissions, what is written or returned, how missing/ambiguous entities behave, or whether output is a file or inline data.

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

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

A single tightly written sentence with no filler, and the scoping condition leads. The trailing 'never guess an entity column' is slightly cryptic but does not bloat the text.

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

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

With five parameters at 0% schema coverage, no annotations, and no output schema, the description is far too thin for an extraction tool with entity-selection subtleties. An agent would be guessing at path/branch/variable/units semantics and at the shape of the 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?

Schema description coverage is 0% across all five parameters, so the description must compensate. It adds only a sliver of meaning for entity_id ('explicitly ID-selected', 'never guess an entity column') while path, branch, variable, and units remain entirely undocumented in both places.

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?

Names a specific verb (export/extract) and resource (binout curve), and narrows scope to 'scalar or explicitly ID-selected' curves. An agent can distinguish it from inspect_binout (inspection) and the d3plot extractors without opening schemas, though sibling routing is only implicit.

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 caution 'never guess an entity column' hints that entity_id must be supplied explicitly rather than inferred, but the description gives no when-to-use/when-not guidance or named alternatives among the many sibling extractors and inspectors.

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 discloses nothing: not whether the operation is read-only, what file/path assumptions apply, whether extraction is expensive, or what errors to expect. "Through LASSO" is opaque jargon rather than behavioral context.

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

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

The text is short and front-loaded, but this is under-specification rather than conciseness: two sentences cannot cover a 5-parameter required-input tool with zero schema documentation, and the first sentence spends its words on an unexplained acronym.

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

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

For a 5-required-parameter extraction tool with no annotations, no output schema, and no parameter descriptions anywhere in the schema, the description is grossly insufficient. An agent cannot determine valid units, quantity names, or state-index bounds from any source.

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% across 5 required parameters. The description partially compensates on two of them (states are 1-based; IDs are user IDs, not internal indices), which is genuinely useful, but path, units, and quantity — including accepted unit or quantity vocabulary — remain entirely undocumented.

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?

"Extract vectors through LASSO" names a vague verb-object pair and never states the resource (d3plot nodal data) that the tool name implies. It gives no basis for choosing it over closely related siblings such as extract_nodal_results or extract_lsreader_nodal. The second sentence is purely parameter guidance, not 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?

There is no statement of when to use this tool, when not to, or which sibling extraction tool is the alternative. An agent must guess between this, extract_nodal_results, extract_lsreader_nodal, and extract_node_history entirely from their 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?

With no annotations provided, the description carries the full burden, and it does disclose one genuinely non-obvious convention: states are 1-based and node IDs are true user IDs rather than internal indices. It says nothing about read-only behavior, file access requirements, cost, or what the returned vectors look like, so the disclosure is partial.

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 dense sentence with no filler, and the indexing convention is front-loaded rather than buried. It is arguably too terse for a five-parameter tool, 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?

Five required parameters, zero schema descriptions, no annotations, and no output schema means the description is the only carrier of meaning for a fairly complex call. One sentence cannot cover path/quantity/units semantics or the operational conditions for a successful extraction, so it is materially incomplete.

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% across five required parameters, so the description must compensate and only does so for two: 'states' (1-based) and 'node_ids' (true user IDs). The remaining params — path, quantity, and especially the format-sensitive units string — are undocumented in both the schema and 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?

States a specific verb (Extract) and resource (LS-Reader vectors), which separates it from the d3plot and nodal-results siblings by source type. It does not, however, explain what an 'LS-Reader vector' is or how it differs from extract_nodal_results / extract_node_history, so the agent must infer the distinction from the name alone.

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

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

There is no when-to-use guidance, no statement of prerequisites (e.g. an LS-Reader must be initialized or a job present), and no mention of alternatives among the many extraction siblings. The agent gets no routing help at all.

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 a 1-based indexing convention and warns that older vector ABIs are blocked, but says nothing about permissions, failure modes, return format, or what units must be supplied.

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 action front-loaded and no filler. It is appropriately sized, though the second sentence is a vague warning that could be sharper.

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 5 required parameters, no annotations, no output schema, and 0% schema coverage, the description is far too thin. An agent lacks the units vocabulary, quantity vocabulary, d3plot path expectations, and any sense of the 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?

Schema coverage is 0% and all 5 parameters are undocumented in both places. The description clarifies only the state index convention and hints at quantity values (position/displacement/velocity), leaving d3plot, node_ids, and especially the units string (accepted values?) 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?

States a specific verb (extract) plus the resource (native position/displacement/velocity at a 1-based state), which is clear enough to distinguish from history-style siblings like extract_node_history. However, it never names the actual related tools (extract_d3plot_nodal, extract_lsreader_nodal), so differentiation relies on 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?

It gives one exclusion (older unverified vector ABIs are blocked) and a generic pointer ("use explicit reader tools"), which implies when to reach for alternatives but names none of them. Usage is implied rather than stated with concrete 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, the description carries the full behavioral burden, yet it only notes that results are 'tested on the 4.13 profile' and that states are 1-based. It does not state read/write nature, permission needs, failure modes, or return shape for a 5-required-parameter extraction tool.

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

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

A single front-loaded sentence with no filler; the useful index-base and profile-compatibility facts come first. It is compact, though perhaps too terse given the documentation gaps elsewhere.

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 five undocumented required parameters, the description is significantly incomplete for an agent to invoke this tool correctly. The profile note and 1-based hint are a start but nowhere near 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 description coverage is 0%, so the description must document all five parameters. It only illuminates 'states' (explicit 1-based) and hints at node_ids ('true user node IDs'), while d3plot, quantity, and units remain undefined in both schema and 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 gives a verb ('Export') and a resource ('native vectors') scoped to node IDs and states, which hints at nodal time-history extraction. However, 'native vectors' is unexplained jargon, and it never clarifies how this differs from close siblings like extract_nodal_results or extract_d3plot_nodal, so an agent cannot confidently distinguish 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?

There is no guidance on when to use this tool versus the many sibling extraction tools (extract_nodal_results, extract_d3plot_nodal, extract_binout_curve). No prerequisites, exclusions, or selection criteria are stated, 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 full disclosure burden. 'Query' and 'return connected user node IDs' imply a non-mutating read and describe the return payload, which is useful. However, it says nothing about behavior on an invalid element ID, the node-ID domain of results, or any limits, so significant behavioral ground is uncovered.

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 zero filler: input scope first, return value second. Every clause earns its place and nothing is 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?

For a simple read tool with 4 params, no annotations and no output schema, the description covers the core question (what comes back) but omits half the parameters and any error/edge-case behavior. Adequate to invoke, but not complete for a tool whose schema documentation is entirely absent.

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

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

Schema coverage is 0%, so the description must compensate. It clarifies that element_id is a 'user' element ID (distinct from internal IDs) and that element_type covers shell/solid/beam, which the schema leaves bare with only a 'shell' default. It says nothing about the 'model' or 'file_type' parameters, so 2 of 4 parameters remain 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?

States a specific verb ('Query') and a concrete resource ('one shell/solid/beam') scoped by 'a user element ID', and it also names the return ('connected user node IDs'). An agent can distinguish it from list_nodes/list_parts, though the description never explicitly contrasts 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?

Usage is implied: 'using a user element ID' tells the agent the prerequisite input, but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., list_nodes) to route between. The agent must infer that this is the connectivity counterpart to the listing 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?

With no annotations, the description carries the full behavioral burden, and it does disclose a genuine constraint: it rejects incomplete MPP shard sets and works on a single literal file. However, it omits the output/return shape and any error semantics beyond the MPP rejection, leaving meaningful gaps for a no-annotation tool.

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

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

A single, front-loaded sentence with no waste. The scope and the MPP constraint are packed efficiently, though the compressed phrasing borders on terse.

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 listing tool with no output schema and no annotations, the description is adequate but thin. It conveys scope and one important edge case (MPP shard rejection) yet says nothing about return values or the optional branch parameter.

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

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

Schema coverage is 0%, so the description must compensate and largely does not. It only obliquely touches the parameters: "one literal file" hints that path must be a literal path (not a glob/pattern) and "branches/variables" gestures at the branch argument, but neither is defined or formatted.

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 ("List") and resource ("LASSO binout branches/variables"), which clearly distinguishes it from the sibling extract_binout_curve (extraction vs inspection). It does not explicitly name that sibling, so differentiation is implied rather than stated.

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

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

No when-to-use or when-not-to-use guidance and no alternatives named. The scope clause ("from one literal file") implies an inspection scenario, but the agent is not told when to pick this over extract_binout_curve or inspect_d3plot_database.

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 that it avoids launching LS-PrePost and may use optional LASSO, but it does not describe permissions, performance implications, what happens if LASSO is unavailable, or whether the read is purely local. This is meaningful but incomplete behavioral context.

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

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

The description is a single, front-loaded sentence with no wasted words. However, the phrase "through optional LASSO" is underspecified enough that it slightly obscures rather than clarifies the action.

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

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

Given a d3plot database inspection tool with no output schema and no annotations, the description omits what metadata is returned, what LASSO represents, and how the tool behaves without it. It is not complete enough for an agent to invoke it confidently on a d3plot file without additional assumptions.

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

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

Schema description coverage is 0% and the single required `path` parameter receives no explanation in the description. The description does not clarify accepted file formats, whether `path` points to a directory or file, or any syntax expectations, leaving the agent to infer everything 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 states a verb ("Read") and a resource ("file metadata"), but does not specify what metadata is exposed for a d3plot database, nor does it distinguish this tool from siblings like inspect_d3plot_scl or inspect_lsreader. The phrase "through optional LASSO" is cryptic and adds ambiguity rather than 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?

There is no explicit guidance on when to use this tool versus alternatives such as inspect_d3plot_scl, inspect_lsreader, or inspect_binout. The mention of "optional LASSO" hints at a mode but does not explain when that mode applies or when to choose a different inspection 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?

No annotations are provided, so the description carries the full behavioral burden, yet it never states permissions, return format, or what 'bounded staged input' concretely means or its limits. The single cryptic phrase is not enough to inform the agent about the tool's runtime behavior.

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

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

It is a single front-loaded sentence with no filler, which is structurally efficient, but the terseness comes at the cost of clarity rather than being genuinely economical. Brevity here is under-specification rather than conciseness.

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

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

With no annotations, no output schema, and 0% parameter coverage, the description must carry the whole load and does not. An agent lacks the input semantics, the return shape, and the behavioral profile needed to invoke the tool correctly.

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

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

The sole parameter 'path' has 0% schema description coverage and no enums, and the description provides no added meaning about its expected format or what it should point to. With only one required, undocumented parameter, the description fails to compensate for the schema's silence.

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 phrase 'Native SCL inventory' gestures at the resource (SCL) but never states a clear verb+outcome, and 'bounded staged input for builds without Python' obscures rather than clarifies what the tool actually does. It is indistinguishable at a glance from the sibling probe_scl and cannot be separated from it without further context.

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 usage hint is the bare qualifier 'for builds without Python,' which implies a condition but names no alternative (e.g., probe_scl) and gives no explicit when/when-not framing. An agent cannot reliably know when to prefer this over the sibling SCL 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, the description carries the full load. It usefully discloses two traits — no solver invocation and no INCLUDE expansion (so the inventory may be partial) — but omits whether the operation is read-only and says nothing about the shape of what comes back.

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; the qualifier is placed immediately after the purpose so it is read as a scope bound rather than 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 tool with an undocumented parameter, no annotations, and no output schema, the description should at least explain the argument and the return shape; it leaves both to the caller's 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?

One parameter ("model") with 0% schema description coverage, and the description adds nothing about it — no indication of whether it is a file path, model name, or PyDYNA handle.

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?

"Inventory a deck using PyDYNA" gives a clear verb (inventory) plus resource (deck), and the qualifier separates it from solver-running or include-resolving siblings such as run_on_version or inspect_model.

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 "no solver or include expansion is performed" clause implies a scope boundary, but it never names an alternative tool or states a when-to-use condition beyond that negative constraint.

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 adds one useful trait (execution in its own configured Python/ABI process, implying isolation) but omits whether the operation is read-only, what permissions or environment configuration are required, whether it has side effects, and what the inspection yields.

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?

It is a single short sentence with no redundant filler and the verb is front-loaded. However, the brevity comes at the cost of meaningful detail, and the phrase 'in its own configured Python/ABI process' is jargon that does not help selection.

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 an inspect tool with no output schema, no annotations, and an undocumented required parameter, the description should explain what gets inspected and what is returned. It leaves all of this unstated, making it incomplete for an agent trying 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 0% and the single 'path' parameter is undocumented in both schema and description. The description does not clarify what the path points to (a result file, a directory, a model directory), so it fails to compensate for the coverage gap.

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

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

The description names a verb (inspect) and a resource (a result via LS-Reader), which is more than a tautology, but 'a result' is vague about what is being inspected and what the tool returns. It does not differentiate itself from siblings that also operate on LS-Reader or inspect result files, such as inspect_d3plot_database, inspect_binout, or extract_lsreader_nodal.

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

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

No when-to-use, when-not-to-use, prerequisite, or alternative-selection guidance is given. The mention of 'LS-Reader in its own configured Python/ABI process' implies a specialized execution context but does not tell an agent when this is preferable to inspect_keyword_deck, inspect_model, or the extract_* 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 carries the full burden. It usefully discloses the execution model ('fresh native Python instance') and the returned contents, which is genuine behavioral context. It does not state whether the operation is read-only, what file path/permissions are required, or any performance characteristics of spawning a new instance.

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; the verb and resources lead. Slightly dense via the semicolon clause, but nothing 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?

For a 2-parameter tool with no annotations, no output schema, and 0% schema coverage, the description should compensate by clarifying parameters and preconditions. It names the return values (helpful absent an output schema) but leaves the input parameters and file requirements 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 0%, so neither 'model' nor 'file_type' is documented beyond a title and a default. The description's 'keyword/d3plot' implies file_type values, but neither the meaning of 'model' (e.g., a path) nor the full set of file_type options is explained, leaving the parameters largely opaque.

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 ('Open') plus the resources ('keyword/d3plot') and enumerates the returned data (counts, user part IDs, state times), so the agent knows what the tool does. However, it does not distinguish itself from siblings like inspect_keyword_deck or inspect_d3plot_database, which appear to cover overlapping ground.

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 'in a fresh native Python instance' hints at an isolation scenario, but there is no explicit when-to-use guidance and no named alternative among the many sibling inspect_* tools. The agent is left to infer when this is preferable to inspect_keyword_deck or the d3plot inspectors.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no 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?

No annotations are provided, so the description carries the full behavioral burden. It does disclose one meaningful interpretive trait — that results reflect configured executables, not verified files, and are not a compatibility signal — which is useful. It still omits whether this is a pure read, whether output is paginated, and what the entries contain.

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 compact sentence with the main action front-loaded and the caveat trailing. Nothing is wasted, though the terseness leaves the description feeling more like a warning than a full definition.

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-param listing tool with no output schema and no annotations, the description should at least sketch the shape of the returned entries, and it does not. The compatibility caveat is valuable, but an agent still lacks enough context to interpret the result confidently.

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 takes zero parameters, so per the rubric the baseline is 4; there is nothing for the description to disambiguate at the parameter level.

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 clear verb+resource ('List configured executables'), and the appended clause clarifies what an installation actually is: a configured executable rather than a discovered file. However, it does not distinguish this tool from the many other list_* siblings (list_capabilities, list_parts, list_jobs), so the agent must still infer its place in the toolbox.

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 clause 'file existence is not a compatibility test' implicitly warns against a misuse (judging compatibility from this output), which is a partial when-not. But it never names an alternative (e.g. probe_environment, run_on_version) or states the positive condition for choosing this tool, leaving usage largely inferred.

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 only the workspace scope; it says nothing about ordering (recency implied but unstated), how many jobs are returned by default, whether the list is capped or paginated, or what constitutes a 'manifest'. Significant gaps for a discovery 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?

One front-loaded sentence with zero filler. It is efficient, though its brevity borders on under-specification rather than true conciseness.

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

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

An output schema exists, so return values need not be described. But with no annotations, an undocumented limit parameter, and no usage guidance, the definition is too thin for a tool whose behavior (recency window, result count, ordering) an agent must reason about.

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

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

Schema description coverage is 0% and the single parameter (limit, default 20) is never mentioned in the description. The word 'recent' hints at ordering but gives no syntax or meaning for limit, so the description does not compensate for the schema gap.

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

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

States a clear verb ('List') and resource ('recent task manifests'), enough to distinguish from mutation siblings like create_shell_plate. However it offers no differentiation from the other list_* siblings (list_parts, list_nodes, list_installations), and the name/description resource mismatch ('jobs' vs 'manifests') may slow an agent slightly.

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 word 'recent' implies a temporal scope but there is no statement of when to use this versus read_job (the obvious companion tool) or the other list_* tools. No prerequisites, no exclusions, no alternatives 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 behavioral burden, and it does disclose two non-obvious traits: offset is zero-based and returned coordinates are undeformed (reference coordinates). It still omits pagination behavior beyond offset, ordering guarantees, and any auth/scope requirements.

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

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

Two tight sentences with the core listing behavior front-loaded and no filler. Slightly under-specified rather than bloated, but structurally 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 paginated listing tool with no annotations, no output schema, and 0% parameter coverage, the description is thin: it never describes the returned shape (e.g., ID-to-coordinate mapping) or pagination termination. An agent cannot confidently call it without guessing at model/file_type 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% across four parameters, so the description must compensate but only covers one: it explains 'offset is zero-based' but adds no meaning for model, limit, or the ambiguous file_type (default 'keyword'). Two of four parameters remain entirely undocumented.

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 ('Page') and resource ('native user node IDs and reference coordinates'), so the agent knows this lists nodes and their coordinates. It is clear on its own, but does not differentiate from siblings such as list_parts or extract_d3plot_nodal, leaving the agent to infer boundaries.

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 when-to-use guidance, no prerequisites, and no mention of alternatives among the many sibling listing/extraction tools. The agent gets no routing help for choosing list_nodes over extract_d3plot_nodal or get_element_connectivity.

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 that null names signal an unavailable binding, which is real behavioral information about the output, but says nothing about read-only semantics, pagination via limit, or what the required model argument expects.

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 the core purpose stated first and no filler. It is appropriately sized, though brevity comes at the cost of the missing detail noted elsewhere.

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?

No output schema, no annotations, and three parameters at 0% schema coverage. The one useful disclosure (null-name semantics) does not compensate for the absent parameter and usage information an agent needs.

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

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

Schema description coverage is 0%, so the description must compensate, yet it explains none of the three parameters (model, limit, file_type). The distinction between native IDs and optional names hints at the domain but gives no parameter-level 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?

States a specific verb and resource ('List native user part IDs'), and adds a secondary output (optional names). It is clear what the tool returns, though it never differentiates itself from the closest sibling, measure_parts.

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

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

No when-to-use guidance, no prerequisites, and no mention of alternatives such as measure_parts for the same domain. The agent must infer the usage context 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 full burden. It does disclose a genuinely useful behavioral trait — that returned values are raw/native and build-dependent, so units and layout must be interpreted — but it omits read-only nature, error conditions, and any notion of return shape.

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

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

A single front-loaded sentence with no filler. It is efficient, though arguably so terse that it under-serves the tool rather than being concisely complete.

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 0% parameter coverage, the description is too thin. It never explains the return structure, units, expected failures, or how to interpret the raw values it warns about, leaving significant gaps an agent must guess at.

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

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

Schema description coverage is 0% and the description adds nothing about the two parameters. The names (model, part_ids) are reasonably self-evident, but there is no indication of whether model is a path, ID, or handle, or what form part_ids take beyond an integer array.

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 verb ("Return") and a resource ("raw native part-volume command values"), which hints at measuring part volumes, but the phrasing is jargon-heavy and never plainly says "measures the volume of the given parts." It is distinguishable from siblings like list_parts or inspect_model only indirectly, so the purpose is implied 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?

There is no statement of when to use this tool versus alternatives such as list_parts or inspect_model, and no prerequisites or exclusions. The only usage-ish signal is the caveat that values "require interpretation," which hints this is a low-level raw tool but gives no 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 provided, so the description carries the full behavioral burden. It does disclose one non-obvious detail — that missing empty-model counters surface as warnings rather than errors — but says nothing about whether launching a 'fresh native instance' has side effects, how costly/slow it is, or what happens on failure. The one warning detail is helpful but far from sufficient for a heavyweight environment-probe operation with zero annotation coverage.

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

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

A tight, front-loaded two-clause sentence with no filler. It is compressed almost to the point of being cryptic, but nothing 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?

For a zero-param tool with no output schema, the description should at least characterize what is returned; it gestures at 'embedded Python' and mentions a diagnostic-warning behavior, but leaves 'native instance' and the response shape undefined. Adequate but with clear 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 tool takes zero parameters, so per calibration the baseline is 4. The description adds nothing here, but there is nothing to add; no parameters exist to document.

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 verb+resource pair ('launch a fresh native instance', 'report its embedded Python'), which is more than a restatement of the name. However, 'native instance' is never defined — of what, and for what product — so an agent can't cleanly separate this from probe_scl or run_on_version. The purpose is inferable but under-specified.

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

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

No guidance on when to use this versus probe_scl, list_installations, or run_on_version, all of which plausibly overlap. There are no stated prerequisites, no environment assumptions, and no exclusions.

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

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

No annotations are provided, so the description carries the full behavioral burden. It notes the native SCL implementation runs without embedded Python, which is minor execution context, but omits whether it is read-only, what it returns, or how the model is resolved.

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 padding. It is efficient, though the 'without requiring embedded Python' clause is somewhat tangential to the core action.

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

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

With no annotations, no output schema, and an undocumented single parameter, the description is too thin. It never explains what the returned count represents or how the model is supplied, leaving real gaps for the 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 single 'model' parameter has 0% schema description coverage, so the description must compensate. It implies the argument is a 'keyword model' but does not clarify whether it is a file path, name, or identifier, adding only marginal value over 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 names a verb and resource (count nodes in a keyword model) which is reasonably clear, but the tool name 'probe_scl' implies SCL exploration rather than node counting, creating ambiguity. It also fails to distinguish itself from siblings like list_nodes or inspect_model, leaving the agent unsure which node-related tool to pick.

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 guidance on when to use this tool versus alternatives. The phrase 'without requiring embedded Python' hints at a condition for preferring it, but no when-to-use, when-not, or sibling alternatives 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 burden. It usefully discloses the returned content (status, errors, log paths, artifacts), which doubles as a partial output contract in the absence of an output schema, but says nothing about failure behavior for a missing/invalid job_id or any auth/permission requirement.

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; the verb and the payload contents appear immediately. It could be slightly richer without bloat, but nothing 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?

For a one-parameter read tool with no annotations and no output schema, the description covers the return shape reasonably but omits the input's provenance and any error/edge behavior. Adequate but with clear gaps given the structured fields provide no backup.

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

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

There is exactly one parameter, job_id, with 0% schema description coverage, so the description must compensate. It never mentions the id or its expected form (e.g., where the id comes from, as returned by list_jobs), leaving parameter meaning entirely undocumented.

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 (read) and resource (a recorded task/job), and enumerates what the read yields: status, errors, log paths, validated artifacts. This contrasts with the sibling list_jobs, though that distinction is implied rather than stated.

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

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

No when-to-use guidance, no exclusions, and no mention of list_jobs as the alternative for enumerating jobs. The agent must infer that this is for a single job given an id, purely from the name and parameter.

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 one prerequisite ('Fringe codes require d3plot/state') and one default-retention behavior, which is useful, but it omits side effects such as file creation, overwrite behavior, output location, and 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?

The description is two sentences with the action front-loaded and no filler. The second sentence is dense and somewhat cryptic, but the overall length is appropriate and every sentence carries relevant information.

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

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

For a tool with five parameters, no annotations, no output schema, and 0% schema description coverage, the description is far too sparse. It gives a few behavioral constraints but omits critical invocation context such as what model types are valid, what view or file_type values mean, and what the rendered PNG is of.

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 five undocumented parameters. It adds partial meaning for 'fringe_code' and 'state' via the d3plot/state requirement, but it leaves the required 'model' parameter, 'view', and 'file_type' unexplained and introduces 'shell layer' and 'averaging' without tying them to schema fields.

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 output type ('native PNG') and uses a specific verb ('Render'), but it never says what is being rendered (model, view, simulation result). It does not distinguish the tool from siblings such as extract_nodal_results or inspect_model, leaving the object of the render 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 explicit when-to-use or when-not-to-use guidance, and no alternative tools are named. The only conditional statement is a behavioral prerequisite for fringe codes, not usage context relative to 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 exist, so the description carries the full disclosure burden. It adds a small amount of context (version comes from an explicit installation rather than a global default) but says nothing about permissions, side effects, failure modes, or how 'typed actions' are resolved. For a tool that executes arbitrary actions with arbitrary parameters, this is thin.

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 constraint, with no filler. Its brevity is genuinely efficient, though some of that brevity is under-specification rather than tightness.

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 complex (arbitrary action + version + free-form parameters, nested object), has no output schema, no annotations, and no schema descriptions to fall back on. The description does not supply the missing execution semantics, so an agent lacks enough to invoke it confidently.

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

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

Schema description coverage is 0% and there are three required parameters including an open nested object. The description does not explain what form 'version' takes, what a valid 'action' identifier looks like, or how 'parameters' maps to the action. It only faintly ties 'version' to an installation.

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 the verb 'Run' and gestures at the resource ('an existing typed action') plus a scoping condition ('explicitly configured installation; no global switch'). However, 'typed action' is undefined and the description does not distinguish this tool from siblings like search_commands, list_capabilities, or the various run/inspect tools in a way an agent can act 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?

'No global switch' loosely implies an alternative path (a global/default configuration), but no explicit when-to-use, when-not-to-use, or named alternative is given. The agent must infer that the counterpart is a globally-configured run mechanism.

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 does disclose one non-obvious trait: results are catalog rows and 'not executable validation', which prevents an agent from treating hits as runnable commands. It says nothing about result volume, ordering, or the limit behavior, but the output schema covers the return shape.

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

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

A single compact sentence with the core action front-loaded and the caveat appended; no wasted words, though the terseness borders on cryptic.

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 search tool with an output schema, the definition should at least explain query semantics and how it differs from the other search_* siblings. The non-executability warning is valuable, but the routing and parameter gaps leave the agent under-informed.

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 neither parameter is explained. The description says nothing about what 'query' matches against or what 'limit' controls (beyond the schema default of 20), so it fails to compensate for the documentation gap.

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

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

States a clear verb+resource: searching the 'command catalog'. The qualifier 'attributed Apache-2.0' and the non-executability caveat distinguish it from sibling search tools like search_knowledge and search_workflows, though the scope of the catalog itself is left somewhat cryptic.

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

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

No guidance on when to use this versus search_knowledge or search_workflows, and no stated prerequisites or exclusions. The agent must infer the routing from the noun 'commands' 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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no description.

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?

Tool has no 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?

Tool has no description.

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?

Tool has no 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, the description carries the full behavioral burden. It usefully discloses the nature of the corpus (authored tutorial/acceptance material rather than runnable recipes), which is a real trait beyond the schema. However it says nothing about authentication, rate limits, result size, or the meaning of the limit cap, leaving notable gaps for a zero-annotation 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 compact clause with the content-type caveat front-loaded and no filler. It is efficient, though the phrasing is slightly oblique for the tool's name.

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. But with no annotations and 0% parameter coverage, the description leaves the query semantics and result interpretation under-specified for a search tool.

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

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

Schema description coverage is 0% and the description adds nothing about either parameter. The agent gets no guidance on query syntax, matching behavior, or how limit interacts with results, so the meaning of the two parameters is entirely undocumented.

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 verb ("Find") and a resource ("authored tutorial acceptance cases"), but it never uses the term "workflows" and never distinguishes itself from the three other search-family siblings (search_knowledge, search_commands, search_workflows). An agent gets a rough sense of the content type but must infer 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?

"these are not completed automation recipes" is an implicit when-not hint that implies usage, but no explicit condition selects this tool over search_knowledge or search_commands, and no prerequisites or query expectations 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?

With no annotations, the description carries the full burden of behavioral disclosure. It usefully states that the original file is preserved, but it does not describe permissions, whether the modification is reversible, what parts of the material are altered, or what the operation 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 concise sentence with no filler. The preservation constraint is front-loaded alongside the core action, though the wording 'into a fresh deck' could be 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?

For a mutation tool with six required parameters, no annotations, and no output schema, the description is far too sparse. It states the basic action and one side-effect constraint but leaves parameter semantics, invocation context, and most behavioral details unaddressed.

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 six required parameters with 0% description coverage, and the description provides no meaning for model, material_id, density, young_modulus, poisson_ratio, or units. An agent gets no additional parameter guidance beyond the bare property names 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?

The description names a specific verb (Modify) and resource (elastic material) and distinguishes the operation from creating a new material, though the phrase 'into a fresh deck' is slightly awkward. It does not explicitly name or compare itself to the sibling create_elastic_material.

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 guidance on when to use this tool versus alternatives such as create_elastic_material or inspect_keyword_deck. The phrase 'preserve the original file' hints at a non-destructive update scenario but does not state when that scenario applies or what prerequisites exist.

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