LetX

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

All annotation hints are false, so the description carries the transparency burden. It discloses the execution backend ('real TeX Live compile farm'), the possible outcomes (PDF link or compile errors), and a side effect (source saved to AI Scratchpad). This goes well beyond what the schema or annotations convey.

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, no fluff. The core action is front-loaded, followed by return behavior, limitations, and side effects. Every sentence earns its place and supports correct usage.

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-parameter tool with complete schema coverage and no output schema, the description covers everything an agent needs to call it safely: what it does, what it returns, side effects, and when to use an alternative. No critical gaps are visible.

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 a baseline of 3 is appropriate. The description restates that main_tex is the content and files are optional, adding little semantic detail beyond the schema. The 'text files only' note is a useful constraint but is largely redundant with the files parameter description.

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

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

The description states a specific verb ('Compile'), resource ('LaTeX source to a PDF'), and key differentiator ('without picking a project'). This clearly separates it from compile_project and other siblings. The main_tex input is also identified as the primary content to pass.

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 explicitly frames the tool as standalone ('without picking a project'), implying compile_project for project-based workflows. It also gives a concrete exclusion: 'only text files are supported here, so projects with images should be created via create_project and edited in letX.' This tells an agent exactly when to use an alternative.

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 indicate this is not read-only, not idempotent, and not destructive. The description adds useful failure behavior disclosure by mentioning that compile log errors are returned on failure. However, it does not disclose potential side effects, compilation duration, or whether this is a long-running operation, which would be valuable for a compile action.

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 sentence that front-loads the action and resource, and efficiently captures both success and failure outcomes. There is no redundant wording 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 single-parameter tool with no output schema, the description adequately explains the return value on success and failure. It is missing minor context such as expected latency or side effects, but the core information needed to call and interpret the tool is present.

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

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

The input schema covers 100% of the single parameter and already indicates it is the project id from list_projects. The description does not add new parameter-level meaning beyond restating that it compiles a user's project. Baseline of 3 is appropriate given full schema description coverage.

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

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

The description clearly states that the tool compiles one of the user's letX projects and returns either a PDF link or compile log errors. This is a specific verb-resource pairing that makes the tool's function understandable. However, it does not explicitly distinguish itself from the sibling compile_latex, so it lacks direct sibling differentiation.

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

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

The description gives no guidance on when to use this tool versus compile_latex or other siblings. It implies it is for letX projects, but does not explicitly state exclusions or alternatives. The agent is left to infer the intended usage context from the name and sibling 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?

The description discloses the key behavioral outcome: the operation creates a new project and returns the project id and editor link. It also calls out the main.tex requirement. Since annotations are all false and provide little behavioral signal, this description reasonably carries the burden.

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 concise sentences with no filler. The key action and required input are front-loaded, and the return value is clearly stated in the second sentence.

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 three-parameter create tool with no output schema, the description is nearly complete: it states the inputs, the required file, and the return values. It does not explain routing to create_project_from_template, but that is a usage-guideline nuance rather than a blocking 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 parameters are already well documented. The description adds no new meaning beyond reiterating that main.tex is required, which is already stated in the files parameter schema. 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?

The description states a specific verb and resource: creating a new letX project from provided LaTeX files. It also distinguishes itself from the sibling create_project_from_template by emphasizing 'from provided LaTeX files', so an agent can tell them apart.

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

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

The description gives clear context for when to use this tool: when the agent has LaTeX files to provide, with main.tex required. It does not explicitly mention alternatives or when-not-to-use, but the 'from provided LaTeX files' phrasing implies the distinguishing use 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?

Annotations provide little useful behavioral information since all hints are false. The description adds meaningful context by stating the project is created for the connected user and that the response includes a project id and editor link, which is especially valuable given 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?

The description is two sentences with no filler: it states the action and source in the first sentence and the return value in the second. Key information is front-loaded and 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 simple one-parameter tool with no output schema, the description adequately covers creation and return values. It could be more complete by mentioning error behavior or explicitly routing the user to search_templates, but these are minor gaps.

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

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

Schema coverage is 100% and the single slug parameter is already documented as a template slug from search_templates. The description does not add significant parameter-level meaning beyond the schema, so the baseline score 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?

The description clearly states a specific action: creating a new letX project from a template slug. It also distinguishes the tool from the sibling create_project by making the template-slug source the defining input.

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 does not explicitly say when to use this tool versus alternatives such as create_project. It implies template-based creation but provides no direct usage guidance, exclusions, or conditions.

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

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

The annotations already provide readOnlyHint=true, so the read-only nature is covered structurally. The description adds useful context about the record type and the id provenance, but does not disclose behavior beyond that. The idempotentHint=false does not contradict the read-only implication because the description never claims idempotency.

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 compact sentences with no filler. The core behavior and id provenance are front-loaded, and the parenthetical efficiently handles the sibling distinction.

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, read-only fetch tool with high schema coverage and a clear sibling comparison, the description covers everything needed to select and invoke it correctly. The agent knows where the id comes from, that it is a read operation, and when to prefer get_template instead.

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%: the only parameter, id, is documented as 'document id returned by search'. The description largely repeats this same information, so it adds little semantic value over the schema. 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?

