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

Annotations already mark this as destructive and idempotent, so the description adds value by clarifying what destructive means here: the project is removed from the active list rather than permanently destroyed. The explicit 'Requires human confirmation' warning is useful behavioral context beyond 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?

Two short sentences front-load the core action and effect, then add the critical human-confirmation requirement. There is no filler or redundancy.

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

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

For a single-parameter tool with destructive and idempotent annotations, the description is largely sufficient: it states the operation, its visible effect, and a key requirement. It could be more complete by noting whether archiving is recoverable or how it differs from deletion, but nothing essential is missing for making the call.

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

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

Schema description coverage is 0%, and the description does not explain projectId, its source, format, or how to obtain valid values from sibling tools like list_projects. The parameter name is self-explanatory to some degree, but the description adds no meaning beyond the input 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?

The description states a specific verb ('Archive'), a clear resource ('an Overleaf project'), and the concrete effect ('removing it from the active list'). This distinguishes it from siblings like delete_project or rename_project because archiving is framed as moving out of the active list rather than deleting or renaming.

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 archive_project versus delete_project or other sibling tools. 'Requires human confirmation' is a prerequisite/warning, not a usage rule, and there is no mention of when archiving is preferable to deletion or how to reverse the action.

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 idempotentHint and destructiveHint values; the description adds useful context beyond them by noting the typical 10-60 second compile time and the structured format of the returned diagnostics. This helps set expectations for a slow, non-read-only 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?

Two sentences, with the core purpose front-loaded and the timing note earning its place. There is no redundant filler or repetition of schema details.

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 description is adequate for a simple compile action and gives both output structure and timing, but it does not cover the meaning of engine and rootDoc, and it could route users to the right sibling tools for logs or PDFs. Given no output schema and no parameter descriptions, this is a clear but incomplete definition.

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

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

Schema description coverage is 0%, and the description does not explain the engine or rootDoc parameters. Only projectId is reasonably inferable from 'the project'; engine and rootDoc remain underspecified, placing a real burden on the agent.

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 and resource: it compiles an Overleaf project and returns structured LaTeX diagnostics. This distinguishes it from siblings like get_compile_log, which retrieves an existing log, and get_pdf, which fetches the compiled output.

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

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

The description implies the tool is used when you need to compile a project and get diagnostics, but it does not explicitly say when to prefer it over get_compile_log, get_pdf, or export_project. 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?

The description merely restates that a folder is created and reveals nothing about side effects, idempotency, error behavior, or what happens if the folder already exists. Annotations provide no extra behavioral context beyond basic flags, so the description carries the burden and does not meet 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?

The description is a single efficient sentence with no filler or redundant modifiers. It is appropriately front-loaded, though it sacrifices semantic richness for brevity.

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

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

For a simple three-parameter create operation, the description combined with the schema is minimally viable: an agent can see the required projectId and name plus optional parentPath. However, with no output schema and no parameter descriptions, the description still falls short of fully supporting correct invocation in ambiguous cases.

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

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

Schema description coverage is 0%, and the description does not explain projectId, name, or parentPath. With zero compensation for the missing schema documentation, an agent cannot infer the meaning or expected format of any parameter.

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 clear action ('Create a folder') and a resource ('inside an Overleaf project'), so its purpose is unmistakable. It distinguishes itself from the sibling tool create_project by targeting folders rather than projects, though it does not explicitly name that 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?

No guidance is given about when to use this tool versus alternatives such as write_file or upload_file. The phrase 'inside an Overleaf project' gives some context but does not state exclusions, prerequisites, or scenarios where a different tool is preferred.

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 a mutating, non-idempotent, non-destructive operation. The description adds that the project is empty and that an id is returned, which is useful, but it does not explain the effect of the template parameter, and the claim 'empty' is potentially misleading if a template populates content.

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

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

The description is a single front-loaded sentence with no filler. It communicates the core action and return value efficiently, earning 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?

