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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the agent knows this mutates state. The description adds the group-ID-0 root convention, which is useful behavioral context, but says nothing about the revision parameter, persistence, or undo implications of this state change. With annotations carrying the safety profile, a 3 is appropriate.

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

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

Two tight sentences with zero filler; the primary action is front-loaded and the ID-0 special case follows it. Every sentence earns its place.

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

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

For a state-changing tool with no output schema and no schema descriptions, the definition covers purpose and the ID-0 convention but omits what revision means and what the tool returns on success. Adequate but with clear gaps.

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

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

Schema description coverage is 0%, so the description must compensate for three undocumented parameters (id, intent, revision). It explains only the sentinel value for id (0 = root Scene group) and leaves both intent and revision completely uninterpreted, so the compensation is partial at best.

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: making a named native Plasticity group the active destination for newly created objects. This clearly distinguishes it from siblings like plasticity_create_group, plasticity_move_to_group, and plasticity_rename_group. It is not tautological and an agent can identify the operation without opening the schema.

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

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

Gives clear context ('newly created objects' go into the activated group) and an explicit edge-case instruction: group ID 0 restores creation to the root Scene group. It does not name an alternative or state when-not to use it (e.g., for moving existing objects, use plasticity_move_to_group), so it stops short of a 5.

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

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

Annotations supply readOnlyHint=false and destructiveHint=true, so the mutation profile is covered. The description adds valuable behavior beyond that: the operation completes 'in one Undo step' and is a 'direct placement, not a persistent concentric constraint,' which tells the agent there is no lasting parametric relationship. It stops short of detailing failure modes or the revision/auth requirements.

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

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

Front-loaded with the core action, then the mode/relation semantics, ending with the key non-parametric caveat. It is densely packed for a 9-parameter tool and mostly earns its length, though the mode description could be tightened.

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

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

For a complex mutating tool with 9 parameters, 0% schema coverage, and no output schema, the description covers the geometric parameters and the direct-placement behavior well. The unexplained required revision and intent parameters are the main remaining gap, but return values need no coverage since no output schema exists.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning and largely does: it explains preserve vs anchor modes, the signed axial offset along the target axis (axialOffsetMm), the same/opposed direction relation, and rotation around the fixed axis as roll. It does not clarify ids, intent, or the required revision, leaving those 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 (align), a precise resource (exact native cylinder axes for moving bodies), and scope (one or more bodies, single Undo step). This clearly distinguishes it from sibling aligners like plasticity_align_planar_faces, plasticity_align_linear_edges, and plasticity_align_vertices without needing to open any 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?

Implicitly signals the tool's domain through 'native cylinder axes' and 'not a persistent concentric constraint,' which helps an agent understand intent, but it never states when to prefer this over its align siblings or what preconditions (e.g. faces must be cylindrical) apply. Usage is inferable but not explicit.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds real value beyond that by disclosing that the operation is a single Undo step (reversibility) and warning to re-read edges afterward because native edge direction is topological, not semantic. It does not detail what geometry is affected or permission needs, but given annotation coverage this is a strong addition.

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 dense but well-ordered sentences that front-load the purpose before the parameter behavior and the caveat. Every clause earns its place, though the second sentence is packed and slightly heavy for its length.

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

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

For a mutating tool with no output schema, nested objects, and 8 parameters, the description covers the key behavioral traits (undo semantics, geometric behavior of the offsets) and adds a meaningful post-placement caveat. It lacks any output or failure-mode note, but the essentials for correct invocation are present.

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 the burden and compensates well: axialOffsetMm is explained as a signed axial offset along the fixed target tangent, relation (same/opposed) as tangent direction control, and rotationAroundAxisDeg as roll around the fixed target line. It does not gloss ids, intent, or revision, but those are comparatively conventional, so overall the non-obvious semantics are covered.

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 (align) and resource (one exact native Line edge) with scope: moving body set to fixed edge, in one Undo step. Distinguishes itself from sibling alignment tools (align_planar_faces, align_cylindrical_faces, align_vertices) by naming the exact edge-pair target.

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

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

The description implies when to reach for this tool (aligning exact native Line edges) but never explicitly states when-not to use it or names an alternative among the many align/select siblings. No prerequisites or preconditions are called out, so usage is inferred rather than directed.

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 readOnlyHint=false, but the description adds meaningful behavioral context: the rotation is the shortest normal-to-normal rotation, in-plane edges are not independently aligned, all moving bodies preserve relative placement, and the operation occupies one native Undo step.

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?

Every sentence is front-loaded and informative, moving from the core action to relation semantics, gap measurement, rotation caveat, and undo behavior with no filler or repetition.

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

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

For a complex mutation tool with no output schema, the description covers the alignment behavior, relation modes, rotation limitation, and undo semantics well. It is slightly incomplete on the roles of ids, revision, and intent, but an agent can still invoke the tool correctly.

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

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

With 0% schema description coverage and 7 parameters, the description must carry the burden. It defines 'relation' (opposed/same) and 'gapMm' ('measured from the target along its outward normal') and implies sourceFace/targetFace, but leaves ids, revision, and intent undocumented.

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

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

The description states a specific verb and resource: 'Rigidly rotate and move current bodies' so a source planar face aligns with a target planar face. It distinguishes itself from sibling alignment tools (align_cylindrical_faces, align_vertices, align_linear_edges) by naming the exact face-pair behavior.

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

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

The description explains the two relation modes ('opposed' seats outward normals against each other, 'same' keeps them parallel), which implies usage, but it never explicitly states when to use this tool versus alternatives like move, rotate, or align_vertices, nor any when-not condition.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered. The description adds meaningful behavior beyond that: rigid translation preserving relative placement, and that the operation occupies exactly one Undo step. It does not, however, explain the destructiveHint aspect or any preconditions on the referenced geometry.

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, front-loaded with the core action and each sentence carrying distinct information (mechanism, placement/undo behavior, disambiguation). No filler or 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 a 6-parameter, nested-object, zero-coverage tool with no output schema, the description is directionally complete for the geometric mechanics but omits any explanation of the required revision parameter and the intent parameter. The safety profile is covered by annotations, but the parameter surface is not fully addressed.

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

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

With 0% schema description coverage the description must carry parameter meaning. It explains ids ('one or more moving bodies'), sourceVertex, targetVertex, and offsetMm (world-space millimeter offset), but never mentions the required 'revision' parameter or the optional 'intent', leaving a required field undocumented in both schema and description.

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

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

The description gives a precise verb+resource: rigidly translating moving bodies so a named source vertex reaches a target vertex plus a world-space offset. The resource (B-Rep vertices) inherently distinguishes it from the sibling align_planar_faces / align_cylindrical_faces / align_linear_edges tools, and the closing sentence separates it from a persistent coincident constraint.

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

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

It clarifies the operation class ('direct placement, not a persistent coincident constraint') but never states when to choose this over the related align_* siblings or move/rotate. Usage is implied by the operation type rather than explicitly routed, leaving the agent to infer selection conditions.

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

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

With no useful safety signal from the annotations beyond readOnly/destructive flags, the description carries heavy behavioral detail: exports STEP, builds a conforming cohesive mesh, runs a 'pinned network-disabled Code_Aster solver', checks the Plasticity revision before and after solving, and saves an immutable report. It also discloses important interpretation caveats, e.g. that V3 means different things for CZM_EXP_REG vs CZM_LIN_REG, and that the result 'does not establish strength, design adequacy or print approval'.

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 content is largely substantive given the 20-parameter, multi-mode tool, and the purpose is front-loaded. However it is delivered as one dense run-on block with no headings or paragraph breaks, mixing prerequisites, axis-alignment rules, solver internals, and result-semantics caveats, which makes it hard to scan. Some sentences repeat the same-material/single-process constraint, so it is longer than strictly necessary.

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

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

There is no output schema, so the description should cover what comes back; it does partially, disclosing the STEP export, immutable saved report, V3 labeling semantics, and the scope limitation on the result. Given the heavy nested schema it also explains the key mode-dependent requirements. The main gap is that it does not fully enumerate all input semantics, but for a tool this complex it is close to 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% across 20 parameters, so the description must compensate, and it covers a great deal: it explains modeILaw defaults, useOrthotropicBulkProperties behavior, the poissonRatio/evidence requirement, the mixedModeRecordIds plus initialStiffnessEvidence.materialProcess and prescribedDisplacementGlobalMm alignment rules, and support/load face currency. It leaves some parameters (increments, meshSizeMm, adhesionPenalty, residualStiffnessRatio, splitPlanes format) unaddressed, so it is strong compensation but not exhaustive.

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 opening sentence names a specific verb and resource ('Run an experimental cohesive solver response for one current native Solid split by 1..255 ordered parallel planes into bulk regions') and immediately scopes it to a single same-material interface. It also explicitly distinguishes itself from adjacent work by rejecting dissimilar-material/multi-material prints and naming plasticity_plan_cohesive_layer_planes as the required prerequisite. An agent can tell it apart from plasticity_analyze_static_fem or plasticity_cohesive_fem_report without opening the schema.

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

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

It gives strong conditions for legitimate use: 'Every new analysis requires a profile-bound layerPlanePlan created by plasticity_plan_cohesive_layer_planes; arbitrary unbound split planes are rejected', and it states which law is the default versus which must be explicitly selected (CZM_EXP_REG vs CZM_LIN_REG) and when the Turon route applies. It also gives clear exclusions (dissimilar materials, mixed-mode prerequisites). It stops short of comparing against sibling analysis tools explicitly, so a 4 rather than 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false; the description reinforces this with 'it does not create geometry' and enumerates the returned quantities (radii, sector radii, slant length, included angle). It adds real context about rejection behavior, though not about performance or error-reporting beyond the listed exclusions.

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 operation front-loaded, followed by return values and exclusions. Dense but every clause carries information; 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?

