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

No annotations are provided, so the description carries the burden; it does disclose what content is returned (signatures + docstrings) but never states that the operation is read-only and side-effect free, nor how large the listing is when `function` is empty. Since it is a documentation lookup, the mutability risk is low, keeping this at adequate rather than poor.

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

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

Two short sentences with no filler, and the core purpose statement precedes the parameter hint. Nothing is repeated from the schema.

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 low-complexity, single-optional-parameter lookup tool with an output schema, so return-value explanation is not needed. The description covers scope and filtering; the only gap is that it never explicitly frames itself as the prerequisite step before `freecad_run`.

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 largely does: it explains that passing `function` narrows to a single function and that an empty value lists everything. It does not say whether the value must match exactly or how function names are discovered, but the empty-string listing behavior makes it self-bootstrapping.

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 resource: signatures and docstrings of the `awcad` helpers available inside `freecad_run`. That clearly sets it apart from the execution siblings, though the verb is implicit (a noun phrase, 'Documentação dos helpers'), so the agent must infer that the tool returns documentation rather than acting on it.

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 `function` vs empty-string behavior is spelled out, but there is no explicit statement of when to reach for this tool versus `freecad_run` or `freecad_status`. The intended usage (consult before writing `awcad` code in `freecad_run`) is only implied by the phrase 'disponíveis dentro de freecad_run'.

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 for a code-execution tool. It usefully discloses that execution is headless, that `doc` starts as an empty document, that files land in the output folder, and that prints come back in the response. However it says nothing about failure behavior, whether execution is sandboxed or has filesystem access, or what happens when timeout_s expires — material gaps for arbitrary code execution.

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 is front-loaded, followed by environment facts and a minimal worked example that earns its space by showing the export idiom. The trailing note on `name` reads as an afterthought tacked onto the end rather than integrated with the rest of the parameter guidance.

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

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

An output schema exists, so return values need not be spelled out, and the description still flags that exports, measurements, and prints come back. What it omits — timeout semantics and error/partial-failure behavior for a code-execution tool — are the remaining gaps an agent would want before 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 description coverage is 0%, so the description must compensate. It explains `code` thoroughly (available bindings, expected final call) and explains `name` as the script filename prefix saved under <output>/_scripts for traceability. `timeout_s` is never mentioned anywhere, leaving one of three parameters 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 and resource: execute a Python script in headless FreeCAD and return exports plus measurements. The output contract (STL+3MF, measurements, prints) is concrete. It does not differentiate itself from the sibling freecad_run_file, so an agent must infer that this one takes inline code rather than a path.

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 in-context guidance: what is pre-bound in the script scope (App, Part, awcad, doc), and the rule that awcad.export is for exporting while awcad.measure is for measuring without exporting. It also states the placement convention (base at Z=0 via aword.on_bed). It never says when to prefer this over freecad_run_file or freecad_selftest, so no explicit alternatives or exclusions.

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

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

No annotations are provided, so the description carries the full burden. It discloses that execution is headless and that `awcad` is importable, but says nothing about arbitrary code execution side effects, whether documents are saved or left in memory, what happens on timeout (the 180s default), or how errors surface. For a code-execution tool with zero annotation coverage this is a substantial gap.

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

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

A single tight sentence with the key constraint (local .py file) front-loaded, no filler. Brevity is achieved, though at the cost of the transparency gaps noted above rather than through disciplined selection.

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

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

An output schema exists so return values need not be explained, but for an execution tool with no annotations and 0% parameter coverage the description should cover side effects, timeout semantics, and failure behavior — none of which appear. An agent could call it on the wrong kind of file or be surprised by state changes.

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

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

Schema coverage is 0%, so the description must compensate. It clarifies that `path` points to a local .py file and shows an example path format, which adds real meaning; however, `timeout_s` is never mentioned in the description or schema, leaving one of two parameters 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 ('Executa') and resource ('arquivo .py local') plus the execution context (FreeCAD headless, with `awcad` available), which lets an agent tell it apart from freecad_run (likely inline code) and freecad_status. However, it never explicitly contrasts itself with the sibling freecad_run, so the differentiation is inferred 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?

The phrase 'arquivo .py local' implies you use this when you already have a script on disk, and the file example gives a concrete hint. There is no explicit when-not guidance, no mention of prerequisites, and no named alternative for the inline-code case.

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 must carry the behavioral burden. Calling it a "short script" implies cheap/fast execution and it is implicitly a self-check, but it does not say whether running it mutates the document, creates test artifacts, or requires an active FreeCAD session — meaningful gaps for a code-executing tool.

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

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

Two sentences, no filler, with the action stated first and the usage condition second. 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 zero-argument diagnostic tool with an output schema documenting results, the description covers what it does and when to invoke it. The only real omission is whether it has side effects on the current 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. No parameter claims are made or needed.

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 action (run a short script that exercises the main awcad helpers), which is clearly a diagnostic/verification operation rather than a file execution. It does not explicitly contrast itself with the closest sibling, freecad_status, which is also a health-style check, so sibling differentiation is only partial.

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 após instalar para confirmar que tudo funciona" gives an explicit trigger condition (post-install verification). There is no guidance on when NOT to use it or which sibling to prefer for ongoing status checks, but the usage context is 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?

With no annotations, the description must carry the behavioral burden. 'Verifica' implies a read-only probe, and the three enumerated checks give a decent picture of what it reports, but it says nothing about what happens when FreeCADCmd is not found (error vs. negative result) or whether it touches the filesystem.

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 that front-loads the existence check and then lists version and output folder. No padding, though the trailing clause is slightly less crisp than the opening.

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

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

With zero parameters and a declared output schema, the return values need no explanation, and the description names the three data points the agent will get back. The only remaining gap is failure behavior, which is minor for a status probe.

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 nothing for the description to disambiguate, and it correctly doesn't waste words on 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 verb ('Verifica') and three concrete checks: whether FreeCADCmd was found, its version, and the configured output folder. This clearly separates it from action-oriented siblings like freecad_run or freecad_run_file, though it doesn't explicitly distinguish it from freecad_selftest.

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 diagnostic nature of a 'status' check, but the description never states when to call it (e.g., before running a file, to troubleshoot missing FreeCADCmd) nor names an alternative. An agent must infer the pre-flight use case on its own.

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

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

With no annotations, the description carries full burden, but it does disclose meaningful scope: read of the output folder, and which formats are included. It omits ordering guarantees (is "most recent" ascending or descending?), whether results are truncated by the limit, and whether it errors when the folder is absent.

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

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

One tight sentence with the key scoping information front-loaded and no filler. Nothing is bloated; it is simply short on 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?

An output schema exists, so return values need not be explained. However, for a listing tool with an undocumented limit parameter and ambiguous sort order, the description leaves real gaps an agent would need resolved.

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

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

The single parameter "limit" has 0% schema description coverage and is never mentioned in the description, so its semantics (count of files, default 30) are completely undocumented. 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 ("Lista") and resource ("os arquivos mais recentes na pasta de saída") plus the file formats covered, so an agent knows exactly what it returns. It does not explicitly contrast with siblings like open_file or freecad_run_file, keeping it from a 5.

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

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

No statement of when to call this versus alternatives, no prerequisites, no mention of what happens if the output folder is empty. The agent must infer usage entirely from the purpose sentence.

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 burden. It usefully discloses the evaluation criteria and the default printer profile, but says nothing about whether it is read-only, whether it is expensive/long-running on large meshes, or what happens on a failed/uncached check. Since an output schema exists, the missing return-format detail is acceptable, but the safety/cost profile is left unstated.

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 with zero filler, front-loading the check criteria and then the default profile. Slightly compressed to the point that the defaults sentence reads as a fragment rather than a complete explanation.

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

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

An output schema exists, so return values need not be described. But for a 7-parameter tool with zero schema text and no annotations, the description should still cover path semantics and max_overhang_deg, which it does not — the definition is adequate but leaves an agent guessing on key inputs.

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 7 parameters, so the description must compensate. It partially does: 'Bambu Lab A1 (256³), bico 0,4, camada 0,2' maps to bed_x/y/z_mm, nozzle_mm and layer_mm defaults. However, path, max_overhang_deg and the unit/format expectations for path are never explained, leaving real 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?

Names a specific verb+resource (FDM printability check) and enumerates exactly the criteria evaluated: watertight mesh, separate bodies, minimum dimensions, overhang area, bed contact, orientation ranking. It never distinguishes itself from the sibling mesh_measure or mesh_render, so an agent could not confidently choose 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?

Usage is only implied — an agent can infer this is a pre-print validation step, but there is no explicit when/when-not, no mention of prerequisites (e.g. that the mesh must already be loaded or a path supplied), and no pointer to mesh_measure for plain dimension queries.

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 computed metrics and one behavioral assumption ('massa estimada em PLA'), and the verb 'Mede' implies a non-destructive read. However, it does not explicitly confirm read-only behavior, permissions, units, or error conditions.

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

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

The description is a single front-loaded sentence that lists the operation and its outputs without filler. Every element contributes to identifying what the tool measures.

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 an output schema, so return values need not be explained in detail, and the description covers the main purpose and supported formats. Still, for a one-parameter tool with no annotations, it leaves the path parameter and measurement units implicit, which is a meaningful gap 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?

The schema documents only one required parameter, 'path', with 0% description coverage. The description partially compensates by naming the supported file types (STL/3MF/OBJ), which tells the agent what kind of path is expected, but it never explains path format, relative vs. absolute paths, or other path-related requirements.

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

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

The description uses a specific verb ('Mede') and resource ('STL/3MF/OBJ') and enumerates the measured outputs (bounding box, volume, PLA mass estimate, faces, watertightness). It is clear what the tool does, though it does not explicitly distinguish itself from the sibling mesh_check_printability, which may also involve watertightness.

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 states what is measured but gives no guidance on when to use this tool instead of siblings such as mesh_check_printability or mesh_render, and it names no prerequisites or exclusions. Usage is only loosely implied by the measurement verb.

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 format (PNG) and that rendering is for inspection, but says nothing about where the file is written, whether it overwrites existing files, or what the call returns (a path? nothing?), which matters for a file-producing tool.

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

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

Two sentences, zero waste: the action and output come first, then the one parameter that genuinely needs enumeration. Nothing is redundant with the schema.

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 annotations and no output schema, yet the description still covers the essential gap: the views enumeration. The remaining ambiguity (where the PNG lands) is a real gap but minor.

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

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

Schema coverage is 0%, so the description must compensate. It does well for `views` (lists all seven valid values and the comma-separated format, which the schema lacks), but adds nothing for `path` and `size_px` beyond their obvious names and defaults.

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

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

States a concrete verb+resource and output artifact: 'Gera um PNG da malha para inspeção visual'. It distinguishes itself implicitly from analysis siblings (mesh_measure, mesh_check_printability) by framing the output as a visual artifact, but never names or contrasts those siblings explicitly.

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

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

'para inspeção visual' implies the when (visual QA rather than numeric measurement), but there is no explicit guidance on when to prefer this over mesh_check_printability or mesh_measure, and no prerequisites stated for `path` (must the mesh already be loaded/opened?).

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 key side effect — it hands the file to an external GUI application — but says nothing about whether the call blocks or returns immediately, what happens if no default app is registered, or whether it mutates anything.

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 mechanism stated before the examples; nothing wasted and nothing buried.

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

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

An output schema exists, so return values need not be explained, and the description covers purpose and dispatch behavior adequately for a one-parameter tool. The remaining gap is the lack of differentiation from freecad_run_file, which matters given the sibling set.

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 'path' parameter, so the description must compensate. The extension-based examples hint that the path determines which application is launched, but it never states path format (absolute vs relative), or error behavior for unknown extensions.

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 ('o arquivo') plus the mechanism (default system application), with concrete dispatch examples (3MF → Bambu Studio, FCStd → FreeCAD) that make the behavior unambiguous. It does not explicitly contrast with the sibling freecad_run_file, which also operates on a file, so the agent must infer the distinction from the examples.

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 'use this to view/open a file' but there is no statement of when to prefer freecad_run_file or freecad_run instead, nor any preconditions (file must exist, extension must be associated).

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