With no output schema and 0% parameter coverage, the description is too thin to support correct invocation, especially for the optional template parameter. It covers only the no-template case and gives no hint about template behavior, naming constraints, or how the returned id is shaped.

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 for the bare name and template properties. It does not mention either parameter, leaving template especially ambiguous: template name, template id, or template content are all unexplained. No parameter-level meaning is added beyond what the schema already shows.

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 clear verb+resource: creating an Overleaf project and returning its id. The phrase 'new, empty' helps set expectations and distinguishes this from operations like rename, delete, or compile. However, it does not explicitly differentiate from potential import or template-based creation paths, and 'empty' may be inaccurate when the optional template parameter is used.

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

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

There is no guidance on when to use this tool versus alternatives, no mention of prerequisites, and no exclusions. An agent must infer from the name and description that this is for creating a project, but no contextual or comparative guidance is 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 declare readOnlyHint=false and destructiveHint=true, so the destructive nature is covered. The description adds 'Permanently delete' (irreversibility) and 'Requires human confirmation' (interaction requirement), which go beyond the annotations. This provides meaningful behavioral context for a high-stakes 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?

A single, front-loaded sentence with no filler. The core action and the critical confirmation requirement are both stated efficiently. The description earns its place without redundancy.

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

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

Despite the destructive nature and lack of parameter documentation, the description is very brief. It does not explain what constitutes a valid path, whether deletion is recursive for folders, what happens to child files, or what errors might occur. The confirmation requirement is mentioned, but for a tool with 0% schema coverage and no output schema, this is insufficient for an agent to call it safely and 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 0% and the description provides no explanation of 'projectId' or 'path'. While 'projectId' is self-explanatory, 'path' is ambiguous – it could be relative, absolute, file-only, or folder-only. The description gives no format or examples, leaving the agent to guess. For a destructive tool, this is a critical gap.

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

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

The description states a specific verb ('permanently delete'), the resource type ('document, file, or folder'), and the context ('from an Overleaf project'). It clearly differentiates from sibling tools like delete_project (whole project) and archive_project (non-destructive archive). The wording 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 implies usage for file/folder deletion within a project but does not explicitly mention alternatives or when not to use it. The note 'Requires human confirmation' signals a precondition but no guidance is given about when to prefer this over delete_project or archive_project. The sibling list includes delete_project, but the description does not route the agent away from it, leaving some inference required.

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 mark the operation as destructive, so the description's 'permanently delete' reinforces that signal. It adds meaningful behavioral context beyond annotations: the deletion covers the 'entire' project and requires human confirmation, which is operationally valuable.

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 deliver the core purpose and a critical constraint with no wasted words. The most important information (permanence) is front-loaded, and the human-confirmation requirement follows naturally.

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 destructive action, the description covers the key operational facts: what is deleted, that it is permanent, and that confirmation is required. It could add pointers to alternative tools or permission prerequisites, but those are not essential for correct invocation.

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

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

There is only one required parameter, projectId, and the description does not explicitly explain it. However, the parameter name is self-explanatory and the description's reference to 'an Overleaf project' makes the target clear. Minimal compensation is needed for such a simple 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?

The description uses a specific verb ('delete') and resource ('entire Overleaf project'), with 'permanently' signaling scope and irreversibility. It clearly distinguishes this tool from siblings like archive_project and delete_entity, even without naming them 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 'Requires human confirmation' gives important contextual guidance about when this tool should be invoked, but it does not explicitly state when to prefer this over archive_project or delete_entity. Usage context is implied rather than spelled out.

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 cover read-only and idempotency. The description adds meaningful behavioral context: the output is written to outputPath on the local filesystem, and the archive contains the whole project. This goes beyond annotations, though it does not mention overwrite behavior or path prerequisites, which are minor 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?

The description is a single, concise sentence with no filler. It front-loads the main action and resource, and every word contributes to understanding the tool's behavior.

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 tool with no output schema and annotations covering idempotency and read-only behavior, the description is largely complete. It covers the core action and destination. It could clarify whether outputPath should be a file path or directory and whether existing files are overwritten, 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?