The description states a specific verb ('Fetch'), a specific resource ('one letX LaTeX template record'), and the required identifier source ('by the id returned from search'). It also distinguishes itself from the sibling get_template by clarifying this is the ChatGPT deep-research compatibility variant.

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 explicitly identifies when fetch is appropriate (as a ChatGPT deep-research compatibility tool) and points to the alternative get_template for other clients. This gives an agent a clear routing decision between fetch and get_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?

The readOnlyHint annotation already covers the safety profile, so the description needs less behavioral disclosure. It adds useful context by specifying the source of the slug and listing the payload fields, but it does not describe error behavior or the exact structure of the response beyond field names.

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

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

The description is one focused sentence that front-loads the primary action, identifies the parameter source, and lists the key return fields. There is no redundant or filler content.

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, read-only lookup tool with no output schema, the description is complete: it specifies the identifier, its origin, and the returned content. No critical operational detail is missing for an agent to call it correctly.

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

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

The input schema already documents the single slug parameter with 100% coverage, so the baseline is 3. The description adds only that the slug identifies a LaTeX template and comes from search_templates, which slightly reinforces but does not substantially expand parameter semantics.

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

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

The description clearly states a specific verb and resource: 'Get one LaTeX template's full details by slug'. It also enumerates the exact fields returned and distinguishes itself from the sibling list tool search_templates by requiring a slug produced by that tool.

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

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

The phrase 'from search_templates' gives clear context that this tool should be used after searching for templates and with a slug obtained from search_templates. It does not explicitly state when not to use it, but the intended workflow is easy to infer and no alternative detail-fetching tool competes with 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?

The annotations already declare readOnlyHint=true, so the tool's non-mutating nature is established. The description adds useful behavioral context beyond that: it enumerates what gets listed (documents and uploaded assets) and signals that the output is intended to supply exact paths. There is no contradiction with the annotations.

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

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

The description is two sentences with no filler. The core action and scope are front-loaded, and the usage guidance follows concisely. 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 simple, single-parameter, read-only listing tool, the description covers what is listed, the project scope, and how the result should be used with sibling tools. The absence of an output schema is mitigated by the clear statement that the tool returns exact paths for later read/update operations.

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 only parameter, project_id, is fully documented in the input schema as coming from list_projects. With 100% schema description coverage, the tool description does not need to repeat parameter details. It adds only contextual scope about the project, which is adequate.

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 and resource: it lists all documents and uploaded assets within a user's letX project. It clearly distinguishes itself from read_project_file and update_project_file by stating it provides exact paths, making the tool's scope and role unambiguous.

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

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

The description explicitly says to use this tool before read_project_file or update_project_file to get exact paths. This names the relevant alternative tools and gives a clear sequencing rule, so an agent knows exactly when to invoke this tool.

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

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

The readOnlyHint annotation already covers the safety profile, and the description adds useful scoping by saying 'connected user's projects.' It does not add further behavioral details like sorting, pagination, or access limitations, but for a simple read-only list this is acceptable.

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 sentence that front-loads the action and resource, lists the output fields, and adds a brief usage context. Every part contributes value; nothing is redundant.

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

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

For a parameterless, read-only list tool with no output schema, the description is complete: it states what is listed, whose projects, and what fields are returned. The simple nature of the tool means no additional details are needed.

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 and the schema fully documents this, so the description does not need to explain parameters. It accurately implies no filtering or arguments are 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 and resource: 'List the connected user's letX projects' and identifies the returned fields (name, id, last update). This clearly distinguishes it from siblings like list_project_files and compile_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?

