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

With no annotations provided, the description carries full responsibility for behavioral disclosure, and it delivers thoroughly. It explains the inspection of output.log, the rationale (PDF can render despite LaTeX errors), the retry and cache-clearing behavior, and the diagnostic return on persistent errors. It also notes that successful results can include warnings, which prevents overinterpreting success.

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 front-loaded with the core purpose and then adds behavioral details in a logical sequence. Each sentence contributes value, though a few clauses could be tightened. Overall it is efficient and well-structured for the amount of behavioral information conveyed.

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

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

The tool has a single parameter fully documented in the schema, and no output schema exists. The description compensates by explaining what is returned on persistent errors (parsed diagnostics and output.log) and warning that successful results can include warnings. For a simple compile tool, this is complete enough for an agent to invoke it correctly and interpret results.

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 the input schema already fully documents project_id as a 24-character hexadecimal Overleaf project ID from the project URL. The description does not add parameter-specific details, but this is acceptable when the schema is self-sufficient. The 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 states a specific verb ('Compile') and resource ('an Overleaf project'), and further clarifies the trigger context ('after uploading source or resource changes'). It also explicitly distinguishes the tool as 'the only compilation-diagnostics tool' among siblings, leaving no ambiguity about its role.

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 indicates when to use the tool: after uploading source or resource changes. It also identifies the tool as the sole compilation-diagnostics option, which implicitly rules out alternatives. It does not explicitly list exclusions, but the sibling set contains no competing compile tool, so the guidance is sufficient.

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

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

With no annotations, the description must carry the behavioral burden. It discloses that the file is empty and root-level, and clarifies the redundancy with upload_file. However, it does not state what happens if a file with the same name already exists, what error conditions may occur, or any permission side effects—leaving moderate gaps for a 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?

Two sentences with no filler: the first states the core behavior, and the second provides the crucial usage caveat. Every clause earns its place and important 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 simple two-parameter tool with a fully documented schema, the description covers tool selection and invocation adequately. It could mention duplicate-file behavior or the response format, but the 'empty file only' guidance and root-level scope make it sufficiently complete 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?

Schema description coverage is 100%, with both file_name and project_id documented in the input schema. The description adds no parameter-level detail beyond what the schema already provides, 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 opens with a specific verb and precise object: 'Create one empty root-level file.' It also distinguishes itself from the sibling tool overleaf_upload_file by explaining the exact difference, so an agent can immediately 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 explicit when-to-use guidance: 'use only when an empty file is specifically needed.' It also explains why it is usually unnecessary by pointing to overleaf_upload_file's behavior when no same-named file exists, making the decision criterion fully explicit.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses key limitations: single folder only, project-root scope, empty folder requirement, no nested path support, and current upload behavior. It does not cover duplicate-name handling or authentication, but the main operational constraints are explicit.

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 short sentences with no filler. The operation is front-loaded, and the second sentence compactly conveys the important limitations without restating schema fields.

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 create operation with fully described parameters and no output schema, the description provides enough operational context. Minor gaps such as duplicate-folder behavior and login requirements are present, but the root and empty-folder constraints already prevent common mistakes.

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?

Both parameters are already well described in the input schema, including the folder_name example. The description adds little parameter-specific detail beyond confirming the root-level scope, so the high schema-coverage 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 states the exact operation and resource: create one folder in the project root. The constraints 'empty folder' and 'no nested paths' make its intended scope unambiguous and distinguish it from sibling file/project creation tools.

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

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

It gives clear usage guidance: use only for an empty folder at the project root, and nested paths are not supported yet. It does not name explicit alternatives, but the scope constraints are sufficient to prevent most misuses.

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?

There are no annotations, so the description must carry the behavioral burden. It discloses the operation, the 'empty' initial state, and the intended follow-up upload, but it does not mention authentication requirements, potential failure modes, or what the call returns. This is adequate for a simple create action 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?

Two sentences with no wasted words. The core action is front-loaded, and the usage guidance and next-step reference earn their 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 one-parameter create tool with no output schema, the description covers what the tool does, when to use it, and the natural next step. The only notable gaps are authentication prerequisites and return value, which are minor given the low complexity.

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 the schema already documents project_name as 'Name for the new project.' The description adds workflow context but no additional formatting, constraints, or semantic detail for the parameter, so the 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 a new empty Overleaf project.' The verb is specific, the resource is clear, and the word 'empty' distinguishes this tool from the sibling overleaf_create_project_from_zip.

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 says to use the tool 'when starting a paper from scratch' and explicitly names overleaf_upload_file as the next step. It does not explicitly mention when not to use it or contrast with overleaf_create_project_from_zip, but the 'empty' qualifier provides enough contextual direction.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It does disclose an important safety behavior: it never overwrites an existing project. However, it omits other relevant behaviors such as authentication requirements, handling of invalid ZIP files, or whether duplicate projects may be created.

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 is front-loaded, and the important non-overwrite guarantee is included without unnecessary detail.

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

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