The schema has zero descriptions, and the description compensates by referencing both parameters: projectId via 'whole Overleaf project' and outputPath explicitly as the write destination. It adds some meaning but does not specify expected path format, file naming, or any constraints, leaving room for ambiguity.

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 ('Download') and resource ('whole Overleaf project as a ZIP archive'), making it immediately clear what the tool does. This clearly distinguishes it from sibling tools like get_pdf, read_file, or compile_project, even without naming them 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 description implies when to use the tool (when you need the entire project as a ZIP) but gives no explicit guidance, alternatives, or exclusions. It does not mention when not to use it or point to any sibling for similar but different tasks.

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 says 'Return' which implies a read-only operation, but the annotation readOnlyHint=false contradicts this by indicating the tool may have side effects. The idempotentHint=true also suggests no side effects, but the readOnlyHint=false directly conflicts with the description's implication. The description does not disclose any behavioral traits beyond the contradiction, so it fails to provide clarity.

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 primary action is front-loaded, and the usage condition is concise. Every word serves a purpose.

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

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

For a simple tool with one parameter and no output schema, the description is almost complete but is undermined by the annotation contradiction. The user cannot trust the read-only implication, and there is no mention of what happens if the compile log is not available or whether it returns the latest log. The contradiction creates a significant gap in understanding.

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

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

Schema description coverage is 0%, and the description does not explain the meaning or format of the sole parameter projectId. It only says 'from a compile,' which hints that projectId identifies the project but does not clarify how to obtain or use it. No additional value is added 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?

The description states a specific verb ('Return') and resource ('full raw LaTeX log from a compile'), which clearly distinguishes it from siblings like get_pdf (returns PDF) and read_file (reads arbitrary files). It does not explicitly name a sibling, but the intent 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 provides a clear usage condition: 'Use when structured diagnostics are insufficient.' This implies a threshold for when this tool is appropriate and suggests an alternative (structured diagnostics), even though that alternative is not named among the siblings. It does not explicitly state when not to use it, but the condition is actionable.

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 mark this as non-read-only and idempotent. The description adds that it performs a compile and writes to disk, making the side effect concrete. It does not discuss overwrite behavior, but annotations lower the burden and there is no contradiction.

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 sentence with no filler; action and destination are stated directly in order. Every word contributes to the call semantics.

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 with two string parameters, but there is no output schema and sparse annotations. The description explains what and where, yet omits whether outputPath is a file or directory, whether existing files are overwritten, and what the call returns. Adequate for a basic call but incomplete for edge cases.

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. It does map both parameters in context: the project is compiled and the output is written to outputPath, but it does not explain expected formats, absolute paths, or extension requirements.

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

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

The description states a specific compound action: compile the project and write the PDF to outputPath. This distinguishes it from a plain compile_project or export tool, though it does not explicitly name sibling alternatives.

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

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

No guidance is given on when to use this tool versus compile_project, export_project, or write_file. With several related siblings present, an agent cannot tell whether to call this directly or compose other tools.

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 and idempotentHint, covering the safety and repeatability profile. The description adds useful context by clarifying that all document types, binaries, and folders are included, but it does not disclose potential pagination behavior or return format. With annotations present, this 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?

A single, tightly-worded sentence that front-loads the core action and scope. There is no filler or redundant 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?

For a simple read-only list tool with one required parameter and no output schema, the description is mostly complete for invocation. However, it leaves unclear whether the listing is recursive and what fields appear in the returned items, which could matter when an agent processes the result.

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 for the undocumented projectId parameter. It connects the parameter to an Overleaf project but provides no details on the ID format, how to obtain it, or what values are valid. The added value over the bare schema is minimal.

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 ('List') and names the resource ('every document, binary file, and folder in an Overleaf project'), making its function immediately clear. This distinguishes it from sibling tools like list_projects (lists projects) and read_file (reads file contents) without needing to inspect schemas.

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 the tool is for enumerating the contents of a project, but it does not explicitly state when to prefer this over alternatives or mention exclusions. There is no guidance about when to use read_file or list_projects, leaving the agent to infer usage context 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 declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the behavioral detail that archived and trashed projects are excluded by default, and implies that setting the include flags will alter that. This is useful beyond annotations, though it does not disclose pagination, sorting, or return format. Given the annotation coverage, this is a strong addition.

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, front-loaded with the primary action and followed by a concise clarification of default behavior. Every word contributes, with no redundancy or filler. This is exemplary conciseness.

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 list tool with two optional boolean parameters, the description covers the core behavior (listing projects and default exclusions). There is no output schema, so return format is not described, but it is implicit that a list of projects is returned. Pagination or field details could be added, but they are not essential for correct invocation. Given the annotations cover read-only and idempotency, the description is sufficiently complete.

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

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