The description gives clear context: use this to obtain projects so you can read, edit, or compile them. It does not explicitly name alternatives or exclusion cases, but the intended usage is evident.

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 idempotentHint=false, and the description aligns with readOnlyHint by saying 'Read'. The description adds some context about the scope ('user's letX projects') but does not disclose additional behaviors such as return format, error handling, or whether the file must exist.

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, focused sentence ending with useful examples. There is no wasted wording, and the core action and resource scope appear immediately.

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 read operation with two well-documented parameters and a readOnly annotation, the description is mostly sufficient. It could be more explicit about the return value (file contents) and what happens if the path is invalid, but the verb 'Read' plus the examples make the intended behavior reasonably clear.

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 both parameters well. The description mostly repeats examples already present in the schema, adding little new semantic value. It does reinforce that paths can be nested and that project_id comes from list_projects, but this is marginal.

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 ('Read'), a specific resource ('a document... from one of the user's letX projects'), and gives concrete examples (main.tex, chapters/intro.tex, refs.bib). This clearly distinguishes it from sibling tools like update_project_file or list_project_files by focusing on reading file content.

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 does not explicitly state when to use this tool versus alternatives. It implies read-only access, but it never mentions that update_project_file should be used for modifications or that list_project_files is for browsing file names. No exclusions or alternative routing are provided.

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 indicate read-only behavior, and the description adds that the tool returns only summary fields ({id, title, url}) rather than full records, with a clear pointer to fetch for more detail. This clarifies the tool's limited scope beyond the annotation hints.

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

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

Two compact sentences cover the resource, return shape, follow-up action, and tool differentiation with no wasted words. The most important operational information is front-loaded.

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

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

For a one-parameter, read-only search tool with no output schema, the description adequately explains what the tool returns and how to obtain full records. The sibling-tool context and annotations cover the remaining safety and usage concerns.

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 only parameter, query, is already fully documented in the schema as 'search terms'. The description adds no additional query syntax or formatting guidance, so it does not meaningfully extend the schema; baseline 3 is appropriate given 100% schema coverage.

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

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

States a specific verb and resource: searching letX's public library of free LaTeX templates. It also differentiates itself from search_templates by noting it is a ChatGPT deep-research compatibility tool and that search_templates gives richer output for other clients.

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 identifies the intended client context (ChatGPT deep-research) and names the alternative tool (search_templates) for other clients. It also states the follow-up action of passing an id to fetch the full record.

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, so the read-only nature is covered. The description adds useful context about what the tool returns (slug, category, preview link) but does not describe result limits, ordering, or matching behavior. This is acceptable for a simple search tool but adds only moderate behavioral detail.

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 concise sentences front-load the action and scope, then describe the return fields, then route to the alternative. Every sentence earns its place with no repetition of structural annotations.

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

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

For a low-complexity search tool with fully documented parameters and read-only annotations, the description is complete. It explains what results look like even though there is no output schema, and it points to get_template for follow-up details.

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%, with both 'query' and 'category' already well-documented in the input schema. The description mentions template categories and return fields but does not add meaningful parameter-level meaning beyond the schema, 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?

The description clearly identifies the action ('Search') and the resource ('letX's library of 1000+ free LaTeX templates'), and lists concrete types of templates to make scope obvious. It explicitly names get_template as the complement for full details, distinguishing this discovery/search tool from the detail-retrieval sibling.

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 that this tool is for searching and discovering templates, then explicitly instructs to 'Use get_template for full details.' This gives an agent a clear branching rule: search here first, then fetch details with get_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 flag the tool as destructive (destructiveHint=true), and the description reinforces this by framing it as overriding letX's automatic engine selection. It adds useful context beyond annotations: the tool exists to correct an automatic guess and the choice of compiler is tied to document feature requirements. No contradiction with annotations.

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

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

Three sentences, each earning its place: main action with valid values, concrete selection rules, and a clear 'when to avoid' signal. Information is front-loaded and free of fluff.

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 tool with two parameters, no output schema, and annotations covering the destructive nature, the description is complete. It covers purpose, valid input values, selection criteria, and when to call. Nothing needed for correct invocation 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?

Input schema already documents both parameters with 100% coverage, so the baseline is 3. The description adds substantive value by mapping compiler values to concrete use cases such as fontspec, unicode-math, polyglossia, xeCJK, and \directlua, helping the agent choose the right value. It doesn't add much for project_id, but that parameter is trivially sourced from list_projects.

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 and resource: 'Choose which TeX engine a project builds with' and enumerates the exact options (pdflatex, xelatex, lualatex). It clearly differentiates from sibling compile tools by focusing on build settings rather than compilation. The purpose is unambiguous and distinct.

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 provides when-to-use guidance: xelatex/lualatex for fontspec, unicode-math, polyglossia, xeCJK; lualatex for \directlua or luacode. It also states when not to call it, since letX auto-detects on creation and this tool is only for overriding that guess. This is model usage 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?

The description goes well beyond the destructiveHint annotation by explaining that 'a version snapshot is saved first, so the change can be undone from letX's history.' It also discloses the replace-vs-create behavior and emphasizes that content replaces the full document. This is exactly the kind of behavioral context an agent needs for a destructive write 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 sentences with no wasted words. It front-loads the core purpose, then adds the essential behavioral details and a practical caution. 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 write tool with three simple parameters and no output schema, the description is complete: it states what happens on create vs replace, confirms undoability via snapshots, and warns about preserving unrelated content. Combined with full schema coverage and the destructive hint annotation, an agent has everything needed to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already fully explains project_id, path, and content. The description reinforces that content is the 'FULL new content' and that path is created if missing, but it does not add substantial new parameter-level meaning. Baseline of 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?

The description clearly states the action: 'Create or replace a document in one of the user's letX projects.' It then specifies the two cases—existing path replaced, non-existing path created—which precisely distinguishes this from sibling tools like read_project_file or create_project. The verb-plus-resource framing is unambiguous.

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

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

The description gives clear operational guidance: 'Prefer reading the file first and preserving everything the user didn't ask to change.' This implies the correct workflow and cautions against overwriting content. It does not explicitly name read_project_file or state 'use this tool when modifying a file,' but the context is clear enough.

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