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

With no annotations, the description carries the full burden and does well: it discloses that analysis is static (no execution), enumerates detection categories, flags timeout risk, and states the return is a human-readable report. It does not explicitly state that it never modifies the script or detail failure/error behavior, but the safety profile is strongly implied.

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

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

Front-loaded with the core action, followed by a compact detection list and return-format note. Every sentence earns its place with no repetition or 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 one-parameter static analysis tool with an output schema, the description covers what the tool does, what it detects, and what it returns. Minor gaps remain around explicit non-mutation guarantees and error semantics.

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

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

There is one required parameter ('script') with 0% schema description coverage, so the description must compensate. It implies the parameter is EisenScript source but does not describe accepted syntax or format beyond that implication.

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

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

States a specific verb ('Lint') and resource ('an EisenScript') and adds the key qualifier 'without running it'. The list of detected issues makes the purpose concrete, but no sibling tool (notably validate_script) is named to distinguish it 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 'without running it' and the timeout-risk note, suggesting pre-render static checking. However, there is no explicit when-to-use versus validate_script, preview_script, or render_script guidance, and no stated 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?

With no annotations, the description carries the full burden. It usefully discloses the 'libssynth backend' and that timeout-avoidance guidance is included, which is real context, but it never states that the tool is a side-effect-free static lookup, how large the returned text is, or that it requires no engine state. An output schema exists, so return structure is covered elsewhere.

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 first and then lists coverage. Every clause earns its place; the only flaw is the slightly fragmented list phrasing, which reads more like a table of contents than prose.

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 static reference with an output schema and no annotations, the description gives enough: what it contains and what backend it targets. A sentence on when to reach for it over validate_script or analyze_script would close the remaining gap.

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

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

The tool takes zero parameters, so the baseline of 4 applies. There is no parameter meaning the description needs to disambiguate, and nothing it says misleads 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 names a specific artifact (an EisenScript language cheat sheet) and enumerates its coverage areas: primitives, transformations, modifiers, preprocessor, and timeout tips. It is clearly a static reference resource, distinguishable in kind from action siblings like validate_script or render_script, though it never says explicitly it is a documentation lookup rather than a script operation.

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

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

Usage is only implied: an agent can infer it should read this before authoring or debugging EisenScript. There is no explicit 'use this when...' guidance, no mention of pairing it with validate_script or preview_script, and no statement of when it is unnecessary.

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 that the tool reports a path and may return install help if the binary is missing, which implies a read-only status check. It does not clarify permissions, whether it verifies existence, or platform/path caveats, so behavioral context is adequate but not rich.

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

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

The description is a single wasted-free sentence that front-loads the primary action and appends the conditional fallback. It is appropriately sized for a simple status tool.

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

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

The tool is simple, has no parameters, and has an output schema, so the description need not explain return values. It communicates the main outcome and missing-install fallback, though the phrase 'install help' remains slightly vague.

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

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

The tool has zero parameters, so there are no parameter semantics to explain. The baseline for zero-parameter tools is 4, and no additional parameter context is 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?

The description gives a specific verb and resource: it reports the path of the ssynthgen engine binary. It also states a conditional fallback behavior, install help if missing. It is clear without relying on the title, though it does not explicitly differentiate itself from the many rendering/preview siblings.

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

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

Usage is implied as a diagnostic check for the engine binary path or missing-install help. There is no explicit guidance on when to choose this over other tools or when not to use it, so it meets the minimum viable threshold but leaves selection mostly inferred.

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

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

With no annotations, the description carries the full burden, and it does add genuine value by disclosing the `trimesh` dependency and how to install it. However, it does not say whether an existing output file is overwritten, where output lands when output_path is empty, or whether the conversion can fail on unsupported geometry.

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

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

Two short sentences: the action and supported targets come first, and the dependency caveat follows. Nothing is padded and the prerequisite is not 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-value explanation is not required, and the format list plus dependency note cover the essentials. Still, for a file-writing tool the unspecified default output location and overwrite behavior are meaningful gaps an agent would want closed.

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 description usefully supplies the accepted format values (stl, glb, gltf, ply, off) that the schema leaves as an unconstrained string with a default. It says nothing about the semantics of an empty output_path default, leaving one of three parameters unexplained.

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

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

States a specific verb and resource (convert OBJ to another mesh format) and enumerates supported targets, so the agent knows exactly what the tool produces. It is clearly distinct in function from siblings like preview_obj and send_to_unreal, but never says so explicitly.

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

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

The phrase 'a rendered OBJ' implies obj_path must come from a prior render step, so usage is inferable but never stated. No alternatives are named (e.g., when to use this instead of send_to_unreal), and no preconditions beyond the optional dependency are given.

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

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

No annotations are provided, so the description carries the full burden. It implies a read-only fetch of bundled content, but says nothing about behavior when the name doesn't match a bundled example (error vs. empty), or whether the returned source is the raw bundled file.

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

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

One front-loaded sentence with no filler; the verb and the scope of the return value come first.

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

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

The output schema covers the return shape and the tool is a simple single-parameter read, so much of the burden is lifted. Still missing is how to discover valid names and the failure mode for an unknown name — key gaps for the only input.

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 single parameter 'name' is undocumented in the schema, so the description must compensate. It only implies the name is that of a bundled example, without stating where valid names come from or whether matching is case-sensitive.

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

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

States a specific verb and resource: 'Return the full EisenScript source of a bundled example by name.' This clearly separates it from list_examples (enumeration) and eisenscript_reference (documentation), though it never names those siblings explicitly.

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

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

Usage is only implied: 'by name' hints that a name must be known beforehand, but the description never says to call list_examples first, nor does it name any alternative tool. An agent must infer the workflow.

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 context. It does disclose that entries carry 'short descriptions' (so it is not the full script content), but it says nothing about read-only safety or whether the catalog is static or bundled.

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

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

One short sentence, front-loaded with the verb and resource, with zero filler. It is efficient, though a little thin for routing.

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 and there are no parameters, so little is needed. Still, the relationship to get_example is unclear, so an agent cannot tell from this text whether listing also returns the script bodies.

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

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

The tool takes no parameters, so the baseline is 4. The description correctly implies no input is required.

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

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

The description states a specific verb and resource: listing bundled EisenScript examples, each with a short description. It is clear on its own, but it does not distinguish itself from the sibling get_example, which plausibly returns the same catalog or an individual entry.

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

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

There is no explicit guidance on when to use this tool rather than get_example or eisenscript_reference. The discovery use case is only implied by '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?

With no annotations present, the description carries the full disclosure burden, and it does add real context: the matplotlib Agg backend and CPU-only rendering tell the agent this is a lightweight, headless, non-GPU path. It does not cover failure behavior for missing/invalid OBJ files or whether the render is a low-fidelity approximation, which 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?

A single front-loaded sentence with the verb, input, output, and runtime constraints packed in. Every clause adds information; nothing is wasted.

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

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

An output schema exists, so return values need not be explained, and the tool is simple with only two parameters. Still, with zero annotation and zero schema-description coverage, the description should resolve the output_path default and file-existence expectations, and it does neither.

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 only loosely maps the two parameters: the OBJ file corresponds to obj_path and the PNG output to output_path. It never explains what an empty output_path (the schema default) does, which is the main ambiguity an agent would hit.

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

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

States a specific verb and resource (render an existing OBJ file) plus the output format (PNG preview), which is enough to tell it apart from script-oriented siblings like render_script and preview_script. It does not explicitly name those siblings, 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?

The phrase 'existing OBJ file' implies this tool is for files already on disk rather than for scripts, which is an implicit cue versus render_script/preview_script. However, it never states when to choose this over those alternatives or any exclusions, so the guidance stays at the implied level.

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

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

With no annotations, the description does add real behavioral context: matplotlib Agg, CPU-only execution, and grammar group-color preservation. It omits the file-writing side effects of a preview (does output_path overwrite?), timeout behavior, and failure modes, which matter for a tool that produces files.

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, front-loaded with the purpose and output, no filler. Every sentence adds information, though the content is thin given the undocumented parameters.

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

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

An output schema exists, so return values needn't be explained, but the description is still incomplete: none of the four inputs are characterized, there are no annotations, and the file-writing behavior of a preview tool with an output_path is unaddressed.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning, but it says nothing about any of the four parameters. The script input, the seed, the 120-second timeout, and especially output_path (which clearly controls the returned preview path) are all left unexplained.

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

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

States a specific verb and resource ('Render an EisenScript') and names the concrete outputs (PNG preview path plus OBJ). It never mentions sibling tools like preview_obj, render_script, or validate_script, so an agent can't tell from the text alone why this differs from those.

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

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

The word 'preview' and the note that it is CPU-only, no-GPU imply a lightweight check before a full render, but there is no explicit when-to-use or when-not-to-use guidance and no alternative is named. Usage is inferable but never 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 behavioral burden. It discloses that this batch-renders all bundled examples, writes OBJ and PNG files into a directory, and is useful for regression checks. However, it does not mention overwrite behavior, error handling, permissions, or how timeout and seed affect execution, which are important for a file-writing batch operation.

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

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

The description is two concise sentences with the core action front-loaded and no wasted text. The second sentence adds useful context without bloating the definition.

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

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

The output schema covers return values, and the description clearly states what is produced and why it is useful. But with no annotations and 0% schema description coverage, it should do more to explain required output directory behavior, preview toggling, timeout, and seed defaults.

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 explain the four parameters. It only implicitly references out_dir through 'in a directory' and with_preview through '+ PNG'; it says nothing about seed or timeout, leaving most parameter semantics undocumented.

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

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

The description states a specific verb and resource: batch-render every bundled example to OBJ and PNG in a directory. It clearly distinguishes this batch gallery operation from single-script rendering siblings such as render_script or preview_script, even without naming them.

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

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

It gives clear usage context: building a visual gallery or checking regressions. It does not state when not to use it or explicitly compare it with render_script or preview_obj, so it falls short of full when/why-not/alternatives 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?

With no annotations, the description carries the full burden and does a decent job: it discloses the temp-file fallback when output_path is empty, that a seed is injected as `set seed N`, and that timeout aborts runaway scripts. It omits whether an existing file at output_path is overwritten and says nothing about sandboxing or resource limits for script 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 stated in a single opening line, followed by a tight args list and a one-line return summary. No restated boilerplate and no wasted sentences.

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

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

Output schema exists and the description still summarizes the return shape (path, counts, bbox), so return values are covered. The remaining gap is over-write behavior on output_path and lack of routing guidance versus preview_script/validate_script, which matters for a tool that writes to disk with no annotations.

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 entirely, and it does: all four parameters get meaningful explanations beyond their titles (full source text, empty-string temp-file behavior with path returned, reproducibility semantics of seed, abort semantics of timeout). This is exactly what a low-coverage schema needs.

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+output format: 'Render EisenScript to a Wavefront OBJ mesh'. An agent immediately knows what goes in (EisenScript source) and what comes out (an OBJ file). It is clearly distinct from sibling tools like preview_script or validate_script, though it does not name them.

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

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

The description implies usage (you have EisenScript and want a mesh file) but never states when to use this instead of preview_script, validate_script, or analyze_script, which are the obvious alternatives in the sibling list. No prerequisites or exclusions are given.

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

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

With no annotations, the description carries the full burden, and it does disclose the TCP prerequisite and the landing location of the asset (content browser at dest_path, default /Game/Imported). However, it never says what `replace=true` does to an existing asset, whether a failed partial import can leave the editor in a dirty state, or how the destination folder is created — meaningful gaps for a mutating import.

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 lines, front-loaded with the action and followed by the environment precondition and the outcome location. No filler, no restatement of the tool name. The terseness is appropriate for a pipe-style import tool.

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 needn't be described, and the environment/port context is well covered. But for a 4-parameter mutating tool with zero annotation coverage and zero schema descriptions, omitting the semantics of `name` and `replace` leaves the definition short of what an agent needs to call it safely.

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 only partly does: dest_path is explained with its default, and obj_path is implied by 'rendered OBJ'. The `name` and `replace` parameters are completely unaddressed anywhere, leaving half the surface undocumented — a real risk for `replace`, which appears to control overwrite behavior.

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 (import), resource (a rendered OBJ), and target (a running Unreal Engine editor) plus the transport (TCP bridge). This is unmistakably different from the sibling names that surround it (export_mesh_tool exports, preview_obj previews, engine_status reports), so an agent can route correctly without opening a schema.

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

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

Gives a concrete precondition — Unreal must be running with the MCP plugin listening on 127.0.0.1:55557 — which effectively tells the agent when this call can succeed. It does not name alternatives or say what to do when the bridge is down (e.g., check engine_status first), so it falls short of a full when/when-not treatment.

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 usefully discloses that geometry is not retained and that output is 'OK' or an error message, but says nothing about whether the script is actually executed, whether a running engine is required (engine_status is a sibling), or how errors are formatted.

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 the key behavioral constraint, with no filler. Nothing could be cut without losing information.

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

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

The tool is simple and an output schema exists, so return-value detail is a bonus rather than a requirement. Still, for a validator the description omits the practical context an agent needs: engine dependency, cost/safety of running it, and how it fits into the preview-then-render workflow.

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

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

Schema description coverage is 0% for the single required parameter, so the description must compensate and largely does not. It never clarifies whether 'script' is raw EisenScript source text, a file path, or an identifier — a meaningful ambiguity for a one-parameter tool.

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

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

Specific verb (check) plus resource (EisenScript) and the exact failure class it detects (syntax/parse errors). The phrase 'without keeping geometry' implicitly separates it from render_script/preview_script, though it never names those siblings, so differentiation is inferential rather than explicit.

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

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

Usage is only implied: the 'without keeping geometry' clause suggests validating before committing to a render, but there is no stated when-to-use, no exclusion, and no guidance on choosing between this and analyze_script or preview_script, which are equally plausible siblings for a script-input tool.

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