For a relatively simple creation tool with fully documented parameters, the description provides the key usage cue and a critical safety guarantee. It is slightly light on expected outcomes or failure modes, but nothing essential for invoking the tool correctly appears to be 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?

The input schema has 100% description coverage for both zip_path and project_name, so the structured schema already documents the parameters well. The description adds little beyond the schema, but the baseline of 3 applies because no additional parameter semantics are needed.

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

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

The description states a specific action and resource: creating a new Overleaf project from a local ZIP archive. It also differentiates itself from sibling tools like overleaf_create_project by emphasizing the ZIP source and the non-overwrite behavior.

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 says to use this tool for importing a complete existing paper and clarifies that it creates a separate project, which gives clear context for when it is appropriate. It does not explicitly name alternatives or exclusions, but the use case is clear enough for an agent to route correctly.

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

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

With no annotations provided, the description carries the full burden of exposing destructive behavior. It clearly warns that deletion is gated by confirm:true and explains the inspect-then-confirm flow. It could add irreversibility or return-format details, but the core behavioral risk is well disclosed.

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 with no filler. The main purpose is front-loaded, followed by the essential confirmation workflow, and 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 destructive single-file deletion operation, the description covers the critical invocation pattern and safety condition. It lacks an explicit note about the return value or irreversibility, but the schema plus confirmation guidance is sufficient 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?

Schema description coverage is 100%, with each parameter already explained including an example and a regex pattern for project_id. The description reinforces the confirm workflow but does not add significant new parameter-level meaning 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 action ('Delete exactly one project file') with a clear resource and scope ('exactly one'), making its purpose unmistakable. This clearly differentiates it from sibling file operations like create, rename, and upload.

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?

Provides an explicit two-step safety workflow: call with confirm omitted/false to inspect, then call with confirm:true only after user approval. It does not explicitly name alternatives or exclusion criteria, but the destructive nature makes the confirmation protocol the most relevant guidance.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It states the tool downloads exactly one file and returns its local path, which covers the key outcome and side effect. It does not mention prerequisites like authentication or whether it overwrites existing local files, but for a read-like file download this is reasonably 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 with no filler. The primary purpose is front-loaded, and the second sentence provides a concise workflow. 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 two-parameter tool with no output schema, the description is complete: it states what the tool does, where the file goes, what it returns (the path), and how to integrate it with upload for modifications. Nothing essential for a basic call 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 description coverage is 100%, so the baseline is 3. The description adds minor context by tying project_id to the target directory and emphasizing that exactly one file is downloaded, but does not substantially enhance the parameter semantics beyond the schema's own descriptions.

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 opens with a specific verb and resource: 'download exactly one Overleaf file' and clarifies its file-reading role, distinguishing it from siblings like overleaf_download_pdf and overleaf_upload_file. The scope is precise, including the underlying directory structure under OVERLEAF_DATA_DIR.

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 provides a workflow for modification: download, edit, then call overleaf_upload_file with overwrite: true. This clearly tells agents when and how to use the tool in a common scenario. It does not mention exclusions versus sibling tools such as overleaf_download_pdf, but the file-reading vs PDF distinction is strongly implied.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds an important ordering dependency (compile must succeed first) and reveals where the file is saved: OVERLEAF_DATA_DIR/workspace/pdfs/<project_id>/. It does not cover overwrite behavior or error cases, but the essential behavioral traits are 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?

The description is one dense, well-structured sentence. It front-loads the core action, then supplies the prerequisite and save location without any filler or repetition.

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 download tool with no annotations and no output schema, the description is mostly complete: it states the action, prerequisite, and destination. It could mention what happens on failure or what the tool returns, but those are minor gaps given the tool's simplicity.

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 baseline is 3. The description adds a little context about the save destination and the human-readable filename aspect, but it does not substantially enrich the parameter meanings beyond what the schema already provides.

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 ('Download the latest compiled PDF') and resource, distinguishing it from the generic sibling overleaf_download_file. The phrase 'latest compiled PDF' precisely identifies what this tool produces.

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 instructs to call overleaf_compile first and to download only after a successful compilation, which is strong when-to-use guidance. However, it does not explicitly mention when not to use it or name alternatives like overleaf_download_file for downloading individual project files.

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

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

