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

All annotation hints are false, providing only coarse signals. The description adds specific behavioral context beyond the annotations by stating the tool never reverts or deletes files, and that it only closes sessions without pending local edits. It does not disclose idempotency effects or what happens if called with pending edits, but the added detail is meaningful.

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, front-loaded sentences clearly convey the action, condition, and safety scope. There is no wasted text or redundant phrasing.

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

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

For a single-parameter tool with an output schema, the description is nearly complete: it defines when to call, what the parameter is, and what the tool will not do. A minor gap is not referencing workflow_status to check for pending edits before calling, but the tool remains correctly usable without that.

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 session_id must be an active sessionId from begin_edit_session or workflow_status. The tool description adds no additional parameter semantics beyond the schema, so the baseline score of 3 applies.

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

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

The description states the specific action (close a session) and the condition under which it applies (no pending local edits), and explicitly notes it never reverts or deletes files. This clearly distinguishes it from sibling tools like write_report_file or begin_edit_session.

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 an explicit invocation condition: only when the session has no pending local edits. It also rules out a common misuse by clarifying the tool is not for reverting or deleting files. It does not name an alternative for discarding edits, but the context is sufficient for an agent to avoid incorrect use.

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 mutation/idempotency profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds useful behavioral context: synchronization, conflict detection, and sessionId return. However, it does not disclose what side effects the Git/Overleaf synchronization may have, which would add value given readOnlyHint=false.

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 that states the operation, the check performed, and the returned artifact. Every clause contributes meaning and there is no repetition of schema or annotation content.

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

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

For a zero-parameter tool with an output schema and sibling context, the description covers the core workflow and why the sessionId matters. It could further clarify what 'safe' means or when abort_edit_session becomes relevant, but nothing essential is missing for correct invocation.

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

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

The input schema has zero parameters, and the description correctly focuses on the output rather than inputs. Per the rubric, 0 params earns a baseline 4; the description's mention of the returned sessionId is adequate and adds no unnecessary parameter noise.

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 action ('Synchronize Git and Overleaf'), a distinct outcome ('detect baseline conflicts'), and a concrete deliverable ('return the sessionId required by report tools'). This clearly distinguishes begin_edit_session from siblings like abort_edit_session and read_report_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 'required by report tools' establishes that this session must be started before using other report tools, giving clear contextual usage. It does not explicitly state when not to use it or contrast it with abort_edit_session, but the implied workflow is sufficiently clear.

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

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

Annotations already indicate idempotent, non-readOnly, and non-destructive behavior. The description adds the useful side effect of saving the PDF in the workspace, but it does not explain overwrite behavior, remote compilation delays, failure modes, or access requirements. It minimally extends what annotations already provide.

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 the primary action and side effect front-loaded. There is no filler, and the minor repetition of 'configured' does not hurt clarity.

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?

An output schema and annotations cover return values and safety, but the definition is incomplete for a compile tool: the only parameter is undocumented, and the relationship to the publishing workflow is unclear. An agent cannot confidently determine when to call it or what root_document should be.

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 sole parameter root_document is entirely unexplained, and schema description coverage is 0%. The description never mentions what root_document should contain, whether it selects a subfile, or how it interacts with the configured project, so the agent receives no semantic help for the parameter.

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

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

The description clearly states the action ('Compile'), the object ('configured remote project'), and the outcome ('save its PDF inside the configured workspace'). It distinguishes the tool from list/read siblings, though it leaves the title's 'download' aspect ambiguous and does not explicitly contrast with preview_publish or confirm_publish.

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

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

There is no guidance on when to use this tool versus siblings like preview_publish, confirm_publish, or read_report_file. It also does not mention prerequisites such as an active edit session or how the workspace is configured, so usage context is left entirely implicit.

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?

Independent of annotations, the description discloses significant side effects: it revalidates, commits, pushes to Git, uploads files, and verifies Overleaf. This goes beyond the generic annotations (readOnly=false, not idempotent) and gives the agent a concrete sequence of state-changing actions, though it does not cover failure or rollback 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?

The description is a single, compact sentence that uses ordering words ('first', 'afterward') to convey a clear sequence without filler. It could be slightly clearer with a bulleted step list, but it remains appropriately sized and front-loaded.

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

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

The tool has five required parameters and a complex publish workflow, yet the description omits what summary, changelog, and validation should contain, what qualifies as 'approved files', and how to recover if verification fails. The presence of an output schema mitigates the need to describe return values, but not the missing parameter guidance.

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 only one of five parameters described in the schema (session_id) and no mention in the description of summary, changelog, validation, or preview_token, the agent cannot determine what values to supply. The phrases 'preview' and 'approved files' loosely allude to preview_token and validation but never define their contents or formats.

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

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

The description clearly identifies a multi-step finalization action—revalidating the preview, committing and pushing Git, uploading approved files, and verifying Overleaf—which goes beyond the title and distinguishes it from preview-only siblings. It is specific about the resource and workflow, though it never names Overleaf as the publication target in one explicit phrase.

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 temporal instruction 'commit and push Git first' implies this runs after a preview/review step, and the word 'confirm' aligns with the final stage of the edit session. However, it never explicitly says to use it after preview_publish or when not to use it, so the agent must infer the workflow context from the tool name and siblings.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description adds a meaningful constraint: credentials are not revealed. It also spells out what status areas are covered. It does not contradict any 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?

One sentence, front-loaded with the verb, and every element (configuration, Overleaf access, Git state, workflow, no credentials) adds information. 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 zero-parameter read-only inspection tool, the description covers what is checked and the key safety behavior, while the output schema handles return-value details. Nothing essential is missing.

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

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