With no output schema, the description usefully enumerates the returned geometry values and the accepted/rejected face conditions. It leaves revision/intent semantics unexplained, but for a single-analysis tool the operational picture is essentially complete.

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

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

Schema coverage is 0% for 3 parameters, so the description must carry the load. It does describe the required input face's constraints (complete conical-frustum, two full circles, one straight seam), which sharpens the 'face' parameter, but says nothing about 'revision' or 'intent'. Partial compensation only.

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?

Specific verb+resource: 'Calculate an area-preserving annular-sector profile' from a conical-frustum face. It is cleanly distinguished from the sibling plasticity_create_cone_development by the explicit 'it does not create geometry' clause, so an agent can route correctly 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 clear input preconditions (one complete native conical-frustum face, two full circles, one straight seam) and explicit rejection cases (pointed cones, partial cone faces, extra boundaries). It never names an alternative tool to use for those rejected cases, so it falls short of full when/when-not/alternative 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?

Adds rich context beyond annotations: bounded/action-free profile, no CAD creation or print dispatch, image format/size limits with macOS HEIC conversion, durable request that is not retried under the same ID after interruption. These are exactly the behavioral traits an agent cannot derive from readOnlyHint=false / openWorldHint=true.

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 tightly packed paragraph that is front-loaded with the action and image limits, then return shape, then scale constraint and guarantees. Dense but every sentence carries information; slight length is justified by the complexity.

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

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

For a no-output-schema tool the description usefully characterizes the return payload and the durability/no-CAD guarantees, but given the sprawling nested input schema and 0% parameter coverage, it leaves too much of the input contract unexplained to be fully complete.

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

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

Schema description coverage is 0% across 7 deeply nested parameters, and the description only glosses imagePaths (formats/sizes) and prompt/text. It says nothing about the large 'context' object (method enum, geometry fields, material, assignments, assumptions) or how evidence/answers feed the workflow, so the schema does the heavy lifting unaided.

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: 'inspect the supplied photo/sketch views and text' and names the output artifacts (functional interfaces, candidate features, scale-confidence status, one question package). It clearly differs from the many CAD-creation siblings, but it never names the closest sibling (plasticity_design_reference_request) to route the agent between the two.

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

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

It implies usage conditions (needs traceable mm scale evidence for dimensioned results; at most one next question package implying iteration). However, it never states when to prefer this over plasticity_design_reference_request or other analysis tools, leaving alternative-selection 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?

The annotations already declare a safe read-only, non-destructive, closed-world operation, and the description adds substantive behavioral context: it does not use the display mesh, does not claim an exact continuous maximum (it is a sampled approximation), and does not change the document. These are real traits beyond the annotations, though the sampling resolution tradeoff could be elaborated further.

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, front-loaded with the action and scope, then reference sourcing, then returns and limitations. No filler; every clause conveys information an agent needs.

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

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

There is no output schema, and the description compensates by enumerating return content (curvature magnitude in 1/mm, finite radii in mm, extrema locations, straight-flag). Only the unexplained revision parameter leaves a minor gap.

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

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

With 0% schema description coverage, the description carries the burden, and it explains the two branch shapes of the edges parameter (bodyId+edgeId vs bodyId+segmentEntityId) and where to obtain those IDs. The revision parameter is left unexplained, which keeps it from a 5.

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 precise verb+resource+scope: sampling Plasticity's native B-Rep curvature vector at 100 positions along each selected current edge. It clearly distinguishes itself from the numerous curve/edge siblings by naming the exact analysis performed.

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

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

It tells the agent how to source the required references for both cases (Wire segments via plasticity_list_curve_directions, Solid/Sheet edges via state), which is strong usage guidance. It stops short of explicitly naming when to prefer this versus a continuous/exact analysis tool, but the context is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, and the description adds substantial context beyond them. It discloses the finite interior-grid sampling method, the signed draft formula asin(normal dot pull), and important proof limitations of the output.

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 compact sentences: purpose first, signed-draft formula second, proof limitations third. Every sentence adds useful information and there is no filler.

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

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

For a complex analysis tool with no output schema and no schema descriptions, the description supplies purpose, input concepts, classification categories, and proof caveats. It is slightly incomplete on the revision parameter and exact return structure, but sufficient for correct invocation.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It does name the pull direction, minimum draft angle, selected faces, and hints at sampling via 'finite interior grid', but it never explains the required revision parameter or the exact samplesPerDirection/default semantics, leaving gaps.

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: analyze/classify B-Rep face normals and classify faces as positive, negative, neutral, or mixed draft. It distinguishes itself from draft-editing siblings such as plasticity_draft_faces by being a read-only analysis operation.

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

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

Explains the required context: an explicit pull direction, minimum draft angle, and sampled face normals. It also gives clear limitations, stating that compact extrema do not prove continuous extrema, mold parting, release paths, or print support requirements. It lacks explicit alternative-tool routing or a named when-to-use/not-use rule.

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 cover the safety profile (readOnlyHint=true, non-destructive, closed-world), and the description still adds substantial behavioral context: which records are eligible, what distinguishes pure-mode from mixed-mode reporting, and that legacy/ambiguous records are readable but skipped. With no output schema, the description also carries the return-value burden by enumerating the reported quantities.

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?

Four sentences, all front-loaded with the eligibility condition first, then the reporting behavior, then the exclusions and scope caveats. Every sentence carries information, though the pure/mixed-mode enumeration is dense and could be slightly tightened.

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

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

No output schema exists, and the description compensates by naming exactly what is reported for each record kind, plus the eligibility gate and the negative scope caveat. Nothing an agent needs in order to decide whether to call this tool or interpret its summary is missing.

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

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

Only one parameter (recordId) with 0% schema description coverage, and the description never explains the identifier itself, its 64-hex format, or where it comes from. It does add semantic meaning about what record qualifies (complete, method-classified, load-mode-consistent), which is real value, but the parameter's own syntax and provenance remain 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?

Specific verb (summarize) plus precise resource (a stored, complete measured traction-separation curve), with an explicit precondition on the record's physical method classification. An agent can distinguish this from sibling analysis tools like plasticity_analyze_cohesive_interface or the energy-calculation tools without opening any 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?

States both when to use (physical method explicitly classified as DCB Mode I, ENF Mode II or MMB, consistent with load mode) and when not (legacy curves without an explicit fracture method remain readable but are not analyzed). It also implicitly routes away from cohesive-law calibration by declaring the output is 'not qualified cohesive-law parameters'.

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 only declare readOnlyHint=false, openWorldHint=false, and destructiveHint=false; the description adds far more, including validation rules, rejection of unstable matrices, job and layer bounds, and the fact that outputs are diagnostic only and never constitute a failure verdict or print approval. It also discloses key limitations: no delamination, nonlinear response, fatigue, buckling, or convergence prediction. This is rich behavioral context beyond the annotations and does not contradict them.

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

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

The description is extremely long, dense, and formatted as a wall of text with no headings or grouping. While the first sentence is front-loaded and many sentences carry relevant constraints, the overall length and lack of structure make it difficult to parse for an agent. It is over-specified rather than concise.

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

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

Given the 19 parameters, nested objects, 0% schema description coverage, and absence of an output schema, the description supplies a great deal of needed context, including evidence requirements, orientation semantics, layer-plan requirements, and diagnostic limitations. It is nearly complete, though it still omits explicit semantics for bodyId, revision, and meshSizeMm, and does not detail nested evidence fields. It is complete enough to use but not flawless.

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

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

With 0% schema description coverage, the description must carry the full burden, and it does so for many parameters: youngsModulusMPa, poissonRatio, orthotropicMaterial fields, couponRecordId, tsaiWuQualificationRecordId, layerPlanePlan, supportFaceIds vs supportConditions, faceLoads, loadCases, and meshRefinementSteps. However, it leaves simple top-level fields like bodyId, revision, and meshSizeMm only implicitly described, and it does not detail the nested evidence object fields. It compensates substantially but not exhaustively.

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 opening sentence states a specific verb and resource ('Run bounded linear-elastic CalculiX analyses for one selected native Solid') and constrains scope to one material and one print process. It also distinguishes itself from the separate cohesive-interface analysis, which covers delamination, and from the coupon-matching prerequisite tool. An agent can tell what this tool is for without opening the schema.

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

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

The description is explicit about when to use each mode: isotropic vs orthotropic, when to call plasticity_match_material_coupon_data first, when to supply layerPlanePlan, when to bind a Tsai-Wu qualification record, and when to use the separate cohesive-interface analysis. It also states that orthotropic analyses reject von Mises allowables and that directional limits are required for an orthotropic screen. This goes well beyond implied usage.

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

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

Annotations declare readOnlyHint=false, openWorldHint=true, destructiveHint=false. The description adds meaningful context: it writes a durable request record, contacts Codex (an external service), never mutates CAD, and never authorizes a print. This aligns with and enriches the annotations without contradiction, though it omits details like auth requirements or rate limits.

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 thousands of words long and reads like a comprehensive system prompt for the entire strength-analysis suite, not a tool definition. It is not front-loaded and every sentence after the first few is oriented toward other tools, making it severely bloated for a single tool. There is minimal structure to help an agent quickly identify the essential purpose and parameters.

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

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

