LetX

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the description's real value is explaining the *mechanics* of that destruction: the source is saved to the user's "AI Scratchpad" project, files of the same name are replaced, and earlier versions survive in project history. It also discloses return behavior (PDF download link plus LaTeX errors on failure) and the text-only input constraint. It stops short of naming auth/permission requirements or size/time limits, so 4 rather than 5.

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 purpose and the project-free scoping in the first clause, then side effects and return values. Four sentences all carry information; only the compiler-default remark is arguably redundant with the schema. No filler or restatement of the tool name.

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

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

No output schema exists, yet the description supplies return semantics (PDF download link, LaTeX errors when compilation fails). For a 3-parameter tool with a persistence side effect, the description covers input constraints, side effects, history behavior, and outputs — nothing an agent needs to call 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 schema already documents main_tex, files[].path/content, and the pdflatex/xelatex/lualatex options. The description adds only a mild constraint (text files only, no images) on the files parameter and nothing on format or syntax the schema doesn't already carry. Baseline 3 is correct.

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 (compile LaTeX source to PDF) and immediately scopes it against the sibling project-based path: "without choosing a project: the main .tex content plus optional extra .tex, .bib or .sty files." An agent can distinguish it from compile_project without opening either schema.

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

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

Explicitly names the triggering condition ("Use when the user wants a PDF of LaTeX that is in the conversation") and the implicit alternative is disambiguated by "without choosing a project" and "Text files only, no images." Both when-to-use and when-not are inferable with no guessing.

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

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

Annotations declare readOnlyHint=false and idempotentHint=false, and the description adds real value on top: it discloses that compilation returns a PDF link and, on failure, surfaces LaTeX errors from the log rather than a bare error. It does not say where the PDF is stored, whether results are cached, or what permissions are needed, so it falls short of a 5.

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 action, then usage, then return behavior. No filler and nothing important 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?

With no output schema, the description correctly compensates by explaining the return value (PDF link plus LaTeX errors) and the usage trigger. The remaining gap is the missing differentiation from compile_latex and the absence of any note on permissions or artifact location.

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 only one parameter and schema description coverage is 100%, so the schema already fully documents project_id. The description adds no format, scoping, or sourcing detail beyond it, which is the expected baseline 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 and resource ("Compile one of the user's letX projects"), so the action is unambiguous. However, it never distinguishes itself from the very close sibling compile_latex, leaving the agent to guess which compile tool applies to a project versus raw LaTeX.

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 two concrete triggering situations: the user wants a PDF, or wants to verify the project builds. That is clear context for when to use it, but there are no exclusions or explicit routing to the sibling compile_latex.

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

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

Annotations already declare this is a non-read-only, non-destructive, non-idempotent write, so the safety bar is largely covered. The description adds useful behavior beyond that: main.tex is required, and the call yields a project id and an editor link. It omits auth/permission requirements and what happens on duplicate names, keeping it below 5.

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

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

Three tight sentences: purpose and required input first, then the usage condition, then the return value. No filler or redundancy; every sentence carries load.

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 compensates by naming the return values (project id, editor link), and it covers the required-file constraint and when to use it. Missing pieces are minor: no error/duplicate behavior and no explicit pointer to the template-creation sibling.

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% and all three parameters (name, files, compiler) are documented in the schema itself, including the compiler enum values and the main.tex expectation. The description adds nothing beyond that baseline, so a 3 is correct.

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 ('Create a new letX project') plus the input source ('from LaTeX files'), and flags a required artifact (main.tex). It implicitly differentiates from create_project_from_template by specifying files rather than a template, but never names a sibling explicitly, 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?

It states a clear when-to-use condition: 'Use when the user wants their document saved as a letX project they can open, share and keep editing.' No exclusions or named alternatives are given (e.g. when to prefer create_project_from_template or create_project_from_template vs compile_project), so it misses the 5 criteria.

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

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

Annotations already declare non-readonly, non-idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds real value by disclosing the scoping ('for the connected user') and the return payload (project id plus editor link), which is important since there is no output schema.

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

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

Three short sentences, zero filler, front-loaded with the action and the when-to-use condition before the return description. 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 single-parameter creation tool with no output schema, the description covers the action, the trigger, and the return shape, which is what an agent needs. Minor gap: no pointer to the sibling that lists/searches templates for obtaining the slug.

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

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

Only one parameter and schema description coverage is 100%, so the schema already defines 'slug'. The description restates it as 'a template slug' without adding format, discovery, or validation detail (e.g., where to obtain the slug), so it stays at the baseline.

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 (create), resource (letX project), actor (connected user), and source (template slug). The 'from a template slug' qualifier distinguishes it from the sibling create_project, which presumably creates a blank project.

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 when the user wants to start a document from a template' gives a clear triggering condition. It stops short of naming the alternatives (create_project for blank projects, search_templates/get_template for discovering slugs) or stating when not to use it.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds only that this is a 'minimal fetch interface for clients that expect one', which is useful framing but discloses nothing about return shape, error behavior on a bad id, or the odd idempotentHint=false.

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 resource, with the routing note trailing. Minor hedging in 'for clients that expect one', but no sentence is padding.

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

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

