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

Annotations only declare readOnlyHint=false, destructiveHint=false and openWorldHint=true; the description adds meaningful behavior beyond that: compilation happens remotely on Overleaf's servers, diagnostics come back with file:line, and there is an optional local PDF side effect. It does not mention cost, latency, or whether an existing output.pdf gets overwritten, which keeps it below a 5.

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

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

One compact sentence that front-loads the action and its result, then appends the optional side effect. No filler or restatement of the tool name.

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

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

With no output schema present, the description carries the return-value burden and does so adequately: it promises errors and warnings tagged with file:line. It omits the shape of a successful result (e.g. confirmation or artifact path), but nothing needed to invoke the tool correctly is missing.

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

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

Schema description coverage is 83%, so the schema already explains draft mode, project resolution, rootFile, savePdfTo and maxWarnings. The description only alludes to savePdfTo ('optionally saves the PDF locally') and adds no format or default detail, so it sits at the baseline for a well-documented 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 precise verb (compiles) and resource (the project, on Overleaf's servers) plus the value it returns (LaTeX errors and warnings with file:line). It also names a sibling, edit_file, so an agent can place it in a workflow rather than guessing.

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 'so they can be fixed with edit_file' establishes the compile-check-fix cycle and implicitly tells the agent when to call it. It stops short of explicit when-not-to-use guidance or naming alternatives for viewing output (e.g. download_file), so it is clear context without full routing rules.

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

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

Annotations supply idempotentHint=true and openWorldHint=true, so the bar is lower. The description adds useful behavior beyond them: it creates any missing parent folders. However, it does not disclose authorization needs, error behavior, or what happens when the folder already exists beyond the idempotency annotation.

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 main action and the recursive-parent behavior. It is appropriately concise, though not richly structured or expansive.

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 create operation with no output schema, the description covers the basic action and project context. Annotations cover idempotency and open-world behavior. However, the required 'path' parameter remains undocumented, and authentication/permission expectations are absent, leaving notable gaps.

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

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

Schema description coverage is 50%: the optional 'project' parameter has a schema description, but the required 'path' parameter has none. The description does not compensate by explaining the format or meaning of 'path' (e.g., relative path, nesting rules), so an agent still lacks key parameter semantics.

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

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

The description states a specific verb and resource: 'Creates a folder ... in a project.' It also clarifies that missing parent folders are created recursively. It does not explicitly differentiate itself from sibling tools like create_project, which is the only gap keeping it from a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives such as create_project, upload_file, or move_file. Usage is only implied by the verb 'Creates', with no exclusions or prerequisites 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?

Annotations only declare openWorldHint=true, so safety/behavior is largely on the description. It usefully discloses what content the new project starts with (empty main.tex or example template), but says nothing about auth requirements, whether the new project becomes active/selected, or side effects on existing state.

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

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

A single front-loaded sentence with no filler. The core action leads and the two modes follow 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?

With no output schema, the description should ideally indicate what comes back (project id/URL) so an agent can chain into write_file or compile. It also omits auth prerequisites, leaving meaningful gaps for a creation 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?

Schema coverage is 50%: 'template' is documented (though tersely as 'Default blank') while 'name' is undocumented beyond min/max length. The description clarifies the meaning of the two template values, partially compensating, but leaves name constraints (uniqueness, 150-char limit) unexplained.

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

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

States a specific verb (Creates) and resource (Overleaf project), and distinguishes the two creation modes (blank with empty main.tex vs. example template). This separates it cleanly from siblings like list_projects or upload_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 explains the two output variants but gives no when-to-use guidance, no prerequisites (e.g., must be signed in), and no routing to alternatives. An agent gets no help deciding when create_project is the right call.

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

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

Annotations already declare destructiveHint=true and openWorldHint=true, so the bar is lower. The description still adds real value: deletion is recursive for folders ('with its contents') and Overleaf retains the item in project history, which tells the agent the action is recoverable. It omits permission requirements and behavior when the path does not exist.

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

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

Two short sentences, zero filler, with the destructive scope (contents included) front-loaded and the recoverability caveat immediately after. Nothing redundant.

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

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

For a simple two-parameter destructive tool with no output schema and annotations already flagging destructiveness, the description covers scope, recursion, and recoverability adequately. Missing only auth/permission notes and failure behavior for nonexistent paths.

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 only 50%: 'project' is documented but 'path' has no description. The description partially compensates by indicating the path may point to either a file or a folder, but it says nothing about path format (project-relative vs absolute) or the pinned-project fallback logic.

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

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

States a specific verb (deletes) and resource (file or folder, with its contents) scoped to a project, which is unambiguous against siblings like move_file, edit_file, or create_folder. It does not explicitly name or contrast with any sibling, so it stops short of a 5.

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

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

No when-to-use or when-not-to-use guidance is offered; the agent must infer that this is the tool for removal. There is no mention of alternatives (e.g., move_file to relocate rather than delete) or prerequisites before destroying content.

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

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

Annotations declare readOnlyHint=false and openWorldHint=true, so the fact that this writes to the local filesystem is already covered. The description adds 'any type' scope, but says nothing about overwriting an existing local file, creating parent directories, auth requirements, or size limits.

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

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

A single efficient sentence with the resource and destination front-loaded and no filler. It is appropriately sized, though the brevity comes at the cost of missing behavioral 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 write-to-local-disk tool with no output schema, the description should cover overwrite semantics, directory handling, and what is returned on success; none of that is present, and one required parameter is undocumented in both description and schema.

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 67%: `project` and `localPath` are documented in the schema, but the required `path` parameter has no description anywhere. The description's phrase 'to a path on this computer' merely paraphrases localPath and leaves the remote `path` meaning unresolved.

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

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

States a specific verb+resource: saving a project file of any type to a local path. This clearly separates it from upload_file (opposite direction) and read_file (returns content without saving), though it does not name those siblings explicitly.

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

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

No when-to-use guidance, no prerequisites, and no mention of when a user should prefer read_file (read inline) over download_file (save to disk). The agent must infer the distinction from the name alone.

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

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

Annotations only declare openWorldHint and destructiveHint=false, yet the description adds substantial behavioral context: live multi-collaborator visibility, merge-not-overwrite concurrency semantics, atomic all-or-nothing application, and the tracked-change/review flow under suggest=true. These are meaningful traits an agent could not infer from the annotations alone.

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

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

Three sentences that lead with the core action and then layer behavior and the suggest mode. Front-loaded and largely waste-free, though the first sentence is dense with clauses.

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

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

No output schema and only partial annotation coverage, so the description carries the behavioral burden well — atomicity, live merge, and suggestion semantics are all present. It omits auth/pinning expectations and the meaning of dryRun, but for a well-schema'd mutation tool this is close to complete.

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

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

Schema coverage is 80%, so the schema already documents oldText/newText/replaceAll/dryRun/project. The description adds meaning for suggest (tracked changes vs. direct edits) but says nothing about dryRun, replaceAll, or the pinned-project omission rule. Baseline 3 is appropriate when the schema carries most parameter semantics.

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

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

The description states a specific verb and mechanism: 'Applies exact search-and-replace edits to a file.' This clearly separates it from whole-file writers like write_file by the search-and-replace mechanic, though it never names that sibling explicitly, so the differentiation is implied rather than stated.

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

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

There is no explicit when-to-use guidance and no comparison to alternatives such as write_file or the suggest-mode review flow vs. direct edits. 'With suggest=true...' describes a mode's effect but not the condition under which an agent should choose it over a direct edit.

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

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

Annotations cover read-only and open-world behavior, but the description adds useful traits beyond them: it follows \input/\include from the main document and reports file:line for each heading. This reveals traversal behavior and output shape. It does not mention permissions or limits, but the added behavioral detail exceeds the annotation baseline.

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 packs the resource, traversal rule, and output format into one tight line.

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

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

With no output schema, the description does explain the return content (outline of parts/chapters/sections with file:line). It is nearly complete for a read-only outline tool, though it could say more about the returned structure or failure behavior if no main document is found.

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

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

Schema description coverage is 100%, so the schema already fully documents project and rootFile. The description adds no parameter-level meaning, such as how rootFile interacts with \input traversal. Baseline 3 is appropriate when the schema carries the parameter burden.

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 resource (document outline) and its scope: parts, chapters, sections, resolved through \input/\include from the main document. It gives enough detail to distinguish it from get_section and list_files, though it is not phrased as a clean verb+resource.

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, when-not-to-use, or alternative selection guidance is provided. An agent can infer that this retrieves the project outline, but the description never mentions get_section or other sibling tools that could also inspect document structure.

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

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

Annotations already cover the safe-read profile (readOnlyHint), so the description's real contribution is defining the boundary of what is returned — everything up to the next same-or-higher-level heading — plus the document-wide lookup scope. It omits error behavior when no section matches, which keeps it from a 5.

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

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

A single sentence that front-loads the return value and packs the boundary and lookup semantics without filler. Nothing to remove.

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 read-only retrieval tool with no output schema, the description explains what is returned and how the target is located, and the schema covers the parameters. Missing only not-found/error behavior and multi-file ambiguity handling.

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

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

Schema description coverage is 100% and all three parameters (file, title, project) are documented in the schema, including the case-insensitive exact-then-partial match rule. The description adds nothing about parameters, so the baseline of 3 applies.

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

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

The description states a specific verb and resource ('Returns the LaTeX of one section') and defines the exact extent of that resource ('up to the next heading of the same or higher level'), which distinguishes it from read_file and get_outline. It stops short of naming any sibling tool explicitly.

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

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

It implies the tool fetches a single section by title, and notes the title is searched 'anywhere in the document', but never says when to prefer this over read_file, get_outline, or search, nor any exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: it runs on local snapshots that refresh automatically when Overleaf reports changes, which tells the agent about data freshness and offline behavior.

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

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

Three tight sentences, front-loaded with purpose then behavior then routing. Every clause earns its place with 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 10-parameter tool with no output schema, the description covers result format (file:line), snapshot freshness, and sibling routing. Minor gaps remain (no explicit note on projects-argument defaulting beyond the schema), but it is nearly complete.

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

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

Schema description coverage is 70%, so the schema documents most parameters (include, projects, refresh, maxResults, contextLines, caseSensitive). The description only echoes that search can be exact/regex and that context is optional, adding little syntax or default detail beyond the schema.

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

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

States a specific verb and resource (regex/text search via ripgrep across projects) with concrete output shape (file:line results) and names the sibling it is not ("search"). An agent can distinguish it from among the 21 sibling tools without opening a schema.

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

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

"For topic-style questions use 'search' instead" explicitly names the alternative and the condition that selects it, which is strong routing guidance. It stops short of a full when/when-not treatment (e.g., no guidance on scope selection or refresh timing), so it is clear but not exhaustive.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the shape of what comes back (versions, authors, times, touched files), which matters because there is no output schema. It does not disclose ordering, pagination, or truncation behavior for the version list, so it falls short of a 5.

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

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

Two sentences, zero filler, with the resource scope front-loaded and the sibling routing placed last. 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?

With no output schema, the description usefully enumerates the returned fields, and the pointer to history_diff covers the main adjacent decision. Minor gaps remain around ordering and whether the list is paginated, but nothing essential for calling it correctly is missing.

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

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

Schema description coverage is 100%, so path, limit and project are all documented in the schema itself. The description adds nothing about parameter meaning, filtering semantics, or the pinned-project behavior beyond what the schema states — baseline 3 is appropriate.

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

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

The description names a specific resource and its contents ('recent changes recorded in Overleaf's project history: versions, authors, times and touched files'), which is far more than a restatement of the name 'history'. It also explicitly separates itself from the history_diff sibling. The verb is implicit (retrieve/list) rather than stated, which keeps it just short of a 5.

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

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

It names the alternative tool and the condition that selects it: 'Use history_diff to see what changed between versions.' That tells the agent when to reach for the sibling, though it never states positively when history itself is the right call (implied by 'recent changes').

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the return format (unified diff) and that output is scoped to a single file, which is useful given there is no output schema, but it says nothing about size limits on large diffs, pagination, or how missing versions are handled.

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

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

A single front-loaded sentence with no filler; the most important scoping information (one file, unified format, between two versions) comes first and the version-number source is parenthetically appended.

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 4-parameter tool with no output schema and low schema coverage, the description covers the critical question of where version numbers come from but omits path conventions, error behavior for versions that don't exist, and any indication of diff output size. Adequate but with clear gaps.

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

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

Schema description coverage is only 25% (only `project` is documented), so the description must compensate. It clarifies the meaning and source of `fromVersion`/`toVersion` beyond the bare integer schema, but leaves `path` (format, project-relative vs absolute) and the omitted-project pinning behavior to the schema 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?

States a specific operation (unified diff) on a specific resource (one file between two history versions), which is unambiguous. It implicitly separates itself from the sibling `history` tool by noting that the version numbers come from that tool, but it does not explicitly frame the sibling relationship beyond that hint.

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 parenthetical gives real usage context: the fromVersion/toVersion values must be obtained from the `history` tool's vFrom→vTo numbers, establishing a prerequisite workflow. It stops short of stating when-not to use it or naming an explicit alternative for viewing differences.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful interpretation: docs are editable text while 'binary/uploaded' entries are images/PDFs/uploads, which helps an agent interpret the output labels. It does not address ordering, size limits, or the exact form of the main-document marker.

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 zero filler, front-loading the core action before the clarifying note on file types. Slightly terse given it leaves usage and return shape unstated, but nothing is wasted.

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

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

For a one-parameter read-only listing tool with no output schema, the description covers purpose and the meaning of the two content categories. Missing are any note on tree ordering/shape or how the main document is marked, which would matter for an agent parsing the result.

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

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

Schema description coverage is 100%, and the schema already explains that the project may be a name, id, or Overleaf URL and may be omitted when one project is pinned. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource: it 'shows the file tree of a project,' which is clearly distinct from list_projects (projects, not files) and read_file (contents, not structure). It also calls out that the main document is marked, adding scope detail. It stops short of naming any sibling to differentiate against.

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 guidance and no alternative tools named (list_projects, read_file, get_outline are all plausible neighbors). The purpose itself implies the usage context — inspecting project structure before reading or editing — so usage is inferred 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?

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description usefully adds result ordering and the shape of each entry, but says nothing about the 30-second cache behavior (only hinted at via the refresh parameter in the schema), pagination, or rate limits.

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

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

A single tight sentence with the verb and scope front-loaded; the parenthetical packs ordering and returned fields efficiently. No wasted words, though it trades exhaustiveness for brevity.

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

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

With no output schema, the description compensates by naming the fields returned and the ordering, which is what an agent needs to consume results. The main gap is the two undescribed boolean filters and no mention of pagination or the cache.

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 67%, leaving includeTrashed and includeArchived undocumented in both schema and description. The description mentions 'tags' only as a returned field, adding no meaning to the tag, query, limit, or refresh 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?

Specific verb (Lists) plus resource (projects in the Overleaf account) with the ordering semantics (newest first, pinned first) and the fields returned (ids, last update, owner, access level, tags). Nothing in the sibling list (list_files, search, etc.) overlaps, so the agent can select it unambiguously.

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

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

The description states what is returned but never says when to reach for this tool versus list_files or search, nor any prerequisite (e.g. requires sign_in) or exclusion. Usage is only inferable from the resource 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?

Annotations declare destructiveHint=false and openWorldHint=true, so the safety profile is partly covered. The description adds a genuine side effect not in the annotations ('creating target folders as needed'), which is useful. However, it says nothing about what happens if the destination already exists (overwrite vs. error), which is the key behavioral risk for a move operation.

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

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

A single front-loaded sentence with no filler; the operation and its side effect are stated in one pass. Nothing redundant or padded.

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

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

For a three-parameter mutation tool with sparse annotations and no output schema, the description covers the core action and target-folder creation but omits destination-collision behavior and the interaction between 'from'/'to' and the optional 'project' scope. Adequate but with clear gaps.

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

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

Schema coverage is only 33% — only 'project' is documented. The words 'moves and/or renames' hint that 'to' may be a destination path or a new name, but the description gives no format, path-root, or collision semantics for 'from' and 'to'. It does not compensate for the undocumented required 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 states a specific verb pair and resource ('moves and/or renames a file or folder inside a project'), which is distinct from siblings like delete_file, write_file, and create_folder. It is clear what the tool does, but it does not explicitly name a sibling alternative or a boundary case to fully separate itself.

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 when-to-use, when-not-to-use, or alternative-tool guidance. The agent must infer from the verb alone that this is the tool for relocating or renaming existing content rather than editing, copying, or deleting it. No prerequisites (e.g., project pinning) 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?

Annotations only declare openWorldHint=false and idempotentHint=true, so the description adds real value by disclosing the cross-surface side effect that pins are shared with the VS Code panel, and by clarifying the dual pin/unpin behavior. It does not discuss permissions or what happens to pre-existing pins beyond the schema's wording.

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

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

Three short sentences with zero waste: the action, the consequence for other tools, and the external side effect, in that order. Every sentence earns its place.

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

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

For a 2-parameter tool with no output schema and partial annotations, the description covers the action, the scope effect, and cross-tool sharing. It is nearly complete, with only the additive/replacing behavior of repeated pin calls left implicit in the schema.

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

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

Schema description coverage is 100%, so both the 'unpin' flag and the 'projects' array are already documented structurally. The description adds no naming format or id-vs-name nuance beyond the schema, so baseline 3 applies.

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

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

States a specific verb and resource ('Pins (or unpins) projects') and immediately clarifies the semantic consequence of that state for other tools. It is clearly distinct from siblings like list_projects or status, though it does not name a sibling to contrast against.

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?

Explains the effect of pinning ('default scope for grep/search', single pin lets tools omit 'project'), which implies when an agent should call it, but never states explicit when-to-use or when-not-to-use guidance against alternatives such as passing an explicit project argument instead.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description still adds real behavioral context: content is live and may include unsaved collaborator edits, and the return type varies with file extension (images vs text). It omits what happens on a missing path, whether line ranges are 1-indexed/inclusive, and the cost of live reads, so it stops short of a 5.

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

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

Three short sentences, front-loaded with the live-content guarantee, then the optional range, then the media-type caveat. Every clause carries information an agent needs and nothing is repeated from the schema.

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

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

There is no output schema, so the description rightly explains the return shape (text vs image) and the line-range option, which is the main ambiguity for a 5-param read tool. Missing only error behavior for invalid or binary paths and the interaction between lineNumbers and a range, which keeps it short of complete.

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

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

Schema coverage is 60%: path, project, and lineNumbers are documented in-schema, while startLine/endLine have only numeric bounds. The description partially compensates by framing them as a combined 'line range', but does not say they are inclusive, 1-indexed, or whether endLine can be omitted while startLine is set. It adds little beyond the schema for the documented params.

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?

Specific verb+resource ('Reads a file live from Overleaf') with the defining scope called out: it returns the latest live content including collaborators' unsaved typing, which separates it from a saved-state read like download_file. It also states the two output shapes (text with optional line range, images returned as images), so an agent can tell it apart from grep/search without opening any schema.

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

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

Usage is implied rather than stated: 'live ... latest content' tells the agent to prefer this over a saved copy, and 'Images ... returned as images' hints at when it beats a text-only path. But no sibling is named and no when-not condition is given (e.g. use grep to find content across files, download_file for export).

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuinely useful context beyond that: the ranking algorithm, that results are file:line ranges with snippets (important since there is no output schema), and the natural follow-up tools. It does not address index refresh or result staleness, which keeps it from a 5.

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

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

Two tightly written sentences with zero filler. The core capability is front-loaded and the follow-up guidance is tacked on only after the essential purpose is stated.

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 search tool with no output schema, the description helpfully explains the return shape (file:line ranges with snippets) and the follow-up workflow, and annotations cover safety. The remaining gap is the undocumented refresh parameter and any index-freshness semantics, which an agent would have to guess.

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 60%: limit, matchAll and projects carry descriptions in the schema, while query and refresh have none. The description illustrates query semantics with a worked example but says nothing about refresh's behavior, and 60% coverage means the description does not fully compensate. Baseline 3 is appropriate.

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

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

States a specific verb and resource with real specificity: "Relevance-ranked full-text search (BM25 with fuzzy and prefix matching)" and what it finds ("passages about a topic"). It implicitly separates itself from the grep sibling via "ranked" and fuzzy/prefix matching, but never names grep, so the distinction has to be inferred.

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 example query and "finds passages about a topic" imply the right context, and it routes the agent onward to read_file/get_section for fetching text. However, it never states when NOT to use this (e.g. exact-match grep) or explicitly compare against the closest sibling, leaving the key choice to inference.

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

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

Annotations only declare openWorldHint and destructiveHint, so the description carries the behavioral load and does so well: it discloses the interactive browser-window flow, that it waits for a human, the supported login methods, and that the resulting session persists and is shared across all Overleaf tools on the machine. These are non-obvious traits an agent must anticipate.

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

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

Three sentences, front-loaded with purpose and the prerequisite relationship, then the two usage branches. Every sentence earns its place with 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 2-param, zero-required auth tool with no output schema, the description covers the interaction model, the cookie alternative, one-time use, and session scope. An agent has everything needed to call it correctly and to instruct the user.

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

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

Schema coverage is 100%, so the baseline would be 3, but the description adds genuine meaning beyond the schema: it tells the agent when to supply cookie instead of triggering the browser flow, and notes the cookie may be a full Cookie header. It adds little for server beyond the schema's default note.

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

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

States a specific verb+resource (signs in to Overleaf) and immediately frames its role among siblings: 'so the other tools work.' An agent can tell this is the authentication prerequisite for the other Overleaf tools rather than a data 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?

Explicitly says when to use it ('only needed once'), gives the alternative path when a cookie is available ('If the person gives you their overleaf_session2 cookie, pass it instead'), and describes the default flow when no cookie is given. Nothing is left to inference.

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

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

Annotations already convey readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds value by disclosing the diagnostic role and roughly what information the call returns (account, server, pinned projects, search engine) — useful given there is no output schema.

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

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

Two tight sentences with zero filler. The content summary comes first and the actionable troubleshooting instruction is front-loaded at the end where it is most likely to be acted on.

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

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

For a zero-parameter, read-only status tool with no output schema, the description adequately covers both what it returns and when to invoke it. It could be slightly richer on the exact shape of the returned status, but nothing essential for correct invocation is missing.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a parameterless tool is 4.

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 ('Shows') and enumerates exactly what the tool surfaces: the signed-in account, the server, pinned projects, and the search engine. That enumeration makes it clearly distinct from sign_in and list_projects, though it does not name a sibling to contrast against.

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?

'Call this first if other tools report sign-in problems' gives an explicit triggering condition for using this diagnostic tool. It does not, however, mention the alternative (sign_in) or state when not to bother calling it.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true, and the description reinforces this by naming exactly what gets destroyed: any file with the same path is replaced. That concrete overwrite disclosure is real added value beyond the annotation flag, though nothing is said about permissions or whether missing parent folders are 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?

A single sentence that front-loads the core action and folds in examples and the overwrite behavior without any wasted clauses. Nothing could be trimmed without losing information.

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

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

With no output schema, the description still covers direction (local to project), destination behavior, and the destructive overwrite. Gaps remain around failure cases (nonexistent path, folder creation) and auth, but for a three-parameter tool with a fully documented schema it 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?

Schema description coverage is 100%, so all three parameters (path, project, localPath) are already documented with defaults and pinning behavior. The description adds only the vague notion of a matching 'path' and a project target, so the baseline 3 applies.

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

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

States a specific verb and resource ('Uploads a file from this computer into a project') and clarifies the source is the local machine, which distinguishes it from write_file and download_file. It stops short of naming a sibling explicitly, so an agent must infer the contrast from the local-vs-project framing.

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 examples ('a generated figure or .bib') imply the intended scenario of pushing locally-produced artifacts into a project, but there is no explicit when-to-use vs write_file/download_file guidance and no stated prerequisites. Usage is implied rather than directed.

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

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

Annotations already flag destructiveHint=true and openWorldHint=true, so the safety profile is partly covered. The description adds genuine behavioral context beyond that: missing folders are auto-created, overwrites use a 'minimal live diff' preserving collaborator cursors, and the schema documents overwrite defaulting to true. It doesn't state permission/auth requirements or what happens if a co-editor changes the file during the write.

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 operation and scope, then the routing hint. Every clause carries information the agent needs; no restatement of the title or boilerplate.

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 mutation with no output schema, the description covers creation, overwrite behavior, and the edit_file routing decision, and annotations carry the safety hints. Remaining gaps are secondary: no return value discussion, no conflict/error behavior, no project-disambiguation guidance for the optional project param.

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 60% (project, suggest, overwrite documented; path and content bare), so the baseline is a middling 3. The description implies 'full content' semantics for the content parameter and relates path to folder creation, but adds no format, encoding, path-resolution, or tracked-change detail beyond what the schema already states.

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

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

States a specific verb and resource ('Writes the full content of a text file') plus the creation scope ('creating it (and missing folders) if needed'). It names the sibling edit_file explicitly, so an agent can separate this from the small-edit tool without opening either schema.

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

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

'Prefer edit_file for small changes' gives an explicit alternative with the condition that selects it, which is the key routing decision among the file tools. However it doesn't cover the other nearby alternatives such as upload_file, create_folder, or delete_file, so the coverage is clear but not exhaustive.

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