With no annotations provided, the description carries the full behavioral disclosure burden. It discloses the underlying mechanism ('by downloading and inspecting the project ZIP') and the performance cost ('slower than single-file download'), giving the agent useful expectations about side effects and overhead beyond the 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. The core purpose is front-loaded, and the performance caveat is provided as a useful secondary note. 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?

The tool is simple: one required parameter, clear list semantics, and no output schema. The description covers the scope, contents of the result (nested files and sizes), and the performance tradeoff. It doesn't detail the exact return structure, but for a list operation this is a minor gap given the otherwise clear behavior.

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 project_id parameter already has a clear description and pattern. The tool description does not add additional meaning to the parameter, so the 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 opens with a specific verb and resource: 'List every project file, including nested files and sizes.' It clearly distinguishes this tool from siblings like overleaf_download_file by emphasizing the complete, nested inventory aspect.

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 states when to use the tool: 'Use when a complete, path-accurate inventory is needed.' It also provides a tradeoff against the obvious alternative, noting it is 'slower than single-file download,' which effectively tells the agent when not to choose 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?

With no annotations provided, the description carries the full burden. It discloses that this is a read/list operation (non-destructive, no authentication requirement stated), but doesn't mention potential pagination, rate limits, or what happens when no projects exist. The description is simple and safe but lacks depth; a 3 is appropriate given the minimal risk and zero parameters.

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 short sentences with no wasted words. It front-loads the core purpose and then adds a usage hint. Every word 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 the tool's simplicity (0 parameters, no output schema, read-only purpose), the description covers the essential context: what it lists, for whom, and when to use it. It could mention that the output is a list of project names+IDs, but that's already implied by the first sentence. It's complete enough for an agent to invoke 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 tool has zero parameters, so there is no schema semantic burden. The description appropriately focuses on the output (projects and IDs) rather than parameters. This is a valid baseline for a parameterless tool.

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

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

The description explicitly states the tool lists the logged-in user's Overleaf projects and their IDs, with a clear verb ('List') and resource ('Overleaf projects'). It distinguishes itself from siblings that operate on files or create projects, though it doesn't explicitly name a sibling alternative.

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 provides clear usage guidance by stating 'Use this first when the project ID is unknown,' which is a practical trigger for an agent. It doesn't explicitly mention when not to use it or name alternatives, but the context of sibling tools (e.g., overleaf_list_files, overleaf_open_project) makes the usage situation reasonably clear.

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

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

With no annotations, the description carries the burden of behavioral disclosure. It explains the tool opens Overleaf, establishes a session, and uses runtime environment variables, which goes well beyond the name. It does not mention failure modes or session expiry, but for a login tool the core behavior is disclosed.

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 action and mechanism, followed by explicit usage guidance. 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 no-parameter, no-output login tool, the description is complete: it states what the tool does, how authentication works, and when it should be invoked relative to the other Overleaf tools. Nothing essential 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?

The tool has zero parameters, and the description adds value by stating that authentication is sourced from runtime environment variables rather than input parameters. This prevents an agent from inventing arguments and matches the empty 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 ('establish') and resource ('reusable authenticated browser session'), and explains the mechanism ('runtime environment variables'). It clearly distinguishes this login/session tool from the sibling tools that perform Overleaf actions.

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 call this before other Overleaf actions if no session exists, giving a clear precondition and timing. It does not explicitly name alternative tools or state when not to call it, but the conditional covers the main exclusion.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly communicates the side effect of closing the session and releasing resources, and adds timing context. It could additionally state the consequence for later calls, but the core behavior is transparent enough.

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 action is front-loaded and the usage constraint is placed directly after, making the guidance easy for an agent to parse without extra cognitive effort.

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, no-output-schema tool, the description is complete. It explains what the tool does, what resources it affects, and precisely when it should and should not be invoked. No critical invocation context 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?

The tool has zero parameters, so there is nothing for the description to explain about parameters. The baseline of 4 for zero-parameter tools applies, and the description reasonably omits parameter details.

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: it closes the reusable Overleaf browser session and releases browser resources. This clearly distinguishes logout from sibling tools like login, ping, or project/file operations.

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 when to call it: once at the end of a bounded Overleaf task, and only when no further Overleaf work is needed. It also explicitly says when not to call it: not between ordinary tool calls. This provides strong decision guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It notes that file tools open projects automatically and that this operation affects the visible Overleaf UI, but it does not mention authentication requirements, side effects on the browser session, or whether any state changes occur.

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

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