For a one-parameter read tool with annotations covering safety, the description supplies enough to call it correctly and indicates that the complete record is returned. Since no output schema exists, it could say slightly more about what 'full record' contains, but complexity is low.

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 with 100% schema description coverage, so the schema already defines 'id' as the template record's id. The description's 'by its id' restates the structured field without adding format, source, or lookup semantics, so the baseline of 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?

States a specific verb and resource ('Fetch one letX LaTeX template record by its id') and frames itself as the minimal, single-record fetch. It does not, however, distinguish itself from the sibling 'get_template', which an agent would reasonably expect to do the same thing.

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 clear triggering context: use it when the full record of a template previously found via search is needed, which chains naturally off 'search_templates'/'search'. No explicit exclusion versus 'get_template' is offered, so the agent must guess between the two.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful note that results include a hosted page on letx.app, but says nothing about failure modes for a bad slug, auth needs, or rate limits. Note idempotentHint=false is unusual for a pure lookup, but the description does not contradict it.

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

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

Two sentences, zero filler, and the core action plus returned fields are front-loaded before the usage clause. 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?

There is no output schema, so the description correctly compensates by enumerating the returned fields (description, author, license, preview image, page URL). For a single-parameter read tool this is nearly complete; only error behavior for an unknown slug 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?