Schema description coverage is 0%, so the description must compensate. It directly explains the meaning of the two boolean parameters by stating that archived and trashed are excluded by default, which implies that setting includeArchived=true or includeTrashed=true will include them. This adds meaning beyond the raw schema, which only lists types. It is clear and sufficient for an agent to understand parameter effects.

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 ('List') and resource ('projects in the account'), and explicitly notes the default exclusion of archived and trashed projects. This clearly distinguishes the tool from siblings like list_files, which lists files within a project, by scope. The purpose 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 provides a clear usage context: it lists projects and states that archived/trashed are excluded by default, implicitly guiding the agent to use the includeArchived/includeTrashed parameters when those are needed. It does not explicitly contrast with siblings (e.g., list_files), but the resource name and context make the differentiation obvious. It lacks explicit 'when-not-to-use' guidance but is otherwise helpful.

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 signal that this is mutating, non-destructive, and idempotent, so the description carries little behavioral burden. However, it adds no operational context such as whether the source path is removed, what happens if the destination already exists, or whether moving a folder moves its contents recursively.

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 clear sentence with no filler, front-loading the action and resource. Every part 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?

Given three undocumented required parameters, no output schema, and no parameter descriptions, the tool is under-specified. An agent cannot reliably determine edge-case behavior, success/failure signals, or conflict handling from this description alone.

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, but it only weakly maps to parameters: path is the item to move, destinationPath is the target folder, and projectId is the project. It does not explain path format, relative vs absolute paths, or whether the destination folder must pre-exist.

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 (Move), the resource (document, file, or folder), and the destination (different folder in the project). This clearly distinguishes it from siblings like delete_entity, write_file, upload_file, and create_folder.

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 usage context is implied but not explicit: the operation is for relocating existing entities within a project. It does not mention when not to use it or point to any alternative, such as using write_file/upload_file for creating content or delete_entity for removal.

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 mark the operation as readOnly and idempotent. The description adds meaningful behavioral context beyond these hints: it reveals that unsaved edits are included and that binary or oversized documents require outputPath. No contradiction with annotations is present.

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 purpose is front-loaded, and the important edge-case behavior about outputPath is placed right after, making it easy for an agent to parse quickly.

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, the description covers the main behavioral nuances: unsaved edits, binary files, and size caps. There is no output schema, so the description could have elaborated on return format or error conditions, but the current guidance is sufficient for an agent to invoke the tool correctly in most cases.

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

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

Schema coverage is 0%, so the description carries the burden of explaining parameters. It does explain the special role of outputPath ('Binary files and documents over the size cap require outputPath'), and projectId/path are fairly self-explanatory from their names. However, it does not fully define outputPath semantics, such as whether it is a local destination or how the path should be formatted.

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') and resource ('a text document from an Overleaf project'), which clearly distinguishes it from sibling tools like write_file, list_files, or upload_file. It also adds a specific behavioral qualifier ('including collaborators' unsaved edits') that sharpens the purpose.

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 clearly establishes when the tool is appropriate: reading text documents from a project, with the notable inclusion of unsaved edits. It does not explicitly name alternatives or conditions to avoid using it, but the context is clear enough for an agent to select it for read operations versus write or export operations.

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. The description adds no behavioral context beyond this, such as whether renaming affects URLs, references, or collaborator access, or whether it can be undone. It does not contradict annotations, but it fails to enrich them.

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

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