The tool has six parameters, no output schema, and minimal annotation depth, so the description should clarify how to construct requests and what responses to expect. Instead, it provides a broad domain manual while leaving parameter usage, return values, and the exact structure of the 'question package' unexplained. The result is incomplete for correctly invoking this specific 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% for six parameters, including nested objects, so the description must compensate. It does not explain fields like requestId, prompt, imagePaths, evidence, answers, or context beyond vague hints such as 'Include each prior full question with its user answer' and mentions of unscaled images. The extensive text discusses engineering methods and other tools rather than the meaning or format of this tool's inputs.

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

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

The description states a specific action: 'Run one isolated Codex turn for factual extraction and the single next decision-relevant question package,' and clarifies it 'writes a durable request record, contacts Codex.' However, the name 'analyze_strength_task' suggests direct strength analysis, while the description frames it as an orchestration/request step, creating a mismatch. It also does not differentiate from siblings like plasticity_strength_request or plasticity_analyze_design_reference.

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 vast majority of the text provides routing rules for dozens of other tools, not for this tool. There is no explicit guidance on when to invoke this tool versus alternatives such as plasticity_strength_request. Usage is only implied by its role in the workflow, with no stated exclusions or prerequisites.

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

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

Annotations already declare readOnly/destructive=false, but the description adds genuinely new behavioral context: it samples at 100 discrete positions, is "native surface sampling rather than an exact continuous maximum," and "does not use the display mesh." These caveats materially affect how an agent should interpret results, though the mutation statement is somewhat redundant with 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?

Three front-loaded sentences that open with the core action, then return values, then the caveat. Dense but nearly every clause earns its place; the phrase about the document not changing is the one borderline-redundant element against the annotations.

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

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

With no output schema, the description usefully enumerates return values (G0 mm, G1 degrees, dimensionless G2, locations, hierarchical tolerance results), which is the right call. However, it leaves the non-obvious "revision" parameter and exact tolerance semantics undocumented, so an agent still lacks a complete picture for a 5-parameter 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% for 5 parameters, so the description must carry the burden but largely does not: "revision" is never explained, and the three tolerance parameters are only obliquely hinted at through "hierarchical G0/G1/G2 tolerance results." How edges/tolerances are supplied or applied is left to the schema.

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

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

The description names a specific verb and resource ("Sample Plasticity's native B-Rep continuity evaluator") and pins the exact scope ("each selected current Solid or Sheet edge shared by exactly two faces"). An agent can distinguish this surface-continuity analysis from sibling tools like plasticity_analyze_edge_curvature or plasticity_inspect_surface_structure without opening any 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?

The description implies when it applies via gating conditions ("edges shared by exactly two faces") and clarifies the sampling-vs-exact distinction, but never names an alternative tool or states an explicit "use this when / not when." Usage is inferable rather than spelled out.

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 and openWorldHint=false, covering the safety profile. The description adds scoping context ("current document revision"), which is useful, but says nothing about behavior when the id is invalid or about the returned payload, so it is only modestly additive over 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 with zero filler. For a one-parameter read tool it is appropriately sized and wastes nothing.

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

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

The tool is simple and annotations cover safety, but with no output schema and no parameter descriptions, the description leaves the agent without return-shape or error-behavior context. Adequate but with clear gaps for a body-inspection 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 parameter meaning. "Read one body" implies the single integer id identifies a body, which is a reasonable but minimal hint; it adds no format, range, or lookup guidance beyond that implication.

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?

"Read one body from the current document revision" states a specific verb (read) and resource (one body), and the singular "one body" implicitly distinguishes it from plasticity_list_bodies. However, it does not name or contrast against any sibling, so the differentiation is left to inference.

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

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

There is no explicit when-to-use guidance, no mention of alternatives like plasticity_list_bodies or plasticity_select_bodies, and no prerequisites. The agent must infer that this is for retrieving details of a single known body id.

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 openWorldHint=false, so the safety profile is covered. The description adds almost nothing beyond repeating the operation choices; it does not explain what geometry is consumed, how target/tool bodies are affected, or what keepTools/revision behavior means.

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

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

The description is a single front-loaded sentence with no filler or repetition. It is appropriately sized for a concise summary, even though it is under-specified 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 six-parameter CAD operation with no schema descriptions and no output schema, one sentence is not enough. The description omits required parameter semantics and behavioral details an agent needs to invoke it correctly.

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

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

Schema description coverage is 0% across six parameters, and the description only names the union/difference/intersection values already present in the schema enum. It provides no meaning for targetIds, toolIds, revision, keepTools, or intent.

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?

It states a specific verb ('Apply') and resource ('CAD union, difference, or intersection'), making the basic operation clear. It does not differentiate itself from sibling CAD operations beyond the boolean term, and it does not clarify the target/tool body model.

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

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

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions or exclusions. The agent must infer usage entirely from the name and operation enum.

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, openWorld=false, destructive=true, so the safety envelope is partly pre-supplied. The description still adds genuine behavioral context: source Wires are preserved, the result is a single independent native B-Spline, and the operation consumes exactly one Plasticity history step (undo scope). There is mild tension between 'preserving both source Wires' and destructiveHint=true, but creating new document geometry is a reasonable reading of that hint, so it is not a true contradiction.

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

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

Front-loaded with the core action, then constraints, then the continuity legend, then the history-step note; every sentence carries information. The prerequisite sentence interrupts the flow slightly between the action statement and the continuity explanation, which keeps it just short of ideal ordering.

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 6-parameter mutation tool with nested objects and no output schema, the description covers the geometry intent, source preservation, continuity levels, and history-step cost. Remaining gaps are the opaque revision/intent parameters and the absence of any statement about what is returned, but the critical modeling semantics are present.

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 whole burden. It partially compensates by fully defining the startContinuity/endContinuity enums (G0 position, G1 tangent, G2 curvature, G3 third-order) and by describing 'two exact current Wire segment endpoints' for the nested first/second objects, but it never explains revision, intent, the 'at: start|end' selector, or bodyId/segmentEntityId. Half the parameters remain 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?

Specific verb+resource+scope: 'Create one independent native B-Spline between two exact current Wire segment endpoints while preserving both source Wires.' An agent can distinguish this from nearby siblings such as plasticity_bridge_curve_vertices, plasticity_bridge_shell_edges, and plasticity_loft_curves because the source (Wire segment endpoints) and output (a single B-Spline) are 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?

Gives a concrete prerequisite/ordering rule: 'Use plasticity_list_curve_directions immediately before this call.' That is real usage guidance, but it does not say when NOT to bridge (e.g., crossing vs. same-body wires) nor name the closest alternative bridging tool, so it stops short of full when/when-not 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 with no readOnly, so the description usefully narrows that: it clarifies that both source Wires are preserved and that validation of internal/stale vertices happens before any mutation. That is real added context beyond the annotations, though it omits concurrency/revision behavior and what the result object is.

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 sentences, front-loaded with the core action, then prerequisites, then continuity/validation detail. No filler, though the continuity sentence crams two distinct concepts together.

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

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

With no output schema and 0% schema description coverage across 6 parameters including nested objects, the description leaves meaningful gaps: revision (likely optimistic-concurrency) semantics and the meaning of intent are undocumented, and no return value is described.

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 explain vertexId sourcing and that start/end continuity are chosen independently (G0-G3), mapping onto startContinuity/endContinuity, but bodyId, revision, and intent are left 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?

States a specific verb and resource ('Create one independent native B-Spline') with exact scope ('between two exact current open Wire vertices'), and distinguishes itself from the sibling plasticity_bridge_curves by specifying the vertex-to-vertex bridge and source-Wire preservation. An agent can select it without opening the schema.

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

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

Gives concrete workflow direction: call plasticity_list_curve_vertices immediately beforehand and pass its numeric vertexId values, plus the precondition that internal or stale vertices are rejected. It does not, however, name when to prefer a sibling such as plasticity_bridge_curves over this tool.

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

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

With destructiveHint=true already declared, the description adds real context: both source bodies are preserved, the operation is a single step, and exact endpoint/tangent read-back is required afterward. It does not explain why a body-preserving operation is flagged destructive, but it meaningfully enriches the safety picture 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?

Three dense but front-loaded sentences with no obvious filler; the core action and the reference-pairing rule come first. The jargon ('native B-Spline', 'read-back') is compact rather than padded.

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

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

For a destructive, 6-parameter mutation tool with nested objects, 0% schema coverage and no output schema, the description covers the geometry contract well but leaves revision/intent semantics and expected failure modes unexplained. Adequate minimum-viable coverage with clear remaining 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% across 6 params, so the description must compensate. It does clarify the nested reference contract ('pair a current edgeId with one of that edge's returned vertexIds') and the independent G0–G3 start/end continuity, but bodyId, revision, and intent are left entirely to the schema's types.

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

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

States a specific verb+resource ('Create one independent native B-Spline between ... endpoints of two exact current Solid or Sheet edges') and constrains the inputs to current edge/vertex references. It is largely distinguishable from the curve-oriented siblings, though it never names bridge_curves or bridge_curve_vertices directly, so an agent must infer the difference.

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: the description says the operation is a 'one-step' bridge between two edges and requires post-hoc read-back, which suggests when it applies. However, it never states when to choose this over the very similar plasticity_bridge_curves / plasticity_bridge_curve_vertices siblings, nor any exclusion or precondition beyond 'current' edges.

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 readOnlyHint=false, so the mutation nature is covered. The description adds genuinely useful context (millimeter units, pick-point-must-lie-on-edge constraint) but does not explain what geometry is consumed/created, whether the source sheets are modified, or any auth/rate concerns.

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

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

Two sentences, zero filler, and the core purpose is front-loaded before the units/constraint detail. Every sentence earns its place.

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

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

For a destructive, 6-parameter tool with nested object inputs, 0% schema coverage, and no output schema, the description is too thin. It omits revision/softness semantics and gives no sense of the resulting surface or failure modes an agent would need to call it correctly.

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

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

Schema description coverage is 0% across 6 parameters, including nested bodyId/faceId/pickPointMm objects, so the description must carry the burden. It only clarifies widthMm units and the pick-point constraint, leaving revision, softness (a key continuity parameter), intent, bodyId, and faceId 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?

The description states a specific verb (Create) and a precise resource (a native G2 transition surface between boundary sides of two Sheet faces). The G2 continuity and 'Sheet faces' qualifiers let an agent distinguish it from siblings like plasticity_bridge_curves or plasticity_bridge_shell_edges without opening the schema.

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

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

It gives a precondition ('each pick point must lie on the intended boundary edge'), which implies usage context, but never states when to choose this surface tool over alternatives such as plasticity_create_constrained_surface, plasticity_loft_faces, or plasticity_match_faces.

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 cover read-only/non-destructive, and the description adds substantial behavior beyond them: tests are not persisted, rows exceeding 0.4 displacement/crack-length ratio are rejected because large-displacement correction is unimplemented, and eligibility for interlayer fracture evidence depends on caller-confirmed interface failure. This is rich, decision-relevant disclosure.

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

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

Purpose and constraints are front-loaded, but the body is a single dense run-on paragraph packing attestations, exclusions, and rejection rules together. Given the complexity the length is mostly justified, but the lack of any structural separation makes it harder to scan than it needs to be.

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 high-complexity, 8-required-parameter tool with no output schema, nested objects, and 0% schema coverage, the description covers input expectations, eligibility rules, and the nature of the returned curve well. It could still say more about how specimens/points failures surface, but nothing critical to a correct call is missing.

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

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

Schema description coverage is 0%, so the description must carry the load, and it does: it explains the exact single-material print process, global interface normal, test method, protocol SHA-256/date, per-specimen width/length/arm thickness, ≥3 strictly increasing crack lengths, positive force, and machine-compliance-corrected displacement, plus the per-point source locator. It omits semantics for secondary fields like failureLocation enum and infill settings, preventing a 5.

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

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

The description names a specific verb and resource: 'Calculate an exploratory Mode-I G_I-versus-crack-length curve from caller-selected DCB crack-growth observations using Modified Beam Theory (MBT).' This clearly distinguishes it from the sibling MMB (mixed-mode) and ENF (Mode-II) energy calculators and from the record/match/list DCB 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?

It gives strong when-not guidance: 'This is not a standards-conformance determination,' does not produce a traction-separation curve/cohesive law/design allowable, and only marks specimens with caller-confirmed interface failure as eligible. It also states the row rejection rule (displacement/crack ratio above 0.4). It stops short of explicitly naming an alternative sibling to use instead, which would be needed for a 5.

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

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

Annotations supply readOnlyHint=true, destructiveHint=false, openWorldHint=false, so safety is already declared. The description adds substantial non-obvious context: the exact fit form C = A + m*a^3, the G_IIc formula, that fit R-squared and sources are retained, that only layer-interface failures are eligible, and the explicit scope carve-out for ASTM D7905 and R-curves. This goes well 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?

The description is one long sentence followed by another dense sentence of disqualifiers and a third sentence of scope caveats. It is front-loaded with the core action, which is good, but the run-on sentence style and repeated hedging ('exploratory', 'not a design allowable or Creality material property') reduce readability without adding new operational detail.

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

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

Given a 9-parameter nested schema, no output schema, and no annotation detail beyond read-only, the description is largely complete: it explains inputs, the computation, what is retained, what is out of scope, and what the result is not. No output schema exists, so it does not need to describe returns, but it could more explicitly state the output is a scalar energy estimate. The current text implies it but doesn't state it plainly.

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 all parameter meaning. It does: it explains which specimen fields are required, what the compliance values represent (inverse initial-linear slope), the required numeric vectors (interface normal and perpendicular global shear), the protocol hash/date, and per-input source hash/locator. It stops short of mapping every schema field (e.g., orientationDeg, wallLoops), but the critical inputs are covered.

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

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

The description opens with a precise verb+resource+scope: 'Calculate an exploratory ENF Mode-II initiation energy from caller-supplied compliance-calibration results.' This clearly distinguishes it from siblings such as calculate_mmb_mode_i_ii_energy, calculate_dcb_mode_i_energy, and record/read/import ENF variants, which handle different test modes or different stages in the workflow.

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 lays out the prerequisites for calling the tool (at least three crack lengths/compliances, same fixture, measured crack and peak force, global normal/shear vectors, protocol hash/date, source hashes and locators, attestations). It also gives exclusions ('does not interpret raw machine traces, correct compliance, determine ASTM validity'). It doesn't point to a sibling for the preceding steps (e.g., import_enf_mode_ii_energy_csv), but the when/when-not is otherwise clear.

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

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

Annotations declare readOnlyHint=false with destructiveHint=false, so the agent already knows this writes state without destroying anything. The description confirms persistence ('persist a screening scenario') and adds the traceability requirement for inputs, but says nothing about permissions, idempotency, or what happens to previously stored scenarios.

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

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

Two densely packed sentences with no filler; the action and the mode set are front-loaded and the input-traceability constraint follows. Slightly terse for a 10-parameter tool, but nothing is wasted.

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

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

For a 10-parameter required-only tool with nested objects, zero schema descriptions, and no output schema, the description omits too much: the role of evidence entries, assumptions, assignments, goal, method/kind constants, and safetyFactor semantics are all unexplained. The two sentences cover the mechanical intent but leave an agent guessing at how to populate most of the payload.

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 real weight: it names effective areas, plane count, plane location, loads, and material limits, mapping to tensileStressAreaMm2/shearAreaPerPlaneMm2, shearPlaneCount, shearPlaneLocation, loads, and material limits. However, 10 required top-level parameters exist and goal, kind, method, evidence, assignments, assumptions, and safetyFactor get no explanation of their expected content or structure.

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 pair (calculate and persist) and a clear resource (a screening scenario for one fastener in axial tension, direct shear, and NASA combined tension-shear interaction). It is distinguishable from the many verify_* siblings by the word 'persist' and the explicit three-mode scope, though it never names an alternative directly.

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 guidance, and no routing to siblings such as plasticity_verify_single_fastener_strength, plasticity_calculate_single_fastener_strength, or plasticity_calculate_threaded_receiver_strength. The scenario framing implies a usage context but the agent must infer 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?

Annotations already convey readOnly=false, destructive=false, and openWorld=false, so the agent knows this writes state without destroying anything; the description's 'persist' is consistent with that. It adds only marginal nuance ('independent' modes, simultaneous modes conditional) and says nothing about what record is persisted, idempotency, or failure 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?

Two sentences, front-loaded with the purpose and scope, with no filler. Dense but appropriately sized for a short description, though the second sentence is terse to the point of ambiguity ('remain conditional' on what?).

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

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

For a 10-parameter, deeply nested, mutation-style tool with no output schema and 0% schema coverage, this description is far too thin. It omits what gets persisted, expected return/result shape, parameter-level meaning, and prerequisite/evidence requirements, leaving the agent to infer most invocation semantics.

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

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

Schema description coverage is 0% across 10 required nested parameters, so the description must carry the burden and does not. The phrase 'insert, host, print, pocket, and installation process' loosely maps to some configuration fields but leaves goal, kind, method, demands, capacity, evidence, assignments, assumptions, and safetyFactor 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 verb pair (calculate and persist) and resource (pullout and torque-out screening for one installed heat-set insert), which an agent can distinguish from siblings like calculate_threaded_receiver_strength. It does not name the sibling it should be preferred over, but the scope is clear enough to route correctly.

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 asserts a precondition ('Qualification capacities must match the insert, host, print, pocket, and installation process') and notes a conditional case ('simultaneous modes remain conditional'), but gives no when-to-use vs alternative guidance relative to the many verify_*/calculate_* siblings. There is no explicit trigger or exclusion.

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 only cover the safety profile (readOnly, not open-world, non-destructive); the description adds substantial behavioral context: per-specimen failure location and hashed locator are preserved, only interface failures feed the summary, other failures stay visible but excluded, and no interface failures yields nulls. It also preempts misinterpretation by stating these are not tractions, allowables, qualified bounds, or a cohesive law.

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

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

Front-loaded with the computational definition, then the inclusion/exclusion rule, then the scope caveats. Dense but each clause carries information; the final negation sentence is long yet earns its place as a guardrail.

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

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

Despite no output schema, the description discloses the returned quantities (range, mean, sample standard deviation, per-specimen visibility, null summaries), so an agent understands both inputs and outputs. Complete enough for a read-only calculation 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% with a single nested specimens array. The description clarifies that peakForceN and netCrossSectionMm2 drive the ratio and that failureLocation/sourceHash/sourceLocator are carried through, giving real meaning, but it does not document each field's contraints or the enum semantics.

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

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

States a specific verb (calculate) and resource (nominal peak stress per directly loaded physical specimen) and even gives the governing formula N/mm² = MPa. It is highly specific about the interface-specimen scope, though it never explicitly names a sibling to contrast with.

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

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

It defines the domain conditions under which the tool applies (specimens failing at the printed interface) and what is excluded, but offers no explicit when-to-use-vs-alternative routing among the many strength/interface siblings. Usage is implied rather than directed.

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 only declare read-only/non-destructive; the description adds substantial behavioural context: required source hashes/locators, an explicitly confirmed axis mapping, a confirmed lever-weight condition, the Reeder-Crews beam-theory basis, and the returned quantities (Mode-I, Mode-II, total ERR and Mode-II fraction).

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

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

Front-loaded with the core purpose and scope, then requirements, then exclusions; every sentence carries information. It is densely packed into long clauses, which slightly hurts readability but not substance.

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 11-parameter, no-output-schema, read-only calculation tool, the description fully covers inputs expected, preconditions, computation method, and returned values, leaving nothing essential for correct invocation unstated.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning; it does well, naming materialProcess, interface normal/shear direction, source hashes and locators, flexural modulus, orthotropic E11/E22/G13, axes mapping, and lever weight. It leaves testProtocolHash, testMethod, testedAt and the individual specimen sub-fields (width, span, lever arm, crack length, criterion) only implicitly covered.

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 ('Calculate an exploratory mixed-mode initiation-energy partition') plus the exact inputs (MMB critical force, crack length, specimen/fixture geometry, one-material process, interface normal and shear direction). It is immediately distinguishable from the DCB Mode-I, ENF Mode-II, and cohesive-FEA 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?

Explicitly scopes what the tool is not for ('does not select initiation from raw test traces, establish ASTM D6671 conformity, infer a traction-separation law, qualify material, or authorize design/printing') and positions it against the measured-curve registry and cohesive FEA. It also states eligibility ('Only confirmed interface failures are eligible').

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 (readOnlyHint=false, destructiveHint=false, openWorldHint=false) indicate a non-destructive write. The description adds genuinely new behavioral context beyond annotations: raw coupon strengths are never mapped to allowables, and no-match or ambiguity returns without saving. That failure-mode persistence behavior is not derivable from the annotations or 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?

Four tight sentences that front-load the verb and the required coupon-data dependency. Dense but each sentence carries distinct semantics; no filler or repetition.

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

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

There is no output schema, so the description should ideally convey what a successful calculation produces or persists. It notes the no-save-on-failure case but never describes the successful result format, and the heavily nested input is only partially addressed. Adequate but with a clear gap for a tool of this complexity.

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

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

Schema coverage is 0% with five nested top-level parameters, so the description carries a heavier burden. It clarifies semantics for allowables (tensile, and compressive for cantilevers, must be separately evidenced) and constrains the allowablesBasis intent, but leaves process, scenario, and effectiveSection structurally 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?

Clearly states a specific verb (calculate) and resource (rectangular axial-tension or cantilever strength derived from coupon data). It is distinguishable from the tongue-root and generic calculate_strength siblings, though the exact 'rectangular' object of analysis is implied via the name rather than spelled out in the description.

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

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

The description implies the prerequisite context (an exact printer/material/profile/orientation coupon record and separately evidenced allowables), which is useful usage guidance. However it never explicitly names when to prefer this over siblings like plasticity_calculate_strength or plasticity_calculate_tongue_root_strength_from_coupon_data, so selection still requires inference.

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

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

With annotations only declaring write/not-destructive/not-open-world, the description adds genuine behavioral context: it says the operation persists state and that caller geometry 'remains unverified' while any CAD binding is 'removed'. That is useful, non-obvious disclosure about side effects. It stops short of explaining validation failure modes or what persistence implies for later reads.

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, front-loaded sentences with no filler; the primary action leads and the side-effect caveat follows. Efficient given the space allotted, though it could have spent a sentence on parameter guidance instead.

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 14-parameter, nested, write operation with no output schema and no per-parameter help, the description is far too thin. It covers only two behavioral facts and leaves the agent with no guidance on the elaborate input contract, which is the tool's main source of invocation error.

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 14 parameters (12 required, deeply nested), and the description adds nothing about any of them. An agent gets no explanation of how to supply geometry, evidence, material, or assignments. This is a severe compensation failure.

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 verb ('calculate and persist') and a defined resource ('a labelled planar-section scenario'), which distinguishes it from siblings like plasticity_inspect_planar_section (read-only inspection) and plasticity_verify_section_strength. It does not, however, explicitly name or contrast any sibling, leaving the 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?

There is no statement of when to use this tool versus the many section-strength siblings (verify_section_strength, scan_section_strength, inspect_planar_section, calculate_strength). Usage is only implied by the word 'calculate'; no prerequisites, alternatives, or exclusion conditions 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 the write/read profile (readOnlyHint=false, destructiveHint=false), and 'persist' is consistent with that. The description adds one genuine behavioral fact beyond the annotations: that caller CAD bindings are removed, i.e. the operation does not retain the binding. However this is vague (removed from where, and is it recoverable?) and nothing is said about auth, rate, or what gets written.

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, zero filler, and the scope/behavior split is front-loaded with the calculation targets first. Appropriately tight, though for an 11-parameter nested schema the terseness edges toward under-specification rather than elegance.

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 11 required nested parameters, 0% schema coverage, no output schema, and heavy sibling overlap, the description is far too thin — an agent learns the arithmetic result it computes but nothing about the required inputs (kind/method constants, binding tokens, evidence, safetyFactor) or what is persisted.

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 11 parameters (10 required, deeply nested: binding, geometry, material/manufacturing, evidence, assumptions). The description names no parameter, no unit convention, and no required-vs-optional distinction, so it compensates for none of the coverage gap.

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

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

The description gives a specific verb pair (calculate and persist) plus three named failure modes (bearing, loaded-edge shear-out, net-section tension) and scopes to one through fastener. That is clear and evidence-rich, but it never distinguishes this tool from the very similar sibling plasticity_verify_single_fastener_strength, so the agent is left to infer the difference.

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 versus the many adjacent strength tools (verify_single_fastener_strength, calculate_fastener_member_strength, inspect_single_fastener_plate). No prerequisites, no exclusions, no triggering context beyond the implied 'you have a single-fastener plate problem'.

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, openWorldHint=false, aligning with 'persist'. The description adds real behavioral content beyond the annotations: the scenario is persisted, and a supplied CAD binding 'is not treated as verified geometry' — an important caveat about how that input is trusted. It does not explain permissions, replay, or side effects of persistence.

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

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

Two tightly written sentences with no filler, and the persist-then-binding-caveat ordering is sensible. Brevity is appropriate, though the second sentence earns its place more than the first's vague phrasing.

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 16-parameter tool with deeply nested objects, a method enum, 6 required fields, and no output schema, two sentences are far too thin. The agent gets no orientation on how method, material, evidence, assignments, and assumptions relate or what the result represents.

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 16 parameters (method enum with 4 formulas, nested evidence/material/assumptions structures, dimensions), yet the description explains almost none of them. It only gestures at 'caller-supplied dimensions' and the binding caveat, leaving the 6 required params and the method selection 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 verb (calculate and persist) and a resource, but 'a labelled scenario' is vague jargon that doesn't clearly say it runs a strength/member calculation. It does partially distinguish itself from the many verify_* siblings by the calculate+persist framing, but an agent can't confidently tell what it produces.

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 use this versus the numerous verify_*/calculate_* strength siblings, nor any prerequisite or triggering condition. The reader 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?

Annotations already declare a write operation (readOnlyHint=false) with destructiveHint=false, and 'persist' is consistent with that. The description adds a genuine behavioral constraint (explicit inputs required, nominal size insufficient) beyond the annotations, but says nothing about failure modes, error behavior, or what gets written.

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

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

Two sentences, no filler, and the core action is front-loaded. The second sentence is dense but each clause adds real constraint information, so little is wasted.

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

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

For a high-complexity tool with 11 required, nested, entirely undocumented parameters and no output schema, the description covers only part of the surface. The roles of method, criteria, safetyFactor, assignments, and assumptions — all required — are never addressed, leaving an agent to guess at the contract.

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 11 required parameters, so the description must carry the burden. It names and semantically clusters five of them in prose (three allowable loads, engagement, complete thread count, load, evidence), but leaves goal, method, criteria, safetyFactor, assignments, and assumptions 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?

The description states a specific verb pair (calculate and persist), a specific resource (axial stripping and tensile-failure checks), and a tightly bounded scope (one tapped hole, nut, or threaded insert). This distinguishes it from the many sibling strength/verify tools without needing to open the schema.

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

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

It gives a strong precondition ('all three allowable loads, engagement, fully formed thread count, load, and evidence must be explicit; nominal M size alone never supplies capacity') that implies when the tool is appropriate. However, it never names an alternative tool or explicitly states when-not to use it, so routing against siblings like plasticity_verify_single_fastener_strength is left to inference.

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

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

Annotations establish non-read-only and non-destructive behavior, and the description adds important context by saying it persists results and produces only a root-level screening result that never validates the complete joint. It still does not describe what a persisted result contains, permissions required, or side effects beyond persistence, but it goes 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?

It is three compact sentences, front-loaded with the core action and scope, then requirements, then the key limitation. Every sentence carries information, though the middle sentence is dense and could be easier to scan with structure.

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

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

For a complex calculation tool with 13 parameters, nested inputs, no output schema, and only basic annotations, the description is only a high-level overview. It says what the tool is for and lists broad input categories, but it leaves many required input structures unexplained and gives no sense of the result format or persisted output.

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

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

Schema description coverage is 0% for a 13-parameter, deeply nested input, so the description carries the full burden. It mentions geometry, load, orientation-matched material properties, allowables, shear correction factor, safety factor, and deflection limit, but it omits many parameters such as kind, goal, method, evidence, assignments, assumptions, and binding. The added meaning is useful but insufficient to compensate for the coverage gap.

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

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

The description gives a specific verb (calculate and persist) and a precise resource (a root-only screening scenario for a rectangular tongue under transverse point load). It also distinguishes the scope from a complete tongue-and-groove joint validation, but it does not explicitly name or differentiate from sibling tools such as verify_tongue_root_strength or calculate_tongue_root_strength_from_coupon_data.

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

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

The phrase 'root-only screening scenario' and 'A result never validates the complete tongue-and-groove joint' imply when the tool is appropriate and when it is not. However, no alternative sibling tool is named, so the agent must infer whether to use this calculation, the verification tool, or the coupon-data variant.

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, openWorldHint=false, and the description adds real context: a match saves a calculation while a no-match/ambiguity aborts without saving, material suitability stays unconfirmed, and the tool cannot emit a pass. That aligns with and enriches the write-permitting annotation. It stops short of describing persistence side effects or auth/permission requirements.

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

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

Three sentences, front-loaded with the core action and followed by prerequisite and failure semantics. The first sentence is long and dense, but every sentence earns its place and nothing is redundant.

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

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

For a high-complexity calculation tool with a large nested schema and no output schema, the description covers the workflow and failure behavior but leaves much of the input contract (scenario fields, effectiveSection meaning) and any notion of the returned/saved artifact unexplained. Adequate but with clear gaps.

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

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

Schema description coverage is 0% and the schema is deeply nested, so the description carries the burden. It usefully enumerates the coupon-matching keys (printer/material/profile hash/orientation/infill percent and pattern/wall loops/top-bottom shell layers/temperature) and the allowables requirement, which partially compensates. But the entire scenario sub-tree (binding, evidence, geometry, loads, assignments, assumptions, safety factors) and the effectiveSection enum are undocumented.

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

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

The description states a specific verb+resource: resolve an exact physical coupon record by a well-enumerated key set, copy measured Young's/shear moduli, and calculate a labelled tongue-root scenario. This is far more specific than the bare name. However, it does not explicitly distinguish itself from siblings like plasticity_calculate_tongue_root_strength (non-coupon) or plasticity_verify_tongue_root_strength_from_coupon_data, so the 'from_coupon_data' variant boundary is left implicit.

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

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

Usage is implied rather than stated: the tool requires an exact coupon match and externally supplied tensile/shear allowables with an independent basis. The failure condition ('no-match or ambiguity returns without saving') is a useful guard, but no alternative sibling is named and no explicit 'use this instead of X when Y' guidance is 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 only declare it a safe read (readOnlyHint=true, no writes/open-world), but the description adds substantial behavioral context beyond that: rejection rules, the exact-setup/interface-normal consistency checks, the returned quantities (peak tractions and per-MMB residuals), and an explicit list of non-capabilities (does not identify K, qualify the law, authorize FEA, establish allowables, or approve a part). This is rich disclosure that goes well past the annotations and is internally consistent with them (a computation that returns results for review, not a persisted write).

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

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

The purpose is front-loaded in the opening clause before any constraints, and each subsequent sentence (format rule, rejection conditions, return values, non-capabilities) earns its place. It is dense and jargon-heavy, but not 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?

There is no output schema, so the description appropriately explains what is returned (pure-mode peak tractions and per-MMB energy residuals). Combined with the input preconditions and the explicit non-capabilities, an agent has everything needed to decide to call it and interpret its scope.

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 meaning, and it does: modeIRecordId maps to the DCB record, modeIIRecordId to the ENF record, and mixedModeRecordIds to 'at least two distinct-ratio MMB' records, matching the minItems=2 constraint. It does not restate the 64-hex-hash format (which the schema pattern already enforces), but the semantic role of each parameter is well conveyed.

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 precise verb and artifact: 'Fit a candidate Code_Aster CZM_TURON ETA_BK' from specific measured test records. This is unmistakably distinct from sibling tools like plasticity_calculate_mmb_mode_i_ii_energy (computes energy) or plasticity_analyze_cohesive_interface, and the scope constraints (same-material printed-layer interface, single process) further sharpen its identity.

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

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

It gives strong when-to-use/when-not conditions: requires immutable measured DCB, ENF and at least two distinct-ratio MMB records, and rejects different-material bond tests, missing curves, non-interface failure, conflicting setups and mismatched processes/normals. The one gap is that it never names an alternative tool to reach for when these preconditions fail.

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 openWorldHint=true, and the description complements this by clarifying the catalog is 'bounded', only registered MCP operations are callable, the selected operation's original Zod schema and safety checks are applied, and it is 'not JavaScript execution'. That last point usefully closes off a plausible misinterpretation, though it does not describe what an invocation 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?

Three tightly packed sentences with the core operation stated first, then the two usage modes, then the safety framing. No filler, no restatement of the title.

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 dispatcher with a nested free-form 'arguments' object, no output schema, and 0% schema description coverage, the description covers the essential contract: how to browse, how to invoke, and that safety checks are enforced. It could still say what a successful invocation returns or how an invalid toolName is reported.

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, and it maps the parameters well: toolName selects 'catalog' or an operation name, query/offset/limit drive catalog browsing, and arguments is the target operation's argument object. It adds real meaning over bare type declarations, though limit/offset pagination semantics are only implied by the schema defaults.

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

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

The description states a specific verb+resource pair: 'Browse the bounded catalog of registered Plasticity MCP operations or invoke one by its exact tool name.' This cleanly separates the dispatcher role from every sibling in the list, which are the individual operations it would dispatch to.

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

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

It gives concrete usage mechanics: use toolName='catalog' with query/offset/limit to read schemas, then set toolName to a returned operation name and pass its arguments. What is missing is guidance on when to route through this dispatcher versus calling a sibling tool (e.g. plasticity_create_circle) directly, which is the primary decision an agent faces.

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, openWorldHint=false, so safety is covered. The description adds genuinely useful behavior beyond that: a 100-item default page size, case-insensitive matching, the returned total/matching counts and nextOffset, and the rationale that pagination exists to avoid flooding MCP context. It stops short of noting rate limits or ordering guarantees.

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 compact sentences that are front-loaded with the purpose before the paging/filter details. Every clause earns its place, though the single second sentence stacks four facts and could be marginally clearer if split.

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

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

With no output schema, the description helpfully states the return shape (total and matching counts plus nextOffset). All parameters are optional and the safe-read profile is covered by annotations. A brief note on result ordering or what a binding entry looks like would make it 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 description coverage is 0%, so the description must carry the parameter burden. It explains limit (defaults to 100 per page) and query (case-insensitive substring), but offset is only implied through the returned nextOffset rather than being described as an input control, and the 250/200 bounds aren't mentioned. Partial compensation 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 (page through) and resource (native renderer bindings in Plasticity 26.1.3), and the version anchor makes the scope concrete. It clearly distinguishes itself from the CAD-modeling siblings, though it never explicitly names a counterpart. The purpose is only slightly fuzzy because an agent may not know why it would want renderer bindings.

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

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

The description explains the mechanics of paging and substring filtering, which implies the usage (browse/discover bindings in a controlled way). It does not state when to reach for this tool versus e.g. plasticity_call or plasticity_status, and no alternative is named. Implied usage only.

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 readOnlyHint=false, so the mutation/safety profile is covered. The description adds useful context ('native Sheet bodies' only, 'one history step' for undo granularity) but omits whether new faces replace or add geometry and what the result state looks like. Modest value 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 efficient sentence with the key scope constraint front-loaded. No wasted words, though it is terse enough to leave gaps rather than being a model of completeness.

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

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

For a mutation tool with no output schema and 0% schema coverage, the description gives the operation but not the required 'revision' token handling, the optional 'intent', or the return state. Annotations cover safety, so it is not dangerously incomplete, but a caller lacks enough to invoke confidently.

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

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

Schema description coverage is 0% for 3 parameters. The phrase 'one or more native Sheet bodies' partially maps to the ids parameter, but 'revision' (required) and 'intent' are entirely undocumented in both schema and description. The description 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 ('Cap'), resource ('planar open boundaries of native Sheet bodies'), and scope ('every ... in one or more'). An agent understands the intended operation. However, it does not name or contrast with the close sibling plasticity_patch_sheet_hole, so the differentiator must be inferred.

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 or exclusion. The description implies capping is for open boundaries, but it never says when to prefer this over plasticity_patch_sheet_hole, plasticity_patch_regions, or plasticity_extend_sheet_edges. The choice is left entirely 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 already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, and the description does not contradict them — the snapshot is an in-memory baseline read of the scene, not a mutation. It adds real value by describing the payload scope ('returns only the snapshot ID, document/revision identity and object counts'), which compensates for the absent 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?

Two tightly written sentences, with the action and its purpose front-loaded and the follow-up usage trailing. 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?

With no output schema, the description usefully summarizes what is returned, and annotations cover the safety profile, so an agent has what it needs to call and chain the tool. The only gap is the undocumented 'label' parameter, a minor omission for a 0-required-parameter tool.

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

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

The single optional 'label' parameter has 0% schema description coverage and is never mentioned in the description, so no semantics are added. Impact is limited because the parameter is optional and self-explanatory, which keeps this at the minimum-viable baseline rather than lower.

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?

Specific verb+resource ('Capture an in-memory scene baseline') with an explicit scope and timing condition ('before manual edits'). It also names the downstream consumers (plasticity_changes_since, plasticity_wait_for_change), so an agent immediately understands this tool's role in the workflow.

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?

'before manual edits' states the intended moment to call it, and the second sentence tells the agent what to do with the returned ID, effectively routing to the two companion tools. There is no explicit when-not-to-use or statement of alternatives to this specific tool, but the workflow context is clear.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=false, so the safety profile is covered. The description adds only that the chamfer is uniform ('equal distance'), and says nothing about whether the operation is revertible, how revision conflicts are handled, or what happens to the original edge geometry.

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 verb, resource, and magnitude; nothing is wasted. It is arguably too short rather than too long, but the structure itself is clean.

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?

A destructive mutation tool with 5 parameters at 0% schema coverage and no output schema needs more than one sentence. An agent cannot tell what revision means, what intent does, or what a successful result looks like, so the definition is under-specified for the tool's complexity.

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

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

Schema description coverage is 0% across 5 parameters, so the description must compensate and largely fails. It implies distanceMm and edgeIds but leaves id, intent, and especially revision (a required string with no explanation of its purpose or conflict semantics) entirely undocumented.

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

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

States a specific modeling verb (Chamfer) against a specific resource (edge IDs) with a defined magnitude (equal distance in mm). The phrase 'current edge IDs' is slightly awkward, and it does not distinguish chamfering from the sibling operations plasticity_fillet / plasticity_refillet_faces, but the core action is identifiable without opening the schema.

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

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

No indication of when to chamfer versus fillet, no prerequisite that the edges exist or that a revision/ID must be current, and no mention of the destructive nature relative to alternatives. The only implicit guidance is that edge IDs must already exist.

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 and destructiveHint=false, so safety is covered; the description goes further by disclosing pagination mechanics (bodyOffset default 0, bodyLimit default 20, max 100), the optimistic-revision contract, and the subtle sceneChanged vs revisionChanged distinction. That is real behavioral context an agent could not infer from the 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?

Dense but front-loaded: the core purpose leads, then pagination instructions, then the companion tool, then the reporting caveat. Every sentence carries information, though the enumeration of diffed categories is long.

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

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

With no output schema, the description does the work of describing the return payload (changed-body B-Rep descriptors plus regions, planes, materials, visibility, instances, groups, selection), which is substantial. Remaining gap is minor: no error/expiry behavior and only implicit explanation of how the baseline snapshot is identified.

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 for three of four: bodyOffset/bodyLimit defaults and maximum, and expectedRevision tied to current.revision. snapshotId is only implicitly described as the 'captured scene baseline', leaving its exact format/relationship to capture_snapshot unstated.

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 ('Return a structured diff from a captured scene baseline') and enumerates the diffed categories, so an agent can distinguish it from sibling inspection tools. It also explicitly routes topology-level detail to plasticity_body_info rather than leaving the boundary implicit.

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

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

Gives concrete operating guidance: follow bodyPagination.nextOffset with expectedRevision set to current.revision, and use plasticity_body_info for detailed topology of selected bodies. It also tells the agent to check sceneChanged for a reportable edit. It stops short of stating explicit when-not conditions or the snapshot prerequisites.

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

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

Annotations already declare readOnlyHint and destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond that: the metrics returned, the requirement that a 'recorded basis' be supplied for an explicit pass, and the explicit limitation that this is a layout check rather than strength or tool-motion analysis.

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

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

Front-loaded with purpose and then returns in the second sentence, with the conditional-pass rule and scope disclaimer after. Four dense sentences, each adding information; no filler or restatement of the title.

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

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

With no output schema and 7 parameters at 0% schema description coverage, the description compensates reasonably by describing the returned distances/clearances and pass conditions. But it leaves several required parameters (bodyId, frame, revision, cylindricalFaceIds) unexplained and gives no return shape, so an agent still faces 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 load, and it covers only part of it: opposedFaceId, the requirements/basis gating, and the envelope concept (head, washer, nut, driver). It says nothing about bodyId, revision, frame, boundaryFaceId semantics, or cylindricalFaceIds, leaving several required parameters unintroduced.

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 ('Measure and optionally check a fastener group on one exact rectangular planar face') and closes by scoping itself out of strength and tool-motion analysis, which distinguishes it from siblings like verify_fastener_group_load and calculate_fastener_member_strength. Clear enough to select without opening the schema, though it never names a direct alternative.

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

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

The description gives conditional guidance for parameters ('Optionally provide opposedFaceId to verify...', 'A pass is returned only when explicit layout requirements with a recorded basis are supplied'), which tells the agent when a pass verdict is meaningful. However it never states when to prefer this tool over inspect_fastener_group or the verify_* siblings, so tool selection remains 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 readOnlyHint/openWorldHint=false/destructiveHint=false, so safety is covered. The description adds genuine behavioral context beyond them: it is deterministic, it treats every layer/envelope/engagement/tip-clearance/datum value as a caller-supplied explicit input (no implicit defaults assumed), and it enumerates what the result explicitly does NOT assert. That is useful disclosure, though it says nothing about failure modes or result shape.

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

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

Three sentences, front-loaded with the core action and followed by the input-policy and boundary clauses. Every sentence carries information, though the second sentence is dense and slightly awkwardly phrased ('remain explicit inputs'), keeping it just short of a clean 5.

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

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

For a tool with a 5-parameter schema including a two-branch oneOf receiver, 4 required params, and no output schema, the description is thin: it correctly avoids explaining return values but does not clarify the designation input format or how nut vs threaded receivers change required inputs. The stated scope boundary is the main thing keeping it at minimum-viable.

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

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

Schema description coverage is 0%, so the description must compensate, and it partially does: 'clamped stack' maps to gripItems, 'nut/washer envelope, engagement, tip clearance' maps to the nut/threaded receiver variant fields, and 'under-head versus overall length datum' maps to lengthMeasurement. It still leaves the designation string format and the broader receiver oneOf branches undocumented, so coverage remains incomplete.

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 ('Check whether the nominal length ... fits an explicit clamped stack') with a precise scope (ISO metric screw/bolt designation, nut or threaded receiver). The closing negative clause ('does not claim strength, preload, access, fit, or thread-stripping capacity') cleanly separates it from the many strength-verification siblings without needing to name them.

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

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

Usage is implied rather than stated: the phrase 'explicit inputs' and the deterministic scope note tell the agent this is a pure length/fit check, and the negative clause hints at when-not (anything strength-related). However, it never explicitly names alternatives like measure_fastener_grip_stack or resolve_fastener_designation, nor the condition selecting them, so guidance stays at implied level.

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, and openWorldHint=false, so the safety profile is covered. The description adds valuable behavioral detail: it operates on native B-Rep clones in a temporary database, does not affect the document or Undo history, and clarifies that a negative result does not distinguish touching from separation.

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 three sentences are tightly structured: purpose first, behavior second, and result limitation third. Every sentence adds useful information without redundancy.

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

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

For a read-only check operation with annotations covering safety and no output schema, the description gives strong behavioral context and clearly bounds the meaning of results. It remains incomplete on parameter semantics, especially the revision input and pair identifier format.

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

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

Schema description coverage is 0% for two required parameters. The description mentions 'pairs' and 'current Solid bodies,' which somewhat maps to the pairs parameter, but it provides no explanation of body ID semantics, pair structure, maximum pair count, or the required revision parameter.

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

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

The description names a specific verb and resource: checking explicit pairs of current Solid bodies for exact volumetric interference. It also distinguishes this from adjacent measurement concepts by explicitly stating it is not a minimum-clearance measurement.

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

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

It clearly implies usage for exact volumetric interference and explicitly excludes minimum-clearance interpretation, giving useful context for selecting the tool. However, it does not name sibling alternatives or provide explicit when-not conditions beyond the clearance caveat.

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 cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=false), so the bar is lower. The description adds real context beyond them: it performs a staleness/consistency check against current evidence, returns a 'raw solver response with mesh-screening diagnostics', and explicitly disclaims that it 'never establishes strength or print approval'. That last point is a meaningful guardrail for downstream reasoning.

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, then the caveat about what the output is not. The enumeration of verified record types is dense but each item carries substantive meaning. No filler, though the sentence is long.

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

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

No output schema exists, so the description carries the burden of describing what is returned, and it does: a matching-status determination plus raw solver output with mesh-screening diagnostics and an explicit non-certification caveat. Annotations cover the read-only safety profile. It is complete enough to call correctly; only ID provenance is thin.

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 a single required parameter at 0% schema description coverage. The description only says 'by ID', which maps to reportId but adds nothing about format, sourcing, or how a valid ID is obtained. The schema supplies the UUID format/pattern, but the description 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 and resource: 'Read a persisted cohesive-interface solver report by ID'. It also describes the salient output behavior (reporting whether saved records still match current evidence), which is more than a restatement of the name. It does not explicitly name how it differs from the similarly-named sibling plasticity_static_fem_report, so it stops short of full sibling differentiation.

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

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

Usage is only implied: an agent can infer this is for retrieving an already-persisted cohesive report when it has an ID. There is no explicit statement of when to use this versus plasticity_static_fem_report, plasticity_analyze_cohesive_interface, or the comparison report tool, and no prerequisites or exclusions are given.

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

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

Annotations only declare a non-destructive write in a closed world; the description adds substantive semantics beyond that: it never averages or infers values, only non-conflicting properties are merged, conflicts cause rejection, and the output is a new immutable record carrying composedFromRecordIds. These are behavior rules an agent could not infer from the schema or 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?

Dense but front-loaded, leading with the action and its scope before the specimenCount instruction and the outcome. Five sentences is close to the useful maximum; a sentence explaining FEA/exact-process reuse is informative but the most expendable.

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

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

With no output schema, the description still states the return value (a new immutable record with composedFromRecordIds) and the usable downstream purposes. Combined with the rejection rules and the specimenCount explanation, nothing essential for a correct call is missing.

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

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

Schema description coverage is 0%, so the description must carry the load: it explains that specimenCount is the caller-confirmed count of unique physical specimens across all source records, which the schema only types as an integer. It also conveys that recordIds is a set of 2–8 coupon identifiers to be merged, though it leaves the id format to the schema pattern.

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

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

Names a specific verb+resource ('consolidate ... coupon records') and pins the scope with hard constraints: 2–8 records, one exact single-material print process. This is clearly distinguishable from sibling operations such as match_/list_/record_material_coupon_data, which do not merge records.

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

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

Gives explicit preconditions for use (compatible immutable coupon records, single material, single print process) and names rejection cases (different processes, conflicting values, differing print frames). It does not explicitly route the agent to an alternative sibling when those preconditions fail, so it stops short of a 5.

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

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

Goes well beyond the readOnly/non-destructive annotations: it discloses the merge rule, the two conditional screen outputs and their preconditions, the homogeneous-continuum assumption (no layer interfaces, delamination or mixed-material joints), and explicit limits ('diagnostic only, not convergence estimates, strength verdicts or print approval'). This is unusually rich behavioral disclosure.

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

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

Dense but front-loaded, leading with purpose before the merge mechanics and caveats. Most sentences carry distinct load-bearing detail, though the allowable-screen paragraph is long and could be tightened.

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

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

With no output schema, the description still explains what comes back: sampled stress/displacement trends across combined levels, plus either the raw peak screen or the componentwise maximum-stress screen, and separately reported CAD/material evidence freshness. Nothing an agent needs to invoke or interpret the result is missing.

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

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

Only one parameter, reportIds, and the schema carries no descriptions (0% coverage). The description compensates by stating the 2–4 cardinality and that inputs must be saved reports from one CAD revision, but it never explains the ID format (36-char UUID pattern) that the schema enforces silently.

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?

Opens with a precise verb+resource+cardinality: 'Compare 2–4 saved static FEA reports from the same CAD revision...'. It enumerates the matching dimensions (body, supports, loads, material evidence, native geometry) and distinguishes itself from report-producing siblings like plasticity_static_fem_report by being explicitly a comparison/merge tool.

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

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

States the prerequisites for valid use (same CAD revision, body, supports, loads, material evidence and native geometry) and what merging requires (byte-identical mesh hashes with matching solver results). It does not name an alternative tool or say when not to use this one, so it falls short of explicit 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 already declare destructiveHint=true and openWorldHint=false, so the safety profile is partly covered. The description adds that the initial scene summary is compact and that body bounds/counts are paginated, but never explains what 'connect' does to any existing connection/lifecycle state — which the destructive hint implies matters.

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 primary action and its result, then the sibling routing. Nothing 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?

No output schema exists, and the description does supply a return summary and a pagination caveat. But for a connection-establishing tool with a required, undocumented parameter, it omits the target identifier format and any connection lifecycle/replacement behavior.

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

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

Schema description coverage is 0% for the single required targetId. The phrase 'one explicit Plasticity window' implies targetId identifies a window, which is some added meaning, but the accepted format (id vs name) and the 'one window at a time' constraint are left unstated.

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?

Specific verb+resource: connecting the MCP process to one explicit Plasticity window, plus the return value (compact initial scene summary). This clearly distinguishes it from siblings like plasticity_list_windows, plasticity_status, or plasticity_call.

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

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

Explicitly routes the agent to plasticity_body_info when exact body topology is needed, and warns that body bounds/counts are paginated. It does not, however, say when to prefer connect over plasticity_list_windows or plasticity_status, so the alternative routing is only partial.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), so the bar is lower, yet the description still adds substantive context: the history is private and local, survives MCP restarts, works without a connected Plasticity window, and records are historical and never authorize replay. That last point meaningfully closes off an incorrect replay interpretation.

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, front-loaded with what is read, followed by the persistence/lifecycle conditions, then paging. No filler or restated boilerplate.

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

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

With no output schema, the description carries the return-value burden and does describe the record contents. It omits ordering (newest-first vs oldest-first), which matters for a paged history read, but is otherwise complete for a simple read-only tool.

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

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

Schema coverage is 0%, so the description carries the load. It names both parameters and frames them as a paging pair, which clarifies their combined intent beyond the bare integer bounds and defaults in the schema. Minor gap: it doesn't state the default page size or the 100 cap from the schema.

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

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

States a specific verb (Read) and resource (private local construction-event history) and enumerates what the records contain: operation inputs, outcomes, and added/removed/modified B-Rep measurements. However, it never distinguishes itself from near-identical siblings like plasticity_construction_journal or plasticity_changes_since, so an agent cannot route confidently between them from the text alone.

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

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

"Use offset/limit for paging" is invocation mechanics, not when-to-use guidance. Given a dense sibling field containing plasticity_construction_journal, plasticity_changes_since, and plasticity_capture_snapshot, the absence of any explicit selection criteria or exclusions is a real gap.

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, and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: results are paginated, commands are not replayed, external document changes are detected, and the live document is compared against the last durable construction event.

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 reasonably tight sentences, with the core read purpose front-loaded and the constraints following. No filler, though the dense terminology slightly hinders 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?

There is no output schema, so the description must describe returns, and it does: journal entries, B-Rep change measurements, detected out-of-journal changes, and a live-vs-durable comparison. Combined with the annotation-covered read-only profile, an agent has enough to invoke it correctly.

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

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

Schema description coverage is 0% with two pagination parameters (limit, offset), so the description must compensate and largely does not. 'In pages' only vaguely implies pagination and never explains offset/limit semantics, defaults, or ranges that the schema lists without prose.

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 ('current-process MCP mutation inputs and compact B-Rep change measurements'), and clarifies scope ('in pages', 'does not replay commands'). However, the jargon-heavy phrasing is opaque and it never names or contrasts with close siblings like plasticity_construction_history or plasticity_changes_since, so an agent can't easily route among them.

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

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

Gives a negative constraint ('does not replay commands') but no positive when-to-use guidance and no alternatives named. With siblings such as construction_history, changes_since, and wait_for_change available, the agent gets no signal for choosing this tool over them.

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 mark this as destructive and non-read-only, but the description adds substantial behavioral context: the Wire path, segment structure, length, and topology all change, all old vertex and segment references must be discarded, and the returned Wire must be inspected before continuing. This is exactly the invalidation and mutation detail an agent needs 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?

The purpose is front-loaded in the first sentence, followed by prerequisites, exclusions, and the critical post-call warning. Every sentence adds operational value 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?

For a destructive, no-output-schema mutation tool, the description covers the source of references, current-revision requirement, unsupported inputs, topology-changing consequences, reference invalidation, and the need to inspect the returned Wire. Nothing critical is missing for correct invocation and safe follow-up.

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 meaningfully constrains the vertices and revision inputs by requiring current-revision references from plasticity_list_curve_vertices and excluding open endpoints, but it says nothing about the optional intent parameter or the bodyId/vertexId shape beyond what the schema itself defines.

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: converting exact current interior or closed Wire vertices into native B-Spline control vertices. It also distinguishes the operation from adjacent curve tools by requiring references from plasticity_list_curve_vertices and excluding open endpoints.

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

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

It gives clear preconditions: references must come from plasticity_list_curve_vertices at the current revision, and open endpoints are not convertible. It does not explicitly name an alternative conversion tool, but the when-to-use context is strong and unambiguous.

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 the destructive mutation profile (readOnlyHint=false, destructiveHint=true), so the bar is lower. The description adds genuinely new behavioral context beyond annotations: the cutter and Boolean become two explicit native history steps, and material depth must exceed hole depth. It stops short of noting auth/revision or reversibility specifics.

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?

Four sentences, front-loaded with the operation and its geometric constraints, with no filler. The technical density is appropriate for a CAD operation, though the history-step detail could be positioned later.

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 9-parameter destructive mutation tool with no output schema, the description covers geometry, material constraint, and history-step side effects well. It omits the required revision parameter (concurrency guard) and overshootMm behavior, which are meaningful gaps but not fatal.

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 the full burden, and it does well: entry center 'lies on the target surface', axis 'points into the material', and diameter/depth/materialDepth semantics are all explained. It does not address revision, intent, or the overshootMm parameter, so coverage of the 9 params is partial but strong on the geometry-critical ones.

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 ('Cut one exact flat-bottom blind round hole into a current Solid') and qualifies it heavily enough (blind, flat-bottom, round, on a target surface) to distinguish it from siblings like create_through_hole, create_counterbore, and create_blind_hole_pattern. An agent can select this without opening the schema.

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

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

It gives input-selection guidance (diameter/depth must come from the tap/screw/insert or qualified process, not nominal thread diameter or fastener length) and a feasibility rule (material depth must exceed hole depth). However, it never states when to use this versus a through hole, counterbore, or the blind-hole pattern variant, so the when-to-use decision is left implicit.

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 readOnlyHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: the axis points into the material, each cutter is a confirmed history step, and a single final Boolean consumes every cutter. It does not mention auth, rate limits, or failure modes, but for a CAD cutter the disclosed modeling behavior is meaningful.

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 dense sentences with the operation front-loaded and the geometric constraints following. Every clause carries information; no filler, though the packing is heavy enough to read as terse.

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

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

No output schema and 9 parameters at 0% schema coverage mean the description bears the load. It covers the geometric operation and its key preconditions well, but omits the auxiliary parameters (revision, intent, overshootMm) an agent may still need to supply 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 must carry parameter meaning. It explains entryCentersMm, axis direction, holeDiameterMm ('qualified finished diameter'), holeDepthMm, materialDepthMm (with the depth constraint) and targetId, but leaves revision, intent, and overshootMm (the 0.5mm default) entirely undocumented.

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

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

States a specific verb ('Cut'), resource ('equal exact flat-bottom blind round holes'), quantity range (2-256), and target ('one current Solid'). This clearly distinguishes it from the single-hole sibling plasticity_create_blind_hole and the other pattern 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?

Implies when to use it (multiple identical holes at explicit entry centers) and states hard preconditions ('material depth must be greater than hole depth'), but never names an alternative such as plasticity_create_blind_hole for single holes, so the routing decision is left to inference 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.