With zero parameters, the schema is trivially complete and parameter semantics impose no burden. The baseline 4 is appropriate because there is nothing for the description to clarify.

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 action ('Check') and enumerates the exact scopes inspected: configuration, Overleaf access, Git state, and active workflow. It is clear, but it does not explicitly distinguish this from the sibling workflow_status tool, so an agent must infer the boundary.

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 diagnostic use but gives no explicit guidance about when to call connector_status instead of workflow_status or other siblings. There are no exclusions or alternative tool references.

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 establish the safety profile (readOnly, idempotent, non-destructive), so the description's addition of the 'active synchronized edit session' precondition is meaningful extra context about valid call conditions. There is no contradiction with annotations.

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

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

A single sentence that front-loads the action and object, with no filler. Every word adds 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 one-parameter list operation with full schema coverage, an output schema, and safety annotations, the definition is nearly complete. It could explicitly mention the behavior for an invalid or expired session, but that is inferable from 'active'.

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 provides 100% coverage, including the source format and origin of session_id, so the description need not repeat parameter details. The description adds no extra parameter semantics, but the schema already carries the burden, warranting the baseline 3.

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 identifies a specific verb ('List') and resource ('report files') and adds a distinct context ('active synchronized edit session'), which separates it from siblings like read_report_file or begin_edit_session.

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 clearly frames when the tool applies — during an active synchronized edit session — implying a prerequisite such as a prior begin_edit_session call. It does not explicitly name alternatives or exclusions, so it stops short of 5.

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 idempotency, destructiveness, and read-only hints, so the description only needs to add extra behavioral context. It does add the blocking-on-conflicts behavior and the previewToken outcome, but it does not clarify what side effects exist given readOnlyHint=false, such as token creation or session state changes.

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 tightly packed sentence conveys the core action, the success return, and the failure/blocking condition without filler. Every clause earns its place.

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

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

For a single-parameter tool with an output schema, the description covers the main behavior and blocking scenario. It is complete enough for an agent to know what to expect, though it could briefly mention that this is the pre-confirm step in the publication workflow.

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 only parameter, session_id, is fully documented in the schema. The description adds no additional meaning about how session_id is used or its format, but the schema already provides the necessary detail, 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?

The description names a specific action ('Perform a three-way comparison'), a concrete return value ('previewToken'), and a distinct blocking behavior ('block on same-file conflicts and deletions'). This clearly separates it from confirms, read/write, and workflow-status siblings even without naming them.

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 this tool should be called relative to siblings like confirm_publish, begin_edit_session, or write_report_file. The preview/confirm relationship is implied by the title, but the description never states 'use this before confirm_publish' or when it should be avoided.

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 establish readOnly and non-destructive behavior. The description adds the non-obvious behavioral detail that reading returns a SHA-256 precondition rather than just file contents, which is useful context beyond the annotations.

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

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

The description is a single, front-loaded sentence with no filler. Every phrase earns its place, and the core action and outcome are immediately understandable.

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

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

For a simple read tool with an output schema and strong safety annotations, the description provides the essential context. It does not explicitly state when to call it relative to write_report_file, but that is reasonably inferable from 'safe write.'

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%: session_id has a description, but path is just a string with minLength. The description does not clarify either parameter or their relationship, so path semantics remain largely undocumented beyond the schema.

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

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

The description uses a specific verb ('Read'), names the resource ('report source file'), and specifies a distinctive outcome ('return the SHA-256 precondition required for a safe write'). This clearly distinguishes it from siblings like list_report_files and write_report_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 clearly implies when to use this tool: before a safe write, to obtain the required SHA-256 precondition. It does not explicitly name alternatives or state exclusions, so it stops short of a 5.

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, idempotentHint true, destructiveHint false). The description adds value by detailing the specific information returned, giving the agent clear expectations for the output. No contradictions with annotations.

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

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

A single, compact sentence that leads with the action and lists key deliverables without any filler. Perfectly 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?

Given that an output schema exists and there are no parameters, the description fully covers what the tool returns. The listed components align with the expected workflow state, and no additional information is needed for correct invocation.

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

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

The tool has zero parameters, so the baseline is 4. The description appropriately avoids parameter explanations since there are none to document.

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

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

The description states a specific verb 'Return' and enumerates the exact state components (active edit session, allowed next actions, preview, conflicts, recovery journal), making its purpose unmistakable. It clearly distinguishes itself from sibling mutation tools like begin_edit_session and abort_edit_session by being an inspection tool.

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

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

There is no explicit guidance on when to use this tool versus alternatives. The description does not mention scenarios, exclusions, or conditions, leaving the agent to infer usage. While the purpose is obvious, the lack of any usage direction prevents a higher score.

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

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

Annotations already mark the tool as non-read-only and non-destructive; the description adds that writes are conditional on session state and expected hash, and that content must be UTF-8. This gives useful behavior beyond the boolean hints, though mismatch/error behavior is not explained.

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

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

Two short sentences front-load the safety-critical constraints and add only one necessary parameter semantic. There is no filler or repetition of schema fields.

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

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

For a mutating file-write tool with an output schema, the description covers session precondition, hash-matching rule, and new-file sentinel. It is slightly incomplete on what happens when the hash does not match, but an agent can invoke it correctly.

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

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

Schema coverage is only 25%, so the description must compensate. It does: it defines the expected_sha256 contract ('use new for a new file') and constrains content encoding to UTF-8. Path and full hash semantics remain implicit, so not a 5.

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—writing UTF-8 report-source content—and adds the session-limited scope. The write operation is unmistakably distinct from the read/list/compile/publish siblings, even though no sibling is named 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 provides clear preconditions for use: only inside an active session and only when expected_sha256 matches, with 'new' signaling a new file. It does not name an alternative tool or an explicit when-not-to-use case, so it stops short of a 5.

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