The description is two concise sentences with no filler. The core purpose is front-loaded, and the second sentence adds practical usage guidance 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?

For a simple single-parameter tool with no output schema, the description covers the purpose, invocation method, and the primary use case. It omits authentication expectations and exact browser behavior, but the tool's low complexity means the provided context is largely sufficient.

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 fully documents project_id with format, source, and required status at 100% coverage. The description merely references opening by project ID and adds no additional semantic detail, so the baseline score 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 states a specific action ('Open a project in the browser by its project ID') and clearly identifies the resource. It also distinguishes the tool from file tools, which open projects automatically, helping an agent tell this apart from sibling file operations.

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 explicit guidance: file tools open projects automatically, so this tool is mainly for inspecting or recovering the visible Overleaf UI. It provides clear context and an implicit exclusion, though it does not name a specific alternative tool or list exhaustive when-not-to-use 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?

With no annotations, the description carries the disclosure burden. It adds a useful behavioral constraint (folder stays unchanged) and implies a mutation, but it does not disclose permissions, reversibility, or effects on references after a rename.

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 tightly scoped sentences start with the action and immediately state the key limitation. No 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 small 3-parameter rename operation this is mostly complete: it names the prerequisite and the non-supported move scenario. It does not describe the return value or error behavior, but there is no output schema and the operation is simple.

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?

All three parameters are already documented in the schema (100% coverage), so the baseline is 3. The description adds slight value by emphasizing that old_path must be the exact path obtained from listing files.

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 precise operation ('Rename an existing project file') with an explicit scope qualifier ('without changing folders'). This clearly distinguishes it from create/delete/upload siblings and tells the agent exactly what resource it acts on.

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 preparatory step: 'List files first to obtain the exact old_path,' and states the tool's limit: 'this cannot move a file between folders.' It lacks a named sibling alternative for moving files, but no move tool exists among the siblings.

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

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

With no annotations, the description carries the behavioral disclosure burden. It clearly states the key side effect: a same-named file is preserved unless overwrite: true is intentionally supplied. It also labels the tool as 'Primary file-writing tool,' signaling mutation. It does not mention return values or error conditions, but it covers the most important destructive-behavior guard.

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 three sentences with no filler: it front-loads the core action, then gives use cases, then addresses overwrite safety and the main alternative. Each sentence earns its place and the structure is easy for an agent to parse.

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 file-upload mutation tool with no output schema, the description covers purpose, typical usage, overwrite safety, and the key ZIP alternative. It lacks details about success/failure responses or authentication prerequisites, but those are not essential for correct invocation given the schema and 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?

Schema description coverage is 100%, so the schema already documents project_id, local_path, and overwrite. The description reinforces the overwrite semantics and gives concrete file-type use cases, but it does not add substantial new parameter meaning beyond what is in the schema. This meets the baseline for high 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?

The description opens with a specific verb and resource: 'upload one local file to the project root.' It also clarifies common use cases (after editing a downloaded file, or adding images/.bib/.cls/.tex files) and distinguishes itself from ZIP import. However, it does not explicitly differentiate from overleaf_create_file, and 'project root' is slightly ambiguous given local_path can include relative subpaths like figures/overview.png.

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 explicit when-to-use guidance: after editing a file from overleaf_download_file, or when adding images, .bib, .cls, and .tex files. It also states when not to use it ('ZIP import uses overleaf_create_project_from_zip instead') and explains the overwrite opt-in behavior, so an agent can select it correctly.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It implies a read-only liveness check, but it does not explicitly state that there are no side effects, whether authentication is required, or what a successful or failed response looks like. For a trivial no-argument health check, this is minimally sufficient.

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 short, clear sentence with no filler or repetition. It earns its place by stating the purpose 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 zero-parameter tool with no output schema and no comparable sibling, the description gives enough context for an agent to select and invoke it correctly. It could mention return values more explicitly, but the tool is simple enough that this is a minor gap.

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

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

The tool has zero parameters and the schema documents this completely, so there is nothing for the description to add about parameter semantics. The baseline of 4 for no-parameter tools is appropriate here.

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 ('Check') and a clear resource ('the MCP server'), stating exactly what the tool verifies: liveness and reachability. This clearly distinguishes it from the sibling tools, which all operate on Overleaf projects, files, or auth.

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 signals that this is the tool to use when you need to confirm the server is alive and reachable before making other calls. It does not explicitly discuss when not to use it, but no sibling tool serves a similar health-check purpose, so the guidance is adequate.

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