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

With no annotations provided, the description must carry behavioral transparency. It does disclose that compilation is server-side and that the tool returns status plus output files, but it does not explain side effects, prerequisites, failure behavior, or timing.

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 concise sentence and packs the essential action and output summary without wasted words.

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 no annotations, no output schema, and zero parameter descriptions, this is too thin. It does not mention how projectId interacts with project selection, whether draft affects output files, or how the returned status relates to compile_log.

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 needed to compensate. It does not explain what 'draft', 'projectId', or 'stopOnFirstError' mean, their defaults, or which are relevant to the current selected project.

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 ('Run a server-side LaTeX compile') and the result ('report status plus output files'). It also distinguishes itself from siblings like overleaf_compile_log and overleaf_download_pdf.

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

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

The description gives no guidance on when to use this tool versus alternatives. It does not mention that compile_log is for logs, download_pdf is for fetching the PDF, or whether a project must be selected first.

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

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

The description discloses the core side effect (compiling the project) and the output type (parsed errors and warnings). However, with no annotations, it does not explain other behavioral considerations such as whether compilation modifies files, whether it uses the current project or requires a projectId, or how failures are surfaced.

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 action and output, making it easy 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?

The tool has one parameter, no annotations, and no output schema, so the description must do more work. It lacks parameter semantics, usage conditions, and any detail about the parsed output or error behavior, leaving the agent with an incomplete picture.

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

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

The only parameter, projectId, is not mentioned in the description, and schema description coverage is 0%. The phrase 'the project' vaguely suggests a project is involved, but the agent is given no information about how to populate projectId or whether it is optional.

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 tool compiles the project and returns parsed LaTeX errors and warnings. This distinguishes it from siblings like overleaf_compile (which presumably just compiles) and overleaf_read_file (which reads files without compiling).

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 explicit guidance is given on when to use this tool versus overleaf_compile or overleaf_read_file. The use case is only implied by the action itself, and there is no mention of prerequisites, project selection, or alternatives.

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 adds one behavioral trait ('including any missing parents'), but without annotations, it must carry the full burden of disclosure. It does not state what happens if the folder already exists, whether the operation is recursive or idempotent, or any permission requirements.

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 with no fluff, but the first part 'Create a folder' directly repeats the title. Still, the 'including any missing parents' addition earns its place, making it appropriately concise for the tool's simplicity.

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 no annotations, no output schema, and no schema descriptions, so the description is the sole documentation. It covers the core action but fails to explain parameter roles, expected return values, or error behavior, leaving the overall context incomplete.

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 and no parameter documentation in the description, the meanings of 'folderPath' and 'projectId' are left entirely to the agent's inference. The description only says 'Create a folder' and provides no mapping to the parameters.

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 'Create a folder, including any missing parents' uses a clear verb and resource, and the 'including any missing parents' detail distinguishes it from any hypothetical simple folder creation. No sibling tool is for creating folders, so 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?

No guidance is provided about when to use this tool versus alternative approaches or in which context (e.g., project selection). The only implicit usage is that it creates folders, but no exclusions or comparisons are mentioned.

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

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

With no annotations, the description carries the full burden. It states it reports the current project, making it clear this is a read-only operation, but it does not disclose what happens when no project is selected (e.g., returns null or errors), nor does it specify the return format (ID, name, etc.). This is minimal but not misleading.

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 or redundancy. Every word contributes to its purpose, making it highly concise and well-structured.

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 low complexity (zero parameters, simple getter), the description is mostly complete. It clearly states what the tool does, but since there is no output schema, it would be slightly better to specify the exact return value (e.g., project ID or name). Still, it is adequate for 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?

The tool has zero parameters, so the schema is trivially complete. The description does not need to explain parameters, and the baseline of 4 applies. No additional parameter information is required.

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

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

The description clearly states the tool's action: 'Report which Overleaf project is currently selected.' It uses a specific verb (report) and resource (current project), distinguishing it from siblings like overleaf_list_projects and overleaf_select_project.

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

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