Only one parameter with 100% schema coverage ('the template's slug'), so the schema does the documentation work. The description repeats 'by its slug' without adding format, URL-encoding, or lookup-resolution guidance. Baseline 3 is appropriate.

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 ('Get one LaTeX template's full details by its slug') and enumerates the returned fields, so the agent knows exactly what comes back. It implies the contrast with search_templates by emphasizing a single template, but never names that sibling, 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?

Gives a clear trigger: 'Use when the user wants to know more about a specific template.' That is enough to select it over listing tools, but it stops short of naming alternatives (e.g. search_templates for discovery) or stating when it should not be used.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false, so the safety profile is covered; the description adds substantive context the annotations lack, namely that the result enumerates both documents and uploaded assets and returns their exact paths. It still says nothing about ordering or pagination, so it is not fully transparent.

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 redundancy, with the core action and scope front-loaded and the usage cue second. 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 simple one-parameter read tool whose annotations carry the safety profile, the description covers what is listed and what comes back (paths). It is short of complete only because ordering/pagination behavior is unstated and there is no output schema to cover 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 100% for the single project_id parameter, so the baseline is 3. The description reinforces that the call is scoped to one user's project but adds no format or sourcing detail beyond the schema.

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

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

States a specific verb (list) and resource (documents and uploaded assets within a single letX project), plus the scope restriction to one project. This implicitly separates it from list_projects (all projects) and read_project_file (single file content), so an agent can place it among the 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?

"Use when the user asks what a project contains or a file path is needed" gives a clear triggering context. It does not name alternative tools or state when NOT to use it (e.g., when only a single file's contents are needed, read_project_file is better), so it falls short of the top level.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuine value by disclosing the returned content (name, id, last update), which is the only source of return-shape information since no output schema exists. It omits ordering, scoping, and pagination behaviour.

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 purpose front-loaded before the usage trigger. 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?

For a zero-parameter read-only list tool with no output schema, the description covers purpose, trigger, and returned fields adequately. It could be more complete by clarifying scope (single user/workspace) and how results are ordered.

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; the baseline of 4 applies. The schema is an empty object at 100% coverage, so no compensation 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?

States a specific verb (List) and resource (the connected user's letX projects) and even names the returned fields (name, id, last update). It does not, however, differentiate itself from near-neighbour siblings such as list_project_files or get_template, which is the main risk given 13 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 reach for it: when the user refers to their letX projects or when a project id is needed. That is clear context, but there are no exclusions or named alternatives (e.g., when to prefer list_project_files instead).

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered and the description adds little beyond a docs link. Notably idempotentHint=false on a pure read is counterintuitive and is left unexplained, and nothing is said about missing-path errors or output size limits.

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

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

Two short sentences plus a docs URL, with the core action front-loaded and no filler. The 'or wants it changed' clause is the one mildly wasteful/confusing phrase.

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 two-parameter read-only tool with no output schema, the definition covers what it reads and where. Gaps are minor: no mention of what a failed lookup returns or that content comes back as raw text.

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 both project_id and path are already documented in the schema, including the same path examples the description repeats. The description adds no syntax, relative-vs-absolute, or resolution guidance beyond that baseline.

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

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

States a specific verb and resource ('Read a document ... from one of the user's letX projects') and gives concrete path examples, so an agent immediately knows what it does. It does not explicitly distinguish itself from siblings like update_project_file or list_project_files, relying on the read/write contrast being obvious.

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 when the user asks about a file in a project or wants it changed' gives a trigger condition, but the second clause is oddly worded for a read tool and no alternative is named. Nothing tells the agent to call list_project_files first to discover a valid path, which matters given a required path parameter.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds useful context about the result fields and the fact that the library is free/public, but says nothing about result limits, pagination, or why idempotentHint is false for a read-only search.

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 with the purpose front-loaded and no wasted phrasing. Slightly redundant to state both 'minimal search interface for clients that expect one' and the when-to-use clause, but efficient overall.

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 read-only search with no output schema, the description usefully discloses the returned fields (id, title, URL), which covers the main gap left by the missing output schema. Only pagination/result-count behavior is unaddressed.

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

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

Schema description coverage is 100% for the single 'query' parameter, so the schema already carries the burden. The description adds no syntax, matching behavior, or filtering guidance beyond what the schema provides, which is the baseline 3 case.

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 ('Search letX's public library of free LaTeX templates') and even sketches the return shape (id, title, URL). It partially differentiates itself from the sibling search_templates by calling itself 'basic' and 'a minimal search interface,' but it never names that sibling, so the distinction is implied 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?

'use when the user is looking for a LaTeX template' gives a clear positive condition, but that condition applies equally to the sibling search_templates. There is no exclusion or preference rule, so an agent cannot tell which of the two search tools to pick from the description alone.

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

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

Annotations already disclose the safety profile (readOnlyHint=true, openWorldHint=false), so the bar is lower. The description adds genuinely useful behavioral detail that annotations cannot: it discloses the return shape (matching templates with slug, category and preview link), which matters because no output schema exists.

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 and library scope, followed by the usage trigger and return fields. The parenthetical category list is somewhat long but earns its place by conveying domain coverage; 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?

With no output schema, the description helpfully compensates by describing returned fields (slug, category, preview link). Combined with annotations covering safety and the fully documented schema, an agent has enough to call this correctly, though result ranking/pagination behavior is unstated.

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

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

Schema description coverage is 100%, so both parameters are already documented in the schema, establishing a baseline of 3. The category examples in the description (journal formats, universities, posters) loosely echo the category slug filter but add no syntax or constraints beyond the schema.

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

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

States a specific verb (search) and resource (LaTeX template library), and scopes it with size (1000+), domain (university theses, journal formats, CVs, posters) and use case. It is clearly distinguishable from get_template, which fetches one template, though the description never names 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?

Gives an explicit trigger: 'Use when the user wants a LaTeX template or a starting point for a document.' This is clear context for invoking the tool, but it offers no exclusions or routing to siblings like get_template or create_project_from_template.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description usefully adds that the default engine is set at project creation, but it never says whether changing the engine recompiles or invalidates existing outputs, or whether the change applies only to future builds — a real gap for a project-level mutation.

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

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

Three sentences, purpose front-loaded, then value-selection rules, then usage trigger. No filler; each sentence carries information the agent needs to act correctly.

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

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

For a two-required-param, no-output-schema tool with full schema coverage, the description covers purpose, value choice and trigger. Only the post-change effect (recompilation/regeneration of output) is unstated, which is a minor but real omission.

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, and the description goes beyond it by giving decision criteria for the enum-less 'compiler' string (which LaTeX packages/document features require which engine). project_id is left to the schema, which is fine since it is self-describing.

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 ('Set the TeX engine a project builds with') and immediately enumerates the three legal values. It also implicitly separates itself from create_project by noting 'letX picks an engine when a project is created', so an agent can distinguish it from the sibling that creates projects.

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

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

Gives an explicit trigger ('Use when the user asks for a different engine or the document needs one') plus per-document routing rules: fontspec/unicode-math/polyglossia/xeCJK need xelatex or lualatex, and \directlua/luacode needs lualatex. That is more than context — it tells the agent which value to select and why.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true; the description adds meaningful context beyond them by explaining the replace-vs-create branch and that the previous version is preserved in letX history and can be undone. That softens an otherwise destructive operation. It omits permission/auth requirements and failure modes, so not a 5.

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

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

Two tight sentences front-load the create/replace semantics, then the history/undo consequence, then the usage trigger. No sentence is redundant and the docs link is a brief appendix.

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 3-required-param write tool with no output schema and annotations covering the safety profile, the description covers create/replace behavior, reversibility, and when to invoke it. It does not address error cases (missing project, path conflicts) or what the call returns, leaving a small 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?

Schema description coverage is 100%, so the schema already documents path, content, and project_id, including the 'FULL new content' replacement warning and the create-if-absent behavior at the path level. The description reinforces but adds no syntax or format detail beyond the schema, so the 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?

States a specific verb pair and resource: 'Create or replace a document in one of the user's letX projects.' An agent can immediately separate it from read_project_file, list_project_files, and create_project without consulting any schema.

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

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

Gives a clear trigger condition: 'Use when the user asks to change or add a file in a project,' which pins it to file writes rather than project creation. It does not explicitly name the alternative (read_project_file) or state when NOT to use it, so it falls short of full routing guidance.

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