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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the safety profile is covered structurally. The description adds only that activation applies to a single tab, with no detail on side effects, state changes, or error conditions.

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

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

One tight sentence with the action and its ID provenance front-loaded. Nothing extraneous.

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

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

An output schema exists, so return values need not be explained. For a single-parameter, idempotent, non-destructive activation tool with annotations covering safety, the description is nearly sufficient; only failure behavior is 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 single parameter has 0% schema description coverage, so the description carries the burden. It usefully identifies valid IDs as those returned by list_materials, which is real added meaning, but says nothing about format or what happens with an invalid/stale ID.

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

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

States a specific verb (activate) and resource (one material tab), and ties the operation to the correct ID source. It is distinguishable from siblings like load_material or save_material, though it doesn't explicitly differentiate itself from those near-neighbors.

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 prerequisite is implied clearly: the ID must come from list_materials. However, there is no guidance on when to prefer this over alternatives such as load_material or new_material, so usage is only partially covered.

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?

Annotations already declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the safety profile is covered. The description adds genuinely non-redundant behavior: a hard 256-node cap and the fact that the whole batch collapses into a single undo step, which is exactly the kind of context an agent needs for a mutation.

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

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

Two sentences, front-loaded with the core action and cap, then the field requirements. No filler or repetition of the tool 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 described, and annotations cover safety. However, the description never says which graph/material the fragment is added to, making `material_id` semantically invisible — a meaningful gap for a mutation that targets a specific material.

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

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

Schema description coverage is 0%, so the description must compensate. It does well on the nested node fields (type, name, parameters, node_position) and connection fields (from, from_port, to, to_port), but says nothing about the top-level `position` or `material_id` parameters, leaving half of the four parameters 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 and resource ('add ... nodes and their internal connections') and scopes it with a batch cap and undo semantics, which implicitly separates it from the singular add_node/connect_nodes siblings. It never names an alternative tool explicitly, so it lands just short of 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 phrase 'in one undoable operation' implies the batch use case, but there is no explicit when-to-use guidance versus add_node, connect_nodes, or validate_graph_fragment, and no mention of prerequisites (e.g., validating a fragment before adding). Usage must be 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?

Annotations already declare it is a write, non-idempotent, non-destructive, closed-world operation, so the safety profile is covered. The description adds only the node-type dependency hint and nothing about what graph/material the node attaches to or whether a material must be active first.

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 no wasted words. The prerequisite is stated compactly without 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?

An output schema exists so return values need not be explained, and annotations cover the safety profile. The remaining gap is parameter documentation (0% coverage) and the missing link to which material/graph receives the node, which the description should address for a 4-param mutation.

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 carry the burden for four parameters, but it does not explain node_type, position, material_id, or the parameters object. The only semantic hint is that ports/parameters are node-type-dependent, which is thin against a total 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?

States a specific verb and resource ('Add one node'), which distinguishes it from move_node, remove_node, and duplicate_node. It does not explicitly differentiate from add_graph_fragment, but the unit of action (one node) is clear.

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

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

Provides a useful conditional prerequisite ('Call describe_node_type first when ports or parameters are unknown'), which is real guidance. However, it names no alternative tool and gives no when-not guidance versus siblings like duplicate_node or add_graph_fragment.

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?

Annotations already disclose readOnly=false and destructive=false, so the safety bar is lowered. The description adds incremental context: it says overrides are constrained, and it explains the default fresh-tab behavior. But it does not explain whether applying is reversible, what validation failures look like, or the effect on overrides against non-declared parameters beyond 'may only target'.

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

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

Two sentences, front-loaded with the core action ('Validate and apply...'), then scoped constraints. No filler. It is efficient, though it could be slightly terser and better organized for scanning.

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 five parameters with zero schema descriptions mean the description leaves gaps around position, material_id, and recipe_id, and it does not state whether validation is automatic or what happens on invalid recipes. Complete enough for a simple apply tool, but not fully self-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 0%, so the description must carry semantics. It correctly documents override keys as Node.parameter and constrains overrides to parameters already declared by the recipe, which is meaningful. It also implies default create_new=true behavior and why it exists. However, position and material_id semantics are absent, and the description does not explain what recipe_id must reference.

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 compound action: validate AND apply a 'curated recipe', and scopes it further with 'optionally with constrained parameter overrides'. It distinguishes itself from siblings like list_material_recipes/describe_material_recipe by being the writer/application step. It doesn't explicitly name those siblings, so this is not 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?

Important usage is implied via 'By default a fresh material tab is created to avoid replacing existing inputs', which hints at a mutation workflow and a safe default. But there is no explicit when-to-use vs. alternatives, no mention of list/describe recipes as a prerequisite, and no exclusion guidance. Adequate but with clear gaps.

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?