The description implies usage (when you need to know the current selection) but gives no explicit guidance on when to prefer this over alternatives like list_projects or select_project. It does not mention any exclusions or prerequisites, so it relies on implied context.

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?

Since no annotations are provided, the description carries full burden. It discloses a key requirement (confirm must be true) and the destructive nature of the operation, but lacks details on permanence, permissions, or side effects.

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 with no filler. The most critical behavioral note (requires confirm) is front-loaded and the description is easy to scan.

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 delete operation, the description covers the essence, but the lack of parameter documentation and usage context is a gap. Given the low complexity and absence of an output schema, this is adequate but not 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?

With 0% schema description coverage, the description must compensate for parameter meanings. While 'file or folder' hints at filePath and 'confirm' is mentioned, projectId is entirely unaddressed and no value formats or constraints are given.

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 tool deletes a file or folder from the project, using a specific verb and resource. It distinguishes itself from sibling tools like rename, move, or read, making the purpose 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?

No guidance is given on when to use this tool versus alternatives (e.g., rename or move). No exclusions or prerequisites beyond the confirm requirement, leaving the agent to infer when deletion is appropriate.

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 states the basic save-to-local-path action but does not mention whether existing local files are overwritten, whether directories are created, what happens if the source file is missing, or any permission requirements. This is similar to the update_drive example where mutation details were omitted.

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 core action and resource. It is appropriately brief, though it omits useful details that could be added without much verbosity.

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 parameters, no annotations, no output schema, and many sibling tools, the description is too thin. It fails to explain projectId, distinguish from download_pdf, or clarify return/error behavior, leaving the agent with insufficient context for reliable 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 coverage is 0% and no parameter descriptions are present. The description partially compensates by mapping 'project file' to filePath and 'local path' to destPath, but it does not clarify the optional projectId parameter or its role in selecting the project. Two of three parameters are only implicitly described.

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?

Description clearly identifies the action ('Save... to a local path') and the resource ('any project file'), with explicit examples (PDFs, images) that distinguish it from the sibling tool overleaf_download_pdf. The verb 'save' effectively conveys 'download' without ambiguity.

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 provided about when to use this tool versus alternatives like read_file, read_image, or download_pdf. The phrase 'any project file' implies broad applicability but does not state exclusions or recommend when a different sibling would be more appropriate.

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

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

No annotations are provided, so the description carries full burden. It discloses the main side effects (compilation and local file save) but omits details such as overwrite behavior, failure handling, or whether the current project is used when projectId is omitted. This is moderate transparency but leaves important behavioral questions unanswered.

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 extremely concise at two short sentences with no filler. It front-loads the core action and is easy to parse, even if it is terse.

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

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

There is no output schema or annotations, so the description must cover return behavior and edge cases. It does not mention compile failures, whether the PDF is written to destPath, or how project selection works, making it incomplete for a side-effectful operation.

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 0% description coverage for parameters, and the description does not explain destPath or projectId beyond the generic phrase 'save the resulting PDF locally.' While destPath is inferable from 'save locally,' projectId is entirely unaddressed, leaving the agent without guidance on which project to compile.

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?

Description uses a specific verb phrase 'Compile the project and save the resulting PDF locally,' clearly stating both actions and the resource. This distinguishes it from sibling tools like overleaf_compile (which only compiles) and overleaf_download_file (which downloads arbitrary files without compiling).

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 explicit when-to-use or alternative comparisons are provided. The description implies a combined compile-and-download workflow, but does not mention when to prefer this over calling overleaf_compile followed by overleaf_download_file, nor any prerequisites or exclusions.

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

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