The description is a single, front-loaded sentence with no filler. Every word adds meaning. It is highly concise and well-structured for quick parsing.

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 tool, the description is minimally adequate but not complete. It omits parameter explanations and usage context, though the tool name and parameter names provide some inferable meaning. Given the simple scope and existing annotations, a well-rounded definition would have at least briefly clarified the parameters or stated a use case.

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

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

With 0% schema description coverage, the description must compensate for missing parameter details, but it does not. It mentions neither 'projectId' nor 'name' explicitly, leaving the agent to infer that 'name' is the new name and 'projectId' identifies the target. No formats, constraints, or examples are provided, so the semantics are entirely underspecified.

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: 'Change the name of an Overleaf project.' This clearly conveys the tool's purpose. However, it does not differentiate from sibling tools like archive_project or delete_project, which are also project-level operations, but the verb 'change the name' is unambiguous enough to avoid confusion.

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

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

No guidance is given on when to use this tool versus alternatives. There is no mention of prerequisites (e.g., project must exist, user must have permission), no exclusions, and no hint about when renaming is appropriate compared to archiving or deleting. The description only states what the tool does, not when 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=false, idempotentHint=true, and destructiveHint=false. The description adds the fact that it can overwrite files, which is a behavioral detail not covered by annotations. However, it does not disclose other potential behaviors such as file size limits, authorization requirements, or response format. Since annotations cover the basic safety profile, the added 'overwrite' context earns a middle score.

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, concise sentence that front-loads the action and resource. There is no wasted wording, and the core information is immediately accessible. It is an efficient and well-structured 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?

For a tool with three required parameters and no output schema, the description is notably sparse. It fails to explain the purpose of each parameter or any expected behavior on overwrite (e.g., atomicity, confirmation). It also does not mention prerequisites like project existence or path format. While the action is simple, the lack of parameter documentation and return information leaves the description incomplete for an agent to call it correctly without additional knowledge.

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 is expected to compensate by explaining the parameters. It does not mention projectId, path, or contentBase64 at all, nor does it clarify their meaning or format. The parameter names are self-explanatory to some extent, but without any description-level elaboration, an agent has no guidance beyond the schema names. This is a significant gap given the low 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 the verb (upload/overwrite) and the resource (binary file in an Overleaf project). It also distinguishes from write_file by specifying binary file types (image, PDF, data). This gives an agent a clear understanding of the tool's scope and differentiates it from 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?

The description does not explicitly state when to use this tool versus alternatives like write_file. It mentions 'binary file' but does not provide explicit conditions or exclusions. An agent would have to infer the intended use case from the resource type alone, which is insufficient 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?

Annotations already declare readOnlyHint=false and idempotentHint=true, and the description adds meaningful context by noting that overwriting records a new version in Overleaf history, which explains the non-destructive nature consistent with destructiveHint=false. This goes beyond the annotations and clarifies the overwrite behavior.

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

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

Two sentences, front-loaded with the core action, and every sentence adds value. No fluff or redundant 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 simple write operation with 3 parameters and no output schema, the description covers the essential behavior (create/overwrite) and the versioning side effect. It does not mention error conditions or prerequisites, but these are minor given the tool's simplicity and the sibling context.

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

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

The schema description coverage is 0%, so the description should compensate by explaining the parameters. However, it only mentions 'text document' and 'Overleaf project' without detailing path, content, or projectId semantics. The parameter names are self-explanatory but the description does not clarify expected formats or relationships (e.g., whether path includes directories).

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 clear verb ('Create or overwrite') and resource ('text document in an Overleaf project'), and distinguishes itself from siblings like read_file and upload_file by specifying text content and versioning behavior. This is a specific and unambiguous purpose.

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 for text files and mentions overwriting with version history, but it does not explicitly state when to prefer this tool over siblings such as upload_file (which likely handles binary files) or when not to use it. There is no explicit exclusion or alternative guidance.

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