Annotations already declare this is a non-read-only, non-idempotent mutation, so the safety profile is partially covered. The description adds one genuine behavioral detail—that both indexes are validated before connecting—but says nothing about the failure mode, whether an existing connection is overwritten, or how material_id interacts with the operation.

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

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

A single front-loaded sentence with no wasted words. Efficient, though the brevity contributes to the coverage gaps above.

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 presence of an output schema covers return values, but with 5 undocumented parameters (0% coverage), no annotations beyond safety hints, and zero usage context, the description is too thin for a mutating graph-editing 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% across 5 parameters, so the description must carry the burden. It clarifies that from_port is an output and to_port is an input, but leaves from_node, to_node, and especially the optional material_id completely unexplained.

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

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

The description uses a specific verb ('Connect') and precise resources ('an output port to an input port'), making the core action unambiguous. It doesn't differentiate itself from siblings like disconnect_nodes or add_node, but the purpose is clear.

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

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

There is no when-to-use guidance, no mention of the natural sibling (disconnect_nodes), and no stated prerequisites such as whether the nodes must already exist. The agent is left to infer 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds nothing behavioral beyond that, and its content list largely duplicates what the output schema carries. It is truthful and consistent, but contributes little beyond annotations.

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, stating the action first and the payload second. 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?

An output schema exists, so return values need not be explained, and annotations cover the safety profile. However, for a tool whose only input is an undocumented required id, the definition omits the one piece of information an agent actually needs: how to obtain or format recipe_id, and how it relates to list_material_recipes.

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 recipe_id is undocumented in both schema and description. The description does not say where a recipe_id comes from (e.g., list_material_recipes) or what format it takes, 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?

States a specific verb ("Return") and resource scope ("one recipe's") plus the returned content (graph, parameters, connections, suggested variations). The single-recipe scope implicitly distinguishes it from the sibling list_material_recipes and apply_material_recipe, but no sibling is named explicitly.

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 such as list_material_recipes (to find recipes) or get_material_graph (for one graph). The agent must infer when this tool is the right choice from the description 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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the scope of returned content (defaults, ranges, docs), which is useful but largely duplicated by the existing output schema.

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

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

A single front-loaded sentence with no filler, and the enumerated return contents are the most useful part to lead with.

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?

Because an output schema exists, the description need not explain return values, and annotations cover safety. What remains missing is the workflow context: that the 'name' must be sourced from list_node_types, and how the described metadata is consumed by siblings like add_node or set_node_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?

The single required parameter 'name' has 0% schema description coverage and no inline description. The phrase 'for a node type' only weakly implies the parameter is a node type identifier, and the description never says where a valid name comes from (e.g., list_node_types) or what format it takes.

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

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

States a specific verb ('Get') and resource ('node type') and enumerates what is returned: ports, parameters, defaults, ranges, documentation. This is clearly a metadata/introspection tool. It does not, however, distinguish itself from the sibling list_node_types, leaving the singular-vs-list distinction 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?

No explicit when-to-use or when-not-to-use statement, and no sibling is named as an alternative. Usage is only implied by the pairing of name similarity: list_node_types enumerates types and this one describes a single one, presumably before add_node or set_node_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?

Annotations already declare readOnly=false, destructive=false, idempotent=false, and openWorld=false, so the safety profile is largely covered. The description adds only the 'one exact' precision constraint and says nothing about behavior when the connection is absent or whether the removal is undoable. With annotations carrying the load, this is an adequate 3.

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 the brevity borders on under-specification rather than informative concision.

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 for a mutation tool with 5 entirely undocumented parameters and no usage or failure-mode guidance, the description is too thin to let an agent call 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% across 5 parameters, so the description must compensate and does not. It never explains from_node/from_port/to_node/to_port as the connection's endpoints or what material_id does, leaving every parameter as a bare title.

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

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

The description states a specific verb ('Disconnect') and resource ('graph connection') with a scope quantifier ('one exact'). It implicitly contrasts with connect_nodes and remove_node, so an agent can distinguish the operation, though the 'exact' qualifier is never explained.

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 versus alternatives such as remove_node or connect_nodes, and no mention of prerequisites (e.g., that the connection must currently exist). 'One exact graph connection' hints at precision but leaves the routing decision 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?

Annotations declare readOnlyHint=false, destructiveHint=false, and idempotentHint=false, so the mutation/safety profile is partly covered. The description adds a genuinely useful behavioral detail not in the annotations: the copy defaults to an 80-pixel offset. It does not disclose whether the duplicate shares the source's parameters or material, which is the key ambiguity for a duplicate op.

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; the offset default is the one fact it chooses to surface. It is efficient but arguably too terse given the surrounding schema gaps.

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

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

An output schema exists, so return values need not be described. However, for a mutation tool with zero schema parameter documentation, the description omits what 'node' accepts, what material_id does, and whether the copy inherits source properties—material gaps 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 0% across three parameters, so the description must carry the burden and largely does not. Only the position default (80-pixel offset) is explained; 'node' and 'material_id' are left entirely undefined, including whether material_id defaults to the source's material.

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 and resource ('Duplicate one node'), which is clearer than a bare name restatement. It does not, however, distinguish itself from adjacent siblings like add_node or move_node, so an agent must infer that it operates on an already-existing node.

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 duplicate versus creating a node with add_node, nor on prerequisites such as whether the node must exist in an open material. The only conditional hint is the default offset, which is behavioral 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?

Annotations declare destructiveHint=true and readOnlyHint=false, yet the description 'return every output file' reads like a safe read operation and never explains that exporting writes/overwrites files on disk or what is destroyed. With annotations present the bar is lower, but this gap is exactly the surprising behavior an agent needs 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 front-loaded sentence with no filler; the verb and resource lead immediately. It is appropriately sized, though the brevity is partly the cause of the missing guidance 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?

For a destructive, 4-parameter export tool with 0% schema coverage, the description omits usage context, parameter meaning, and any warning about the write behavior. An output schema exists so return values need not be explained, yet the description redundantly covers them while leaving the operationally important gaps 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?

Schema description coverage is 0% across 4 parameters (size, prefix, profile, material_id), and the description adds no meaning for any of them — not even what 'prefix' or 'profile' refer to. The one reference to 'size' describes the returned file size, not the size parameter, so it does not 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?

States a specific verb+resource ('Export a material') and even summarizes the return payload (output files with size, hash, channel). This distinguishes it from preview/render siblings in spirit, but it never names an alternative tool, so the differentiation is implicit rather than explicit.

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

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

There is no when-to-use guidance and no mention of alternatives like preview_material or render_material_variations. The agent must infer from the name alone whether exporting is the right operation versus previewing or rendering.

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?

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so safety is fully covered. The description only adds a list of returned content, which is already captured by the output schema; it says nothing about failure modes or what 'current' means if no material is loaded.

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

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

A single front-loaded sentence with no filler. The enumerated payload makes it slightly list-like, 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?

Return values are covered by the output schema and safety by annotations, so the remaining gap is small but real: how material_id interacts with 'current' is never resolved for a tool whose only parameter is undocumented.

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 one parameter (material_id) at 0% schema coverage, so the description carries the full burden. The description never mentions material_id; its meaning is only obliquely implied by 'current', and the default empty-string behavior is left 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 (return) and resource (material graph) and enumerates the payload: connections, parameters, save path. That distinguishes it from get_material_node and get_node_parameter, though it never names those siblings explicitly.

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 'current' hints that it targets the active material, but there is no explicit statement of when to use this versus get_material_node, list_materials, or load_material. 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and a closed world, so the safety profile is fully covered structurally. The description adds that output includes ports and parameter values, but nothing beyond that (no auth needs, no error behavior). Adequate but not rich.

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

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

A single tight sentence with no wasted words, and the core purpose is front-loaded. It is efficient, though very sparse given the tool's documentation gaps.

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

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

An output schema exists, so return values need not be spelled out, and annotations cover the safety profile. However, for a two-parameter tool with 0% schema coverage, leaving material_id entirely undocumented makes the definition only marginally complete.

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

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

Schema description coverage is 0%, so the description carries the burden of explaining the two parameters. It implies the 'node' identifier but never defines its format, and it does not mention the optional 'material_id' parameter at all, leaving scope/context ambiguous.

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

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

The description states a clear verb ('Inspect') and resource ('graph node'), and adds scope detail ('including ports and current parameter values'). It does not differentiate from siblings such as get_node_parameter or describe_node_type, which also expose node data, 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?

There is no guidance on when to use this tool versus get_node_parameter, describe_node_type, or get_material_graph. No context, prerequisites, or exclusions are provided.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that — no note on what happens if the parameter is absent, how defaults (material_id='') behave, or what the read 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?

A single front-loaded sentence with no filler, which is structurally clean. However, at this length it is under-specified rather than genuinely concise — nothing beyond the bare action is conveyed.

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 three undocumented parameters, no usage context, and no behavioral detail, the definition is too thin for an agent 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% across three parameters. The description does not explain what 'node' identifies, that 'name' is the parameter key, or why 'material_id' has an empty-string default. It leaves all three parameters semantically 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 ('Read') and resource ('one node parameter'), which is enough to distinguish it from the write-side sibling set_node_parameter. It stops short of naming or contrasting with any sibling explicitly.

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 list_node_types, describe_node_type, or get_material_node, nor any prerequisite information (e.g., that the node must already exist). The agent must infer usage entirely from the name.

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

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

The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that results include implementation status, which is useful, but it does not disclose pagination, authentication needs, or other behavioral details.

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 redundant or filler language. Every word contributes to specifying the action and its output.

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

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

With zero parameters, rich annotations, and an output schema, the description is almost sufficient for correct invocation. The main gap is that 'internal bridge actions' remains somewhat undefined, but the agent does not need additional parameter or return-value instructions.

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

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

The tool has zero parameters, so parameter semantics do not require description support. The baseline for no-parameter tools is 4, and the description does not need to compensate for missing schema detail.

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 ('List') and resource ('internal bridge actions') and adds the returned attribute ('implementation status'). It does not explicitly differentiate from sibling tools, and the term 'bridge actions' is not defined, but the purpose is clear.

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

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

There is no explicit when-to-use guidance, no statement of prerequisites, and no mention of alternatives among sibling tools. Usage is only implied by the tool's name and the listed content.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so safety is fully covered structurally. The description adds only the scope ('current PBR material node'); it says nothing about when profiles are unavailable, empty results, or whether an unset material_id resolves differently, but with annotations this lower bar is acceptable.

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 efficient sentence with the scope constraint front-loaded, no filler or repetition. It is appropriately sized, though it leaves the parameter behavior unexplained.

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?

Return values are covered by the existing output schema, so the description needn't explain them. However, for a tool whose only parameter is undocumented everywhere, the description does not compensate enough to let an agent invoke it confidently without guessing material_id 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?

The single parameter material_id has 0% schema description coverage, so the schema provides no semantics at all. The phrase 'current PBR material node' hints that omitting material_id falls back to the current node, but the description never states what the id refers to or how it relates to the node/graph ids used by sibling tools.

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 (export profiles) with a clear scope qualifier: profiles supported by the current PBR material node. An agent can tell this apart from export_material or list_material_recipes without opening the schema, though it 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 only implied: enumerating supported export profiles before choosing one for export_material. There is no explicit when-to-use, no when-not-to-use, and no named alternative tool to route to.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only the 'curated declarative starter recipes' framing, with no detail on result ordering, limits, or pagination, so it earns a baseline 3 rather than more.

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 resource named first and the optional filtering clause trailing. Zero wasted words.

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

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

An output schema exists, so return-value description is unnecessary, and annotations cover the safety profile. For a two-param list tool the description is nearly complete, lacking only filter semantics.

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

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

Schema description coverage is 0%, so the schema titles ('Tag', 'Query') carry little meaning. The description compensates by mapping the filters to text and tag, but it gives no matching semantics (substring vs exact, tag vocabulary) and no note that both are optional with empty-string defaults.

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

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

States a clear verb+resource ('List ... recipes') with the qualifier 'curated declarative starter recipes', which distinguishes it from the sibling describe_material_recipe and apply_material_recipe. It doesn't explicitly name those siblings, so it stops short of a 5.

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

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

'Optionally filtered by text or tag' implies how to narrow results, but there is no statement of when to use this versus describe_material_recipe or apply_material_recipe. Usage is implied rather than prescribed.

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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only the note that session IDs are stable, which is mildly useful context but not rich behavioral disclosure beyond the structured fields.

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 that names the action and the payload with zero waste. Nothing is redundant and nothing needed is deferred.

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

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

For a zero-parameter list tool with an output schema and full annotation coverage, the description is nearly sufficient. It omits any statement about scope (all open tabs vs. filtered) or ordering, but the output schema relieves it of explaining return values.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. The description correctly does not pad with parameter talk, since there is nothing to parameterize.

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 (open material tabs) plus the fields returned (session IDs, active state, undo state). This distinguishes it from graph/node-level siblings like get_material_graph or list_node_types, though it does not explicitly contrast itself with any 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?

Usage is only implied: an agent infers it should call this when it needs to enumerate open material sessions. There is no explicit when-to-use statement, no prerequisites, and no named alternative (e.g. material_maker_status) to route between.

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?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds the filtering capability but nothing about pagination, ordering, or result size (limit defaults to 200), so it stays at baseline.

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; the resource is stated first and the optional filters follow immediately. Nothing redundant 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?

An output schema exists, so return values need no explanation, and the annotations cover safety. The remaining gaps are the undocumented limit/pagination behavior and the lack of routing to describe_node_type, leaving the definition only minimally complete for a multi-sibling listing 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%, so the description must compensate. It maps 'category' and 'text' to the category and query parameters, adding real meaning, but omits the limit parameter and any syntax hints for the text query.

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 (Material Maker node types) plus the optional filters, so the core action is unambiguous. However, it does not distinguish itself from the closely related sibling describe_node_type, which retrieves detail for a single node type; an agent must infer the list-vs-describe split.

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 names no when-to-use condition, no alternatives, and no pointer to describe_node_type for per-node detail. 'Optionally filtered' describes capability but not when this tool should be chosen over its 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?

Annotations already declare readOnlyHint=false and idempotentHint=false, telling the agent this mutates session state and is not repeatable-safe. The description adds only the constraint that the material must already exist and that paths may be absolute or user-relative; it says nothing about failure when the file is missing or what state is affected.

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 path guidance is appended where it is relevant. Slightly terse rather than overly long, which is the right failure mode here.

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

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

An output schema exists so return values need not be described, and annotations cover the safety profile. However, for a mutation-flagged loader the description omits what happens on a missing/invalid file and any permission context, leaving real gaps.

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

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

Schema description coverage is 0%, so the description must carry the weight for the single 'path' parameter. It clarifies that either an absolute or user-relative path is accepted, which is genuinely beyond the bare schema, but gives no format examples or constraints (extensions, separators).

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 (load) and resource (.ptex material), and adds the path semantics that qualify the operation. It does not explicitly name how it differs from siblings like list_materials or activate_material, so it stops short of a 5.

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

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

There is no statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The use case (bringing an existing material file into the session) is only implied by the name and description.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and a closed-world scope, so the safety profile is fully covered. The description adds the diagnostic categories covered, but says nothing about cost, rate limits, or whether it blocks while an operation is active.

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

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

A single sentence with no padding, and the most concrete content (queue state) is front-loaded.

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

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

An output schema exists, so return value detail is not the description's responsibility. For a zero-param read-only tool the description is essentially sufficient; only the sibling differentiation gap 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?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to disambiguate beyond the empty schema.

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

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

States a specific verb ('Return') and enumerates the diagnostic resource contents (queue state, operation timing, versions, bridge errors). It does not, however, distinguish itself from the sibling material_maker_status, which sounds like the nearest 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?

No when-to-use guidance at all. With material_maker_status as a close sibling, the agent has no signal for choosing diagnostics over status, or for when troubleshooting is the right 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds genuinely new information by naming the three things it verifies (bridge, Material Maker, graph), which is more specific than a bare 'status' label, but it says nothing about failure reporting, timeouts, or partial-readiness states.

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

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

A single sentence with zero filler, front-loading the verb and the three checks. Nothing to trim and nothing buried.

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 no explanation, and the description covers what is being probed. What is missing is the selection rationale against the closely related diagnostics tool, but for a trivial no-arg probe this is nearly complete.

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

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

The tool takes zero parameters, so the schema carries no semantics to miss; baseline for a no-param tool is 4.

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 ('Check') and enumerates the resources being checked: the bridge, Material Maker itself, and a material graph. An agent understands this is a readiness/preflight probe. It does not explicitly differentiate itself from the sibling material_maker_diagnostics, which likely overlaps in intent.

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 statement of when to call this versus material_maker_diagnostics, nor when readiness should be re-verified (before load/export, after reconnects, etc.). The usage context is only weakly implied by the word 'ready'.

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?

Annotations already declare this is a non-read-only, idempotent, non-destructive write. The description usefully clarifies the position is absolute rather than a delta, which matters for correct invocation. It does not disclose what happens if the node is missing, what material_id does, or whether the move is undoable.

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 efficient sentence with the key detail (absolute coordinates) front-loaded. It is arguably too terse for a 3-parameter mutation, 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?

An output schema exists, so return values need no explanation, and annotations cover the safety profile. However, an undocumented optional parameter and the absence of any failure/permission context leave the definition merely adequate for a mutation tool.

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

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

Schema description coverage is 0%, so the description must carry the burden. It only clarifies that position is an absolute [x, y] pair; the node parameter and especially the optional material_id (which defaults to empty string, with no hint of its role) are left 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 (move), resource (node) and destination format (absolute [x, y] graph position). An agent can distinguish it from add_node, connect_nodes or set_node_parameter without reading the schema. It stops short of naming sibling alternatives, so not 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?

No when-to-use guidance, no prerequisites, and no mention of alternatives such as set_node_parameter or add_node. The agent must infer context 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?

Annotations declare this is a non-read-only, non-idempotent, non-destructive mutation, so the safety profile is partly carried. The description adds real behavioral content by revealing the default PBR output node is created, but it stays silent on a key question for a 'new project' action: whether unsaved current work is discarded or replaced.

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

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

A single front-loaded sentence with zero filler that conveys both the action and the resulting state.

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 no explanation. However, for a state-creating mutation that starts a new project, the description omits whether the existing project/unsaved graph is replaced, 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?

The tool takes no parameters, so there is nothing for the description to disambiguate; the baseline for a zero-parameter tool 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 ('open') and resource ('new material project') and adds the notable detail that the default PBR output node is included. It clearly implies a fresh creation step, though it never names the sibling it contrasts with (load_material, activate_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 when-to-use or when-not-to-use guidance and no alternative is named. The word 'new' hints at 'start fresh vs open existing', but the agent must infer that load_material is the alternative for opening an existing project.

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?

Annotations already establish readOnly, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds genuinely useful information not in structured fields: the return is MCP image content, which is essential since there is no output schema. It does not, however, explain the empty material_id default, what model/rotation defaults produce, or whether it re-renders live state.

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

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

A single front-loaded sentence with no filler; the resource and the return format are stated up front. Nothing to trim.

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

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

For a simple read-only render tool whose annotations cover safety and whose return type the description actually discloses, this is close to adequate. The gap is parameter semantics and the inability to distinguish it from the several other preview/render siblings.

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

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

Schema description coverage is 0% and all five parameters (model, width, height, rotation, material_id) are undocumented in both schema and description. The description's mention of a '3D PBR preview' weakly implies what model/rotation/width/height control, but it leaves material_id and the size defaults entirely unexplained.

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

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

Names a specific action and outcome: returning a live 3D PBR preview as image content. The verb+resource is unambiguous, but it does not distinguish itself from siblings like render_node, preview_material_maps, save_material_preview, or preview_material_variations, which are all plausibly 'produce a visual' tools.

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

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

There is no guidance on when to use this versus the many visual-output siblings, nor any prerequisite (e.g., whether a material must be loaded first). 'For visual inspection' is the only hint at context and it does not route the agent.

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

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

Annotations already declare readOnly/idempotent/non-destructive safety, so the bar is lower. The description adds genuine lifecycle context beyond them: the temporary export is deleted once its bytes are embedded, making the ephemerality of the operation clear.

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

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

Two tight sentences, front-loaded with the core action, then the deletion caveat, then the alternative. No wasted words.

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

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

Annotations cover the safety profile and there is no output schema, so return-value explanation is less critical. However, for a 3-parameter tool with 0% schema coverage, omitting any description of size, profile, or material_id leaves a real gap in how 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%, so the description carries the full burden for size, profile, and material_id, yet it explains none of them. It obliquely implies format/profile context (PNG/JPEG/WebP) but adds no real semantics for any parameter.

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

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

States a specific verb+resource+scope: 'Export and return all PNG/JPEG/WebP PBR maps as labeled MCP images.' It also names the sibling it is not (export_material), letting an agent distinguish it 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?

Gives an explicit routing rule: use this for in-context MCP images, use export_material when persistent output files are required. The when-to-use and the alternative with its selecting condition are both 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?

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds 'without keeping files,' which is useful ephemeral-output context not conveyed by annotations, but it does not explain return format or any auth or rate-limit behavior.

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

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

The description is a single front-loaded sentence with no wasted words. However, it is under-specified rather than efficiently concise, omitting information needed to act on the tool correctly.

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

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

Given five parameters, nested objects, no output schema, and no parameter descriptions, the definition is too thin. It does not explain how variations are interpreted, what 'labeled 3D MCP images' means in practice, or how material_id and other parameters affect 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 five parameters, including a required nested 'variations' object and material_id. The description says only 'parameter variations' and provides no details about size, model, rotation, material_id, or the structure of the variations map, so it fails to 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?

The description states a specific verb and resource: return parameter variations as 3D images. However, it does not clarify what kind of parameter variations or how this differs from sibling tools like preview_material, render_material_variations, or preview_material_maps, leaving the purpose only partially clear.

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

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

There is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative among the many preview/render siblings. The phrase 'safe parameter variations' implies a preview or exploration context, but usage must be inferred rather than read.

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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds only that redo applies to a single operation in the selected or active material; it omits preconditions, failure behavior on an empty redo stack, and whether the stack survives material switches.

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 or repetition. It is efficient, though arguably too terse for a state-mutating tool with preconditions.

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 the tool is structurally simple with one optional parameter. However, key behavioral preconditions for a non-idempotent redo operation are missing, leaving the definition only minimally complete.

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

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

The single parameter has 0% schema description coverage, so the description must compensate. It partially does by implying that the material defaults to the 'selected or active material', matching the optional material_id with an empty default, but it never explains the argument's format or what a non-empty value does.

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 ('Redo') and resource scope ('one operation in the selected or active material'), which is clearly distinguishable in practice from its sibling 'undo'. It does not explicitly name undo as the counterpart, but the operation itself 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?

No when-to-use guidance is offered: it never states that a prior undo must exist, what happens when the redo stack is empty, or how it relates to the sibling 'undo' tool. The agent must infer usage entirely from the tool name.

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?

Annotations already declare destructiveHint=true and non-idempotent, so the danger profile is covered. The description does add one real behavioral fact beyond annotations — that all graph connections are removed with the node — but omits whether the deletion is recoverable via undo, and says nothing about the material_id scoping parameter.

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 and the key destructive scope detail attached immediately. Efficient, though the terseness leaves room that useful context could have occupied.

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

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

An output schema exists, so return values need not be described, and the destructive annotation covers safety. Still, an undocumented second parameter and no note about reversibility/undo leave gaps for a mutation tool in a graph-editing cluster.

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 carry parameter meaning and it does not. It only obliquely implies the required 'node' argument and gives no hint of what the optional 'material_id' defaulting to empty string is for (scoping the node to a specific material graph, presumably).

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 (remove) and resource (node), and the scope clause 'and all of its graph connections' implies it is distinct from disconnect_nodes. It never names a sibling, so atomic differentiation is left to inference, but the purpose itself 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?

No when-to-use guidance, no exclusions, and no mention of alternatives. In a cluster containing disconnect_nodes, duplicate_node, move_node and undo, an agent gets no help deciding that removing a node is the right operation versus merely unlinking it or moving it.

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

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

With destructiveHint=true already declared, the description adds real value by disclosing that the original graph state is restored after rendering, softening the destruction risk. It also discloses the 64-combination cap and the mode-dependent outputs (preview PNGs vs. per-manifest results), going beyond what annotations convey.

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 tight sentences with the core purpose and the state-restoration guarantee front-loaded, followed by the complex parameter format and the mode distinction. Every sentence earns its place, with no redundant restatement of the 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?

For an 8-parameter, nested, destructive tool this is only partially complete. The nested variations structure and state restoration are covered and the output schema covers manifests, but the semantics of mode, size, model, profile, rotation, and material_id remain unexplained anywhere.

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 carries full burden. It explains the most complex parameter (variations) thoroughly with a concrete nested example, and describes mode behaviorally, but leaves six other parameters — including the required output_dir plus size, model, profile, rotation, and material_id — completely undefined.

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 and resource — render parameter combinations and restore the graph state — and quantifies scope with 'up to 64'. However, it never distinguishes this from the very similarly named sibling preview_material_variations, leaving an agent to infer the boundary.

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 only implied: 'Preview mode writes 3D preview PNGs; export mode writes the selected profile' hints at which mode fits which goal but never states when to choose this tool over preview_material_variations or render_node. 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the agent knows this is a destructive write operation. The description adds a useful prerequisite that the destination directory must exist, but it does not disclose whether an existing PNG is overwritten 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?

A single compact sentence that front-loads the action and includes the key operational constraint. There is no filler or redundancy.

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

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

Although an output schema exists and annotations cover safety, the tool has six parameters with zero schema descriptions and the description does little to fill that gap. For a destructive file-writing tool, it should do more to clarify parameter meanings and usage relative to siblings.

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

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

Schema description coverage is 0% across six parameters, so the description must compensate. It only vaguely implies the 'node' and 'path' parameters and says nothing about width, height, output, or material_id, leaving most parameters semantically 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 and resource: render one node output to a PNG file. It is clear on its own, but it does not explicitly differentiate itself from sibling tools like render_material_variations or preview_material, which also produce visual outputs.

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

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

Provides only a prerequisite (destination directory must exist) but no guidance on when to use this tool versus siblings such as preview_material, save_material_preview, or render_material_variations. There is no indication of when it is not appropriate.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the write/destructive profile is carried by structured data. The description adds the path-reuse behavior, but says nothing about overwriting an existing file, permission requirements, or failure modes, so it does not go far beyond the annotations.

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

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

A single front-loaded sentence that states the action first and the argument nuance second, 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. However, for a destructive save operation with an undocumented material_id and no overwrite warning, the definition is 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 description coverage is 0%, so the description must compensate. It meaningfully explains the path default (omit to reuse the existing .ptex path) but leaves material_id completely undefined in both schema and description, so half the parameters remain 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 (save) and resource (the current material), and adds a distinguishing behavioral detail about the path argument. It does not explicitly differentiate itself from near-neighbors like save_material_preview or export_material, but the action 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?

Gives a concrete condition for one parameter ('omit path to reuse its existing .ptex path'), which is useful, but never says when to choose this tool over export_material or save_material_preview, nor what prerequisites (an active material) must hold.

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?

Annotations already declare this as a non-read-only, destructive, non-idempotent write, so the safety profile is carried by structured fields. The description adds that the captured content is the rendered 3D PBR preview in PNG, but does not disclose what the destructive behavior actually means (overwriting an existing file at path) or how material_id/rotation select what is rendered.

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 and output front-loaded and no wasted words. Nothing could be cut without losing information.

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

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

The output schema means return values need no explanation, but for a 6-parameter destructive file-writing tool the description gives almost no parameter or behavior detail. An agent cannot determine required inputs, defaults, or overwrite semantics from the description alone.

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?

All 6 parameters have 0% schema description coverage, so the description carries the full burden and does not meet it. It never mentions that path is required and is the write target, that model defaults to a sphere, that width/height control the saved image, or what material_id and rotation select — the PNG/3D hints only weakly imply width/height.

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 (save) plus the resource (Material Maker's 3D PBR preview) and the output format (PNG), which separates it from siblings like save_material (saves the material itself) and preview_material_maps (2D maps). It stops short of naming any sibling explicitly, so an agent must infer the distinction.

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

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

There is no when-to-use statement, no prerequisites, and no reference to alternatives such as preview_material, preview_material_maps or export_material. The agent must infer that this tool is for writing a raster preview rather than inspecting or exporting the material.

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?

Annotations already declare idempotentHint=true, destructiveHint=false, and readOnlyHint=false, covering the safety profile. The description adds that the parameter is 'validated' and triggers the update path, which are behavioral traits beyond the annotations, but these are vague and lack detail on validation outcomes 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?

A single sentence with no wasted words, front-loading the core action. Slightly ambiguous due to 'validated' 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?

Output schema covers return values and annotations cover safety, but with 4 undocumented parameters and no usage guidance, the description is inadequate for a mutation tool in a complex system like Material Maker.

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 4 parameters. The description adds no meaning for 'node', 'name', 'value', or 'material_id', leaving the agent with no information on expected formats or constraints.

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

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

States a specific verb (set) and resource (node parameter) and mentions triggering Material Maker's update path. However, it does not differentiate from sibling tools like get_node_parameter or describe_node_type, so an agent cannot immediately tell why to choose this one.

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

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

The description provides no when-to-use guidance, no prerequisites, and no alternatives. It only states the action, leaving the agent to infer 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?

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the meaningful constraint that undo is limited to a single operation (not a bulk/history rollback), but says nothing about what state is restored or what happens when there is nothing to undo.

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 scope qualifier placed right after the verb, so nothing is wasted. It is arguably under-specified rather than over-long, but as written it is tight and front-loaded.

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

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

An output schema exists, so return values need not be described, and annotations cover the mutation profile. For a simple one-parameter tool this is close to adequate, but the unexplained material_id and the absence of any redo cross-reference leave the definition minimally complete.

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

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

There is one parameter, material_id, with 0% schema description coverage and a default of empty string. The description never explains what material_id means or what happens when it is omitted (presumably the active material), leaving a real semantic gap that the schema does not fill.

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 ('undo') and bounds its scope ('one operation in the selected or active material'), which is far more informative than a bare 'undo'. It does not, however, name or contrast with its sibling 'redo', so an agent must infer the pairing.

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 by the operation itself and the mention of 'selected or active material' gives some context, but there is no explicit when-to-use guidance and no reference to the redo sibling or to any prerequisite (e.g. that an operation must exist in the history).

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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, and 'without changing Material Maker' merely restates that safety profile rather than adding to it. Nothing is said about what validation actually checks, whether it can fail loudly, or what makes a fragment unacceptable.

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

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

One short, front-loaded sentence with no filler or repetition. It is efficient, though the extreme brevity leaves other dimensions under-served rather than being a structural defect.

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 not required, but with zero parameter documentation and no stated criteria for a successful validation, an agent cannot tell what a pass/fail means or how to build the fragment it should submit. The definition is thin for a validation entry point in a 30+ tool surface.

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 carries the full burden for three parameters and adds nothing about them. It gives no hint about the shape of node/connection objects or what material_id does when omitted (defaulted to empty string), leaving a required 'nodes' array entirely 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 ('preflight' i.e. validate) and resource ('graph fragment'), and the qualifier 'without changing Material Maker' implicitly separates it from the mutating sibling add_graph_fragment. It never names that sibling, so the differentiation is inferential 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?

'Preflight' implies the check-before-commit workflow, which is useful implied guidance, but the description never states when to call this versus add_graph_fragment or apply_material_recipe, nor what conditions make a fragment invalid. Usage must be inferred.

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