With no annotations, the description must fully disclose behavior. It only states 'replace an exact string' and omits details about replaceAll behavior, error handling when oldString is not found, project selection requirements, or file existence assumptions. This leaves significant ambiguity.

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 redundancy. It is front-loaded and every word contributes to the core 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 5-parameter mutation tool with no annotations and no output schema, this description is severely incomplete. It fails to explain crucial behaviors like replacement scope, project context, and failure modes, making it inadequate for correct agent usage.

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 description adds no meaning to the parameters. With 0% schema description coverage, it should at least explain the roles of oldString, newString, filePath, projectId, and replaceAll, but it does not mention any of them.

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 tool replaces an exact string in a project file, using a specific verb and resource. It distinguishes from sibling tools like overleaf_write_file by emphasizing 'exact string', though it does not explicitly name 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 provided on when to use this tool versus alternatives such as overleaf_write_file or overleaf_grep. There is no mention of appropriate scenarios, prerequisites, or exclusions, leaving the agent without decision support.

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 burden of behavioral disclosure. It states the action (regex search on text files) but does not mention read-only nature, case sensitivity, match limits, or performance implications. It adds basic context but lacks depth for a tool with 4 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 a single, focused sentence with no redundant words. It front-loads the core purpose and earns its place efficiently, achieving maximum 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?

The tool has 4 parameters and no output schema, yet the description does not disclose return format, valid flag values, or the role of projectId relative to the selected project. This is insufficient for an agent to invoke the tool correctly without additional assumptions, especially given the lack of annotations.

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

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

Schema description coverage is 0%, so the description must compensate. It explains none of the parameters—pattern, flags, projectId, maxMatches—beyond the implicit 'regex' in the verb. While parameter names are somewhat self-explanatory, the description does not clarify flag syntax, project scope, or match limiting behavior, leaving the agent to guess.

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 tool performs regex search across every text file in the project, with a specific verb and resource. It distinguishes from sibling tools like overleaf_read_file (single file access) and overleaf_word_count (counting), making the purpose 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 phrase 'across every text file in the project' provides context that this is a project-wide search tool, implying use when scanning multiple files. However, it does not explicitly mention alternatives or when not to use it, but the scope is clear enough to differentiate from file-specific 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?

No annotations are provided, so the description carries the full burden. It only states the action without disclosing behavior like whether it requires an active project, what happens if projectId is omitted, or if it returns a flat list or tree structure. The refresh parameter's effect is unexplained.

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 is front-loaded and free of fluff. It earns its place, though it could be slightly more informative without becoming verbose.

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 has 2 parameters, no annotations, and no output schema, the description is too thin. It doesn't explain the refresh parameter, the need for projectId, or the return format. For a listing tool, more context about scope and behavior is needed.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'every file and folder' but doesn't explain the two parameters (refresh, projectId) or their semantics. The description adds minimal value beyond the schema's bare property names.

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 tool lists every file and folder in a project, which is a specific verb+resource. It distinguishes from siblings like overleaf_read_file or overleaf_list_projects, though it doesn't explicitly differentiate from a potential 'list files' 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?

No guidance on when to use this tool versus alternatives. It doesn't mention that projectId is needed or how it relates to the current project selection, nor does it explain the refresh parameter's purpose. Sibling tools like overleaf_current_project or overleaf_select_project are not referenced.

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

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

No annotations are provided, so the description carries the full transparency burden. It identifies the operation as listing projects but does not disclose behavior such as whether archived projects are excluded by default, pagination, sorting, or what fields are returned.

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

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

The description is a single sentence that is direct and front-loaded. Every word contributes to the core purpose 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?

Given the lack of an output schema and annotations, the description is too sparse. It does not clarify the includeArchived parameter behavior or what the returned project list will contain, making it incomplete for confident 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 0% for the single parameter includeArchived. The tool description does not mention this parameter or explain its effect, leaving the agent to infer from the parameter name alone.

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 ('List') and the resource ('projects on the signed-in Overleaf account'). This distinguishes it from sibling tools like overleaf_list_files and overleaf_select_project.

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

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

No guidance is provided about when to use this tool versus alternatives such as overleaf_select_project or overleaf_current_project. There are no exclusions, prerequisites, or hints about typical invocation order.

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 disclosing behavioral traits, but it does not mention side effects (e.g., overwriting), whether moves are recursive, path interpretation, or authentication requirements. It merely states the operation without safety or behavioral details.

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 that is front-loaded and free of verbose language. It conveys the core operation without unnecessary padding.

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

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

Given the lack of annotations, no output schema, and three under-documented parameters, the description is too minimal. It omits critical context such as required projectId semantics, expected return behavior, and how folders are handled, making it incomplete for reliable 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 0%, so the description must compensate. It does not explain the role of projectId, path formats, or the relationship between filePath and destFolder beyond what their names imply. The description adds no detail for the three parameters.

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 ('Move') and a clear resource ('a file or folder') with a target ('into another folder'). It distinctly conveys the operation, distinguishing it from siblings like rename or delete.

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 rename, upload, or create_folder. The description only states the action, leaving usage context implicit at best.

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 disclosing side effects. The term 'Read' inherently implies a non-destructive operation, and the description does not suggest any modification. It could be more explicit about being read-only, but the intent is clear.

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 concise, consisting of two sentences with no redundant information. It efficiently conveys the core functionality and a key usage hint.

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?

Covers the essential purpose and the truncation behavior, which is sufficient for a simple read operation. It does not specify the return format, but since no output schema is provided, the absence is not critical; the description meets the needs for a basic tool.

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 description adds meaning for startLine and endLine by explaining they serve for paging through truncated files. However, it does not elaborate on filePath or projectId, which are presumably self-explanatory in the Overleaf context, but the schema itself provides no descriptions. Partial 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 tool reads a LaTeX or other text file, which is specific and unambiguous. It naturally distinguishes from sibling tools like write_file, edit_file, and grep, as reading is a distinct operation.

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

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

Provides actionable guidance by noting that long files are truncated and advising to use startLine and endLine for paging. This directly helps the user handle large files, though it does not explicitly mention when to prefer this over alternatives, which is not critical for a read operation.

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

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

No annotations are provided, so the description carries the full transparency burden. 'Fetch' and 'viewed directly' correctly signal a non-mutating, display-oriented operation, but the description does not disclose how the image is returned (binary, base64, URL), what formats are supported, or what errors/limitations apply.

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 states the action, the resource, and the purpose 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 2-parameter read tool, the description is close to adequate, but the lack of annotations, output schema, and parameter semantics leaves the agent uncertain about the response format and exact arguments. It supports tool selection but not fully confident 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 0%, so the description itself must explain the meaning and usage of filePath and projectId. It only hints that filePath refers to an image and that the image comes from a project; it never names the parameters, mentions whether projectId is optional/relative to the current project, or specifies path rules or supported image types.

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 action ('Fetch') and a clearly scoped resource ('an image from the project'), with the intended outcome 'so it can be viewed directly'. This makes the tool's purpose easy to distinguish from siblings like overleaf_read_file or overleaf_download_file.

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 intended use case is implied: use this when you need to view an image from the project. However, it does not explicitly say when not to use it or compare this with alternatives such as overleaf_read_file for text or overleaf_download_file for raw downloads.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the action is an in-place rename, but omits side effects, overwrite behavior, permissions, and whether renaming a folder affects its contents.

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 or repetition. Every word contributes to the core meaning.

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

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

For a 3-parameter mutation tool with no output schema and no annotations, this description is too minimal. It lacks prerequisites, behavior details, return/error information, and context about how projectId or file paths are resolved.

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 filePath, newName, or projectId. While the parameter names are somewhat self-explanatory, the description adds no explicit semantics, constraints, or relationship between the parameters.

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 ('Rename') and identifies the resource ('a file or folder') with the scope 'in place', which clearly distinguishes this from sibling tools like overleaf_move. The title is also clarified by the description.

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

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

There is no explicit when-to-use or when-not-to-use guidance, and no alternative tools are mentioned. The only usage signal is the verb 'rename', which is largely implied by the tool name.

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

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

No annotations are provided, so the description must disclose behavioral details. It does reveal that the tool changes the active project and accepts partial names, but it does not explain behavior on ambiguous matches, no matches, persistence across calls, or the return value. This is a meaningful gap for a state-changing tool.

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. It front-loads the core purpose and immediately defines the parameter semantics, making it easy to scan.

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

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

For a simple one-parameter selection tool, the description covers the essential purpose and input meaning. However, with no annotations and no output schema, it omits edge-case behavior and expected results, so it is only minimally 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?

The schema only states that 'query' is a required string, so the description adds useful meaning by clarifying it can be a project id or part of a project name. However, it lacks specifics such as id format, case sensitivity, or how to disambiguate multiple partial-name matches, leaving some 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 uses a specific verb ('Choose') and identifies the resource ('the project every other tool works on'), which clearly distinguishes it from sibling tools like overleaf_list_projects and overleaf_current_project. It also states the accepted input forms (id or part of a name).

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 'every other tool works on' implies this should be called before using other Overleaf tools, but the description does not explicitly say when not to use it or mention alternatives like listing projects first to find a valid id/name. Usage context is implied rather than stated.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states only that a file is uploaded, but does not mention overwrite behavior, file size limits, authentication requirements, or whether an existing target file is replaced. This is a significant gap for a mutation tool.

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

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

The description is a single sentence that is direct and front-loaded with the action. It wastes no words and is appropriately sized for the tool's simplicity.

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 annotations, no output schema, and zero parameter descriptions, the description is too sparse to provide complete context. It does not explain return values, required project state, or how parameters interrelate, leaving important operational details undocumented.

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 any of the three parameters (localPath, filePath, projectId). Although the parameter names are somewhat self-explanatory, the description adds no value beyond the minimal schema, leaving the agent without guidance on how to populate these fields.

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 tool's action: 'Upload a local file, such as a figure, into the project.' It uses a specific verb ('upload') and identifies the resource being acted on (local file) and the destination (project). This distinguishes it from sibling tools like write_file or download_file.

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 'such as a figure' implies a use case (binary or local content), but the description provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions or prerequisites. The usage context is only weakly 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 provided, the description carries the full burden of behavioral disclosure. It only states the basic action ('Return the compiled word count') without elaborating on side effects, dependencies (like prior compilation), or any limitations, offering minimal insight beyond the obvious.

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 wasted words. It efficiently conveys the core purpose, though the brevity results in missing details, which is acceptable for conciseness but penalized elsewhere.

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?

This simple tool lacks an output schema and has only one undocumented parameter. The description fails to explain what 'compiled word count' means (e.g., does it require compilation? what files are included?), and it does not describe the output format. Given the minimal schema and absence of annotations, the description is insufficient for full contextual 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?

The input schema has zero description coverage for the projectId parameter, and the tool description does not explain it either. The phrase 'for the project' vaguely alludes to it, but no meaning or usage context is added for the parameter, leaving the agent to guess its format or optionality.

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 tool returns the compiled word count for the project. It uses a specific action ('Return') and a specific resource ('compiled word count'), which distinguishes it from siblings like overleaf_list_projects or overleaf_read_file.

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 no explicit guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., whether compilation is required) or any exclusion conditions, leaving usage entirely 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 provided, the description carries the burden of behavioral disclosure. It explicitly mentions 'overwrite' and that missing parent folders are created, which are the key behavioral facets. It doesn't discuss permissions, return values, or content restrictions, but the most critical behaviors are 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?

The description is two sentences with no wasted words: it states the core purpose and a key additional detail. The information is front-loaded and easy 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 simple write tool, the description covers the primary operations adequately. However, it does not explicitly distinguish itself from sibling tools, does not mention project context/current project selection, and relies on the agent to infer content semantics and behavior with insufficient detail. These gaps reduce completeness.

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 zero description coverage. The description adds a small amount of semantic for filePath by noting that missing parent folders are created, but it does not clarify content (beyond being a text string) or the role of projectId. Complete coverage for parameters is required because the description is the only source, and it is insufficient.

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

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

The description clearly states the action: 'Create or overwrite a text file in the project.' This is a specific verb-plus-resource with scope, and it distinguishes itself from siblings like overleaf_edit_file (targeted edits) and overleaf_upload_file (file uploads) by focusing on full-file text writes.

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 its usage by describing create/overwrite semantics and automatic creation of parent folders, but it does not explicitly say when to use this tool instead of alternatives such as edit_file or upload_file. Usage context is present but not overt.

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