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

With no annotations, the description carries the full burden, and it does disclose meaningful behavior: the typelib block is from THIS installation (so it matches the running version, not a generic doc), the help is versioned 2026 SP04, and the payload includes parameter meaning, governing enum, units, return, remarks tables and version-introduced info. It omits any note on lookup failure behavior or performance, but for a local documentation read the disclosure is solid.

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, followed by a compact enumeration of payload contents and one short directive sentence. No filler or repetition. The middle sentence is dense, but every clause maps to a real output component, so 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?

There is no output schema, so the description must describe the return payload — and it does so in detail (typelib order and COM types, per-parameter meaning, governing enum, units, return value, remarks/mark tables, version availability). Inputs are fully covered by the schema. Only minor gaps remain, such as error handling for unknown members.

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 already 100% with both parameters documented, so the baseline is 3. The description adds value beyond the schema by stating that the interface argument accepts either 'FeatureManager' or 'IFeatureManager', i.e. the 'I' prefix is optional — a normalization rule the schema does not state.

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: it returns the full documentation sheet for one API method/property, enumerating exactly what that includes (typelib parameter block from this installation plus official 2026 SP04 help). That is far more than a restatement of the name. It does not, however, differentiate itself from the closely related siblings sw_api_search, sw_api_members and sw_api_example, which an agent would also consider for API lookups.

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 clear usage context: consult before writing a COM call in sw_execute_script. That tells the agent the moment to reach for this tool. It stops short of naming exclusions or the sibling alternatives (e.g. 'use sw_api_search for free-text discovery instead'), so it earns a 4 rather than 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?

With no annotations, the description carries the full burden. It discloses genuinely useful behavior: a member name is auto-resolved to its enum, and swSelectType_e returns an enum->string table for SelectByID2 (swSelFACES -> "FACE"). It does not say what happens for an unknown or misspelled name, which is the main failure mode for a lookup tool.

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

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

Three short sentences, no filler: first the scope, then the alternate input form, then the practical coding note and the special-case output. Every sentence adds information and the primary purpose is front-loaded.

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

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

There is no output schema, so the description must carry return semantics; it does so for the interesting case (swSelectType_e's enum->string mapping) but not for the generic case. For a single-param read lookup this 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 coverage is 0% and the schema documents nothing about 'name'. The description compensates well by explaining that the parameter accepts either an enum type or a bare member name, which is the key ambiguity an agent would face. 0-parameter baseline logic does not apply since a required param exists.

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 resource (swconst enum members and values) and gives concrete examples (swEndConditions_e, swSelectType_e), plus a second mode: resolving a loose member name to its enum. That distinguishes it from generic siblings like sw_api_search and sw_api_doc, though the verb itself ('returns/retrieves') 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 only implied through the two input modes (whole enum vs single member) and the note to reference names via win32com.client.constants rather than the number. There is no explicit statement of when to prefer this over sw_api_members or sw_api_search, so routing guidance is weak.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the VBA-first/VB.NET-fallback behavior and that results are indexed by interface/member, which is useful. However it says nothing about ordering, result shape, or what 'limit' bounds, leaving real behavioral gaps for an unannotated tool.

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

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

Content is dense but ordered: resource and index first, then the use-case routing to sw_execute_script, then the three lookup modes. No filler sentences, though the single long paragraph could be more scannable.

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, no annotations, and 5 parameters, the description should describe the return payload more fully. It covers most query modes but omits the 'limit' default behavior and gives only a hint ('el codigo completo') about what a result actually contains, leaving the agent guessing at output structure.

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 5 parameters, so the description must compensate, and it largely does: it explains query as free-text search with concrete examples, iface/member as those linked by an interface or member, and id as returning the full code of a single example. Only 'limit' is left unexplained.

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

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

States a specific resource (official API code examples for the 2026 help, VBA with VB.NET fallback) and what it is indexed by (interfaces and members). It distinguishes itself implicitly from sibling doc tools (sw_api_search, sw_api_doc, sw_api_enum, sw_api_members) by returning full runnable code, though it never names those siblings.

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

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

Explicitly says when to use it: 'Para descubrir el flujo completo de una operacion ... antes de escribirla en sw_execute_script' – discovering the sequence of calls before scripting. It names the downstream tool but gives no when-not guidance versus the other sw_api_* lookups.

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

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

With no annotations, the description carries the burden and does disclose a genuinely useful behavioral trait: output can be very large (IModelDoc2 has 762 members) and should be narrowed with kind. It also discloses the breadth of coverage (all 10 namespaces) and the payload structure. It omits any note on permissions or rate limits, but for a read-only doc lookup that is minor.

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: scope first, coverage second, size warning and filter tip last. Slightly redundant between 'resumen de una linea' and 'Incluye la ficha: resumen...', but every sentence conveys actionable information.

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

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

No output schema and no annotations, so the description must describe the return shape, which it does (one-line summaries, interface card with summary, accessors, functional category, official examples). Combined with the size warning and filter advice, an agent has enough to call it correctly; only the exact response format remains unspecified.

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

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

Schema coverage is 0%, so the description must compensate and largely does: it implies iface is the interface name and supplies example values (IFeatureManager, IBody2, IFace2), and it explains what the kind filter does ('si solo quieres propiedades') beyond the bare enum. Format/acceptability details for iface are still left implicit.

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: lists all members of an interface with a one-line summary, covering the 10 namespaces of the 2026 help. It also names concrete example interfaces (IFeatureManager, IBody2, IFace2), so the agent knows exactly what it retrieves. It does not, however, differentiate itself from overlapping siblings like sw_api_search or sw_api_doc.

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

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

Gives an implicit usage scenario ('para descubrir que se puede hacer con...') and one concrete tip ('filtra con kind si solo quieres propiedades'), but never says when to prefer this over sw_api_search or sw_api_doc, nor any exclusion conditions. Usage is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden; it discloses the underlying data sources (api_index.txt typelib dump vs sw_api_index.sqlite help index) and what fields each covers. It stops short of stating read-only nature explicitly or describing result shape/pagination, so it is strong but not exhaustive for a search tool.

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

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

Three front-loaded sentences with no filler: purpose first, then mode behavior, then the hand-off to sw_api_doc. Dense but every clause earns its place.

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

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

For a read-only search tool with no output schema and no annotations, the description gives enough to select the right mode and know the data provenance. It omits how results are returned and how 'limit'/'interface' refine output, which keeps it short of a 5.

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

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

Schema coverage is 75%; the description clarifies what the regex actually matches against (exact name, order and type of each parameter) and frames 'text' as the alternative to 'pattern', adding meaning beyond the schema strings. The 'interface' and 'limit' parameters are not addressed in the description, leaving a minor gap.

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

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

States a specific verb+resource ('Busca miembros de la API COM de SOLIDWORKS') and explicitly distinguishes the two operating modes ('pattern' vs 'text'), which is the key ambiguity an agent would face. It also names the sibling sw_api_doc as the natural next step once a name is found.

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 routing: use 'pattern' for regex over the real typelib, use 'text' for free-text search over the official help when you don't know the name, with concrete examples ('bounding box', 'save body as part', 'mass properties'). It also states the follow-up tool, so an agent knows exactly when to reach for this vs alternatives.

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

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

No annotations exist, so the description carries the full burden; it does disclose the output content and units, which compensates for the absent output schema. However, it says nothing about whether it reads the active document, a selected body, or the whole assembly, nor whether it requires an open document first.

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

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

A single short sentence with the units front-loaded before the returned fields; nothing is wasted. It is slightly too terse to be a model of front-loading, reading as a fragment without an explicit action verb.

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

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

For a zero-parameter query tool with no output schema, the description adequately enumerates the return values and their units. It leaves a real gap in scope: which document, body, or component the 'global' box applies to, and how multiple bodies would be represented.

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

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

The tool takes zero parameters, so per the baseline this scores 4. The description correctly does not invent parameter detail, and the named treat values (min, max, size, center) describe the result rather than 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?

Names the resource precisely (global bounding box) and enumerates the returned components (min, max, size, center) plus units (mm), which cleanly separates it from siblings like sw_mass_properties or sw_list_bodies. The verb is implicit and no target document/body scope is stated, so it falls short of a 5.

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

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

There is no guidance on when to reach for this tool versus alternatives such as sw_mass_properties or sw_doc_info, and no prerequisites or context are mentioned. The agent must infer usage entirely from the name and the returned field list.

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

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

No annotations are present, so the description carries the full burden and does well: it discloses the assumed machine/dimensions and collet set, states the side effect that export_dir triggers an additional STEP (mm) export for Makera CAM, and explicitly negates toolpath generation. It stops short of describing permissions or the exact result format.

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 defaults are front-loaded in one dense sentence followed by the export clause and the scope negation. Slightly packed (collet list and machine dims inline), but each element carries real information for correct invocation.

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

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

For a single-optional-param tool with no output schema or annotations, the description covers what is analyzed, the default assumptions, the export side effect, and the non-goal (no toolpaths). Return content is characterized by the check list rather than a structured spec, which is acceptable here.

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 coverage the description must compensate, and it does: export_dir is explained as the switch that additionally exports a STEP in mm for Makera CAM. That is meaningful behavior beyond the bare name/type in the schema, though it omits path/error 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+resource (manufacturability review for 3-axis milling from +Z) and enumerates exactly what is checked (fit in area, min concave radius, cutter fit, L/D slenderness, tight holes, faces needing a flip). This is unmistakably distinct from the SolidWorks modeling/API 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?

Scope is implied rather than stated: it notes the default machine profile and that it does NOT generate toolpaths, which helps an agent place it as pre-CAM feasibility analysis. However, there is no explicit when-to-use vs. alternative guidance or prerequisites for invoking it.

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

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

No annotations are provided, so the description carries the full burden — and it does disclose the single most important behavioral trait: that closing discards unsaved changes unless save=true. It does not, however, describe error behavior (e.g. what happens with no active document) or the interaction with sw_save_as.

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 waste, with the core action and the critical side-effect caveat front-loaded. Every clause earns its place.

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

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

For a no-annotation, no-output-schema mutation tool, the description covers the destructive risk but omits error conditions and relationship to sibling save/close tools. 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 there is exactly one parameter. The description compensates well for the sole parameter by explaining the semantics of save ('No guarda salvo que save=true'), which is meaning beyond the bare boolean default in 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?

Names a specific verb and resource ('Cierra el documento activo'), so an agent immediately knows this is a close operation on the current document. It does not, however, differentiate itself from siblings like sw_save_as or sw_open, though the naming makes the distinction largely self-evident.

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

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

The description gives no indication of when to use this tool versus alternatives, nor any prerequisites (e.g. whether a document must be open). Usage is only implied by the verb 'Cierra'.

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

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

With no annotations, the description carries the full burden and does disclose the environment prerequisite and that it attaches to a running instance rather than launching one. It does not say whether the attach has side effects, whether it fails or blocks when no instance exists, or what error behavior to expect.

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

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

Two short sentences, front-loaded with the action and return values, with the prerequisite placed last. No padding or redundancy.

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

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

For a zero-parameter, no-output-schema tool, the description covers the action, the required precondition, and the return payload, which is nearly everything an agent needs. It could have said what happens on failure, but nothing essential is missing.

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

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

The tool takes zero parameters, so the baseline is 4; there is no parameter surface for the description to clarify or omit.

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 ('Adjunta') plus two concrete outputs (version and active document), which clearly separates it from sw_open and sw_new_part. It does not explicitly name those siblings, so it stops short of a 5.

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

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

The precondition 'SOLIDWORKS debe estar ya abierto' tells the agent when the tool is valid, which is useful implied usage guidance. However, it never states when to prefer this over sw_open or sw_doc_info, so routing between siblings 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?

With no annotations provided, the description carries the full behavioral burden and does not state that this is a read-only query, that it requires an open/active document, or what happens when no document is loaded. The only implicit hint is the word 'activo', which suggests a dependency on current state but never makes it explicit.

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

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

A single short sentence that front-loads the returned fields with no padding. It is a noun fragment rather than a complete statement, which slightly weakens the delivery but wastes no words.

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

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

There is no output schema and no annotations, so the description's enumeration of return fields (title, path, type, body count) is genuinely load-bearing. For a zero-parameter getter, this is close to sufficient; only the read-only/active-document precondition is missing.

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

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

The tool takes zero parameters, so the baseline of 4 applies. No parameter semantics need explaining.

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 Spanish fragment names the resource (documento activo) and enumerates the returned fields (título, ruta, tipo, número de cuerpos), so the agent can infer this is a metadata getter. However, it lacks a verb and offers no differentiation from sibling info tools like sw_mass_properties or sw_list_features, leaving the agent to guess its unique role.

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 call this versus sw_list_features, sw_bbox, or sw_mass_properties, all of which also inspect the active document. No preconditions (e.g., a document must be open) or exclusions are stated.

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

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

No annotations are provided, so the description carries the full burden and does so richly: the two-step readOnly enforcement (pre-execution textual block on Feature*/Insert*/Set*/Save* patterns, post-execution body/face/modified-flag comparison), the readOnlyViolation return on failure, the explicit 'this is not a sandbox' warning, and the no-timeout/hang-blocks-server caveat.

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, then scope, then prerequisites, then safety caveats — a logical order with every sentence carrying weight. It is dense and long, but for an arbitrary-code-execution tool the density is justified rather than 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 tool with no output schema and full arbitrary-code power, the description covers return channels (result, stdout, readOnlyViolation), execution constraints (no timeout), safety limits, and prerequisite tooling. Nothing an agent needs to invoke it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds genuine meaning beyond the schema: it documents the injected scope names, the 'result' variable for structured output, and print() mapping to stdout. The readOnly parameter's semantics are also elaborated far beyond the schema's one-line note.

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: it runs arbitrary Python against the SOLIDWORKS session, explicitly analogous to Fusion's 'script' tool. The enumerated scopes (sw, doc, c, fx, mz, am) make it unmistakable against siblings like sw_extrude or sw_bbox, which are narrow single-operation 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?

Gives clear conditional guidance, notably 'ANTES de escribir una llamada COM que no conozcas de memoria, consulta sw_api_doc(iface, member)', routing the agent to the right sibling for API signatures. It also explains how and when readOnly triggers its two-step check. It stops short of explicitly saying when to prefer this escape hatch over the dedicated sw_* tools, so 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?

No annotations are provided, so the description carries the full burden. It discloses that the source is the active document, but says nothing about overwrite behavior if the path exists, required permissions, whether the document must be saved first, or error/failure modes. For a file-writing operation this is a significant gap.

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

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

A single short sentence with the verb and target format front-loaded; nothing is wasted. It is efficient, though its brevity is part of the under-specification problem rather than a virtue in itself.

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 no annotations, so the description alone must cover behavior for a write-to-disk tool, and it does not mention overwrite risk, path validation, or return information. An agent calling this could easily clobber an existing file without warning.

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 one parameter at 100% schema description coverage, the baseline is 3. The schema already specifies 'Ruta absoluta .STEP', and the description adds no further meaning (e.g., whether the extension is mandatory or auto-appended), so the schema does the heavy lifting.

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 (exporta) and resource (el documento activo) plus the target format (STEP), so an agent knows exactly what operation this performs. It does not, however, distinguish itself from the closest sibling sw_save_as, which also writes the active document out.

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 indication of when to use this versus sw_save_as or sw_execute_script, no prerequisites (document must be open), and no exclusions. The agent must infer the trigger condition from the name alone.

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

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

With no annotations the description carries the full burden, and it delivers real behavioral detail: units are mm, extrusion grows +Z from z0 to z1, the z1 < z0 case inverts direction, and cut=true switches from additive to subtractive. It does not mention document mutation side effects, undo, or rebuild requirements, but the core geometry behavior and the add/cut distinction are well disclosed.

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

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

Four dense sentences, front-loaded with the operation and units, then geometry direction, then the cut modifier. No filler, and every clause carries information an agent needs.

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

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

For an 8-parameter mutation tool with no annotations and no output schema, the description covers units, direction, inversion, and cut semantics well. It leaves the role of merge, name, and plane to the schema, which is acceptable given 75% coverage, though it could have noted the tool rebuilds/modifies the active document.

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 75%, so the schema already documents profile, plane, z0/z1 and through. The description adds cross-parameter semantics the schema lacks: the +Z growth direction, the z0 >= 0 constraint, the inversion rule when z1 < z0, and what cut=true means. This meaningfully exceeds the per-field descriptions.

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

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

States a precise verb+resource (combine sketch + extrusion in one step) and scopes it to the active document. No sibling covers extrusion, so it does not need to disambiguate against sw_new_part or the sw_api_* tools. An agent immediately knows a profile geometry becomes an extruded feature.

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 the case for use ('en un solo paso') and the cut=true alternative for material removal, but gives no explicit when-to-use vs. when-not or a pointer to any alternative approach (e.g., scripting via sw_execute_script). Usage is inferable rather than stated.

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

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

No annotations are provided, so the description carries the full burden. It usefully discloses the performance profile (~40 s for 22 components) and the shape of the result grouping, which goes beyond the schema. However it never says whether the operation is read-only or mutates/annotates the model, nor that an open assembly document is required, leaving key behavioral traits undisclosed.

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 sentences: the scoping/return information is front-loaded and the practical timing warning is appended. Nothing is redundant and every clause carries information.

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

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

With no output schema, the description correctly tells the agent what comes back (per-pair count, total and max volume in mm3) and how long it may take. The remaining gap is that it does not state the read-only nature or the required document state, minor for a single-parameter query tool.

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

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

Schema description coverage is 100%, so the schema already documents the single 'coincidence' parameter. The description does not mention it at all, adding no meaning beyond the structured field; baseline 3 applies.

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

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

The description states a specific verb+resource: it reports interferences within the active assembly, grouped by component pair, with count, total and max volume in mm3. That is far more concrete than a tautology. It does not explicitly distinguish itself from the sibling tools (e.g. sw_check_machining), though no sibling is a direct competitor, so it stops short of a 5.

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

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

Usage is implied rather than stated: the reference to the 'active assembly' hints at a precondition, and the timing note helps the agent decide whether to wait, but there is no explicit when-to-use, when-not, or alternative tool guidance. Minimum-viable guidance.

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

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

No annotations are provided, so the description carries the burden, and it does at least disclose the return content and units (bounding box in mm). However it says nothing about whether hidden/suppressed bodies are included, ordering, or that it is a read-only operation — meaningful gaps for a zero-annotation tool.

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

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

A single front-loaded sentence that names the resource and the returned data with zero filler. Well sized for the tool's simplicity.

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

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

With no output schema and no annotations, the description should explain the return shape a bit more (e.g., one entry per body, ordering, whether the bbox is a min/max pair). It covers the essentials (bodies + bbox in mm) but leaves the response structure underspecified.

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

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

The tool takes zero parameters, so there is nothing to document; baseline 4 applies. The description's mention of mm units is a small bonus but not a parameter concern.

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: lists the solid bodies of the active document, and even names the payload (bounding box in mm). It does not explicitly differentiate itself from close siblings like sw_bbox or sw_list_features, so it lands at 4 rather than 5.

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

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

There is no when-to-use guidance, no mention of prerequisites (an active document / open model), and no pointer to alternatives such as sw_bbox or sw_list_features. The agent must infer that this applies only when a document is already open.

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

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

No annotations are provided, so the description carries the full burden. It discloses the shape of each returned entry (name, type, suppressed) but says nothing about read-only behavior, ordering, pagination, or what 'documento activo' means if no document is open.

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

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

One compact sentence with no filler, and the resource and returned fields are front-loaded. Slightly terse given what remains unexplained, but efficient.

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

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

For a simple listing tool with no output schema, the description adequately signals the return fields, but it omits the limit parameter, truncation behavior, and the read-only nature expected of an agent making this call. Partially 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% and the single parameter (limit, default 200) is never mentioned in the description, so its purpose, units, and ceiling are undocumented anywhere. 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 resource (the operation tree of the active document) and even enumerates the returned fields (nombre, tipo, suprimida). This distinguishes it from siblings like sw_list_bodies, though the verb is only implied by the tool name rather than stated.

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

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

No guidance on when to call this versus alternatives such as sw_list_bodies, sw_doc_info, or sw_rebuild; no prerequisites or context of use are given. The agent must infer that this is a read-only inspection call.

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

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

With no annotations, the description carries the full burden. It does disclose an important side effect — passing 'material' assigns it to the document before measuring — which is meaningful behavioral context. However, it omits whether the assignment is persistent/reversible, permission needs, or failure behavior, leaving notable gaps.

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

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

Two compact sentences, front-loaded with the returned quantities and units, then the conditional side effect. No filler. Minor awkwardness in the phrasing of the conditional clause, but 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 usefully enumerates the return quantities with units, which covers the return gap. But with no annotations and zero schema coverage, the unexplained 'database' parameter and unstated document prerequisites leave the definition only partially complete for a measurement-plus-mutation tool.

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

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

Schema description coverage is 0%, so the description must compensate. It documents 'material' well (a .sldmat name with a concrete example), but says nothing about the 'database' parameter, leaving half the parameters 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?

States a specific resource and enumerates exactly what is computed/returned (volume, area, mass, density, center of gravity) with units, which lets an agent distinguish it from siblings like sw_bbox or sw_doc_info. It does not explicitly name a sibling it differs from, but the returned quantities are unambiguous.

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

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

Usage is only implied: the description notes the conditional behavior when 'material' is passed, but gives no explicit when-to-use/when-not or prerequisites (e.g. that a document must be open, or when to prefer sw_bbox for geometry queries). The tool being read-oriented is inferable but not stated.

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

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

With no annotations, the description carries the full burden and does meaningfully disclose a non-obvious side effect: it overrides document units to MMGS by default and explains why (factory template is in metres, sheet-metal DXF/DWG would export in metres). It also states the document is left active.

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

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

Two tight sentences: purpose first, then the units caveat. Every clause earns its place and the most important constraint is front-loaded after the purpose.

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

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

For a simple one-parameter creation tool with no output schema and no annotations, the description covers purpose, unit behavior, and resulting document state. Only minor gaps remain, such as the exact template name or session requirements.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds real value beyond the schema by explaining the consequence of the default (mm=true → MMGS) and the reason for it, which is exactly the decision an agent must reason about.

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 ('Crea una pieza nueva') plus the template used and the resulting document state ('la deja activa'). It is clearly distinct from sw_open by the word 'nueva', though it does not name that sibling explicitly.

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

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

Usage is implied by the name – you call it to start a fresh part – but there is no explicit when-to-use statement, no exclusion of alternatives such as sw_open, and no preconditions (e.g. active session).

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

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

No annotations are provided, so the description must carry behavioral disclosure. It discloses that the document is left active, which is a useful post-condition. But it does not mention error behavior for missing files, whether it requires an existing SolidWorks connection, or any side effects. For an open operation that's insufficiently rich, but the 'active' detail adds value.

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

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

A single, front-loaded sentence with zero waste. It conveys the action, accepted formats, and the resulting active state.

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

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

For a one-parameter open tool with no annotations and no output schema, the description is minimally complete: it says what's opened and the effect. Missing prerequisites like 'requires sw_connect first' or error conditions keep it from being 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 coverage is 100%, and the schema already documents the single 'path' parameter including that it's an absolute Windows path. The description adds nothing beyond what the schema provides. Baseline 3 is appropriate when the schema does the work.

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 ('Abre') and resource ('documento existente') with supported extensions (.SLDPRT/.SLDASM), and notes it becomes active. However, it does not distinguish itself from the sibling sw_new_part (which creates new) beyond the word 'existente'. Adequate but sibling differentiation is thin.

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: use this to open an existing document. No explicit when-to-use vs alternatives (e.g., vs sw_new_part or sw_connect) and no exclusions. Minimum viable.

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

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

No annotations are provided, so the description carries the full burden, yet it discloses nothing about side effects, whether the rebuild can invalidate downstream features, whether it requires an open document/connection, or what happens on failure. Only the word 'Fuerza' hints at a forced/override 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?

A single front-loaded sentence with no padding, so it is concise, but its terseness comes at the cost of useful content rather than from disciplined editing.

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 operation on the active document with no annotations, no output schema, and an undocumented parameter, the description is too thin. An agent lacks enough information to call it confidently or predict its effect.

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

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

One parameter ('full') exists with 0% schema description coverage (no description, just a default), and the description does not mention it at all. The difference between a normal and a full rebuild is 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?

"Fuerza reconstruccion del documento activo" states a specific verb (force rebuild) and resource (active document), which is enough to distinguish it from siblings like sw_new_part or sw_list_features. However, it never explains what a 'rebuild' means for the model or how it relates to editing operations, so it is clear but bare.

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 rebuild versus when not to, no prerequisites, and no mention of any alternative tool. The agent must infer that this is used after geometry changes.

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

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

No annotations are provided, so the description carries the full burden. It does not say whether an existing file is overwritten, whether the active document's working path changes, whether a dialog or permission prompt appears, or what the tool returns on success or failure.

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

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

A single tight sentence with the primary action front-loaded and the optional flag attached at the end. No filler, though it sacrifices detail for brevity.

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 zero annotations and no output schema, the definition is thin: overwrite behavior, error conditions, and the STEP output destination are all unstated, leaving the agent unable to predict the side effects of calling it.

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

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

Schema coverage is only 50%: path is fully documented in the schema (absolute path with .SLDPRT/.SLDASM extension), but step has no schema description. The description partially compensates by explaining that step optionally writes STEP as well, though it does not say where that STEP file lands.

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 in Spanish: saves the active document to the given path. It is clear what happens, though it never distinguishes itself from the sibling sw_export_step despite both touching STEP output.

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

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

No when-to-use or when-not-to-use guidance. The only implied usage note is the optional STEP flag, and the agent gets no hint about whether to prefer this over sw_export_step or how they differ when step=true.

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

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

No annotations exist, so the description carries the full behavioral burden. It usefully discloses the export mechanism (SaveBMP as the only confirmed image export) and the no-Pillow conversion, but omits whether the view is mutated, what the tool returns, or any permissions/state requirements. Adds real value but leaves meaningful gaps.

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

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

Three sentences, front-loaded with the core action, then use case, then implementation note. Little waste; the implementation detail is arguably relevant given the no-Pillow constraint, though it edges toward verbose.

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 no annotations mean the description should ideally explain the return value (path? confirmation?), which it does not. It does cover output location and format, so the agent can call it correctly, but completeness for a file-producing tool is only partial.

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 50%: path and direction carry rich descriptions (direction's ViewId verification is unusually detailed), while width/height have only defaults. The description itself adds nothing to parameters, so the undocumented width/height must be inferred from type and defaults. Baseline 3 for partial coverage.

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

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

States a specific verb+resource: capture the active view to PNG, and reinforces it with an analogy to Fusion's 'screenshot' queryType. An agent can immediately tell this is a screen-capture tool, though it never explicitly contrasts against any sibling (e.g., sw_export_step for file export).

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

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

Provides an implied use case ('ver lo que se ha construido sin que el usuario este delante de la pantalla'), which tells the agent when remote inspection is wanted. However, there is no explicit when-not guidance, no prerequisites (e.g., document must be open/connected), and no named alternative.

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