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

No annotations are provided, so the description carries the full behavioral burden. It usefully discloses the multi-sheet default and the sheetName-over-allSheets precedence, but says nothing about overwrite behavior at targetPath, required permissions, or error/failure reporting for a tool that writes files.

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, front-loaded with the core capability and output formats, then the non-obvious XLSX caveat. No wasted 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 conversion tool with no output schema, the description covers the format space and the main edge case (multi-sheet XLSX). It lacks any note on return value or overwrite semantics, but is otherwise adequate to invoke correctly.

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

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

Schema description coverage is 100%, so both paths and both sheet options are already documented; baseline is 3. The description reinforces the sheetName/allSheets precedence but adds no new syntax or constraint 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 (convert) plus resource (document) and enumerates the supported output formats, and names the underlying engine (x2t). This clearly distinguishes it from sibling write/read tools like r7_read, r7_create, or r7_edit.

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

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

Gives explicit conditional guidance for the XLSX-to-PDF case: default exports every worksheet in tab order, and passing sheetName or allSheets: false restricts to one sheet. It does not name an alternative tool for in-place editing vs conversion, so it stops short of full routing guidance.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the overwrite guard ('refuses to replace an existing file unless overwrite is true'), which is real behavioral context, but it says nothing about permission requirements, behavior on unsupported extensions, or where the file is written.

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

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

Two short sentences with zero waste; the core action is front-loaded and the overwrite caveat follows immediately. Nothing is padded or 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?

With a rich 100%-covered schema and no output schema, the description covers the essential purpose plus the one non-obvious behavioral rule. It is nearly complete, lacking only notes on failure modes or return behavior that an agent might benefit from.

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 every parameter including the format-specific ones (sheets, tables, paragraphs, title, overwrite) is already documented in the schema. The description adds no format syntax or constraint detail beyond that, 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?

States a specific verb ('Create') and resource ('DOCX, XLSX or PPTX document') with the scoping qualifier NEW, which clearly separates it from siblings like r7_edit, r7_replace, r7_insert, and r7_sheet_write. An agent can identify the tool's operation without opening the 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?

The refusal-to-replace rule implies the correct usage context (creating a fresh file rather than modifying one), but the description never names an alternative sibling such as r7_edit or r7_slide_create for existing documents, nor states when this tool should be preferred. Usage is implied rather than guided.

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

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

With no annotations, the description carries the full burden, and it does disclose the key prerequisite that arbitrary JS requires developerMode enabled. However it omits whether execution mutates the live document irreversibly, whether changes are saved automatically, and any side-effect or rate-limit behavior for a mutating exec tool.

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

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

Two tightly packed sentences with the core purpose front-loaded and the developerMode caveat following. No filler or redundancy.

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

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

There is no output schema and no return-value description, and the description never clarifies the relationship to the numerous sibling document-editing tools. For an exec tool with complete schema coverage it is adequate but leaves real 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 100%, so the schema already documents args, code, and the safeCommand enum. The description adds no parameter syntax or interaction detail beyond what the schema provides, 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 (Execute) and resource (safe built-in command or custom DocScript) scoped to 'live opened document in R7 Desktop', which distinguishes it from offline docx/sheet/slide tools. It does not, however, differentiate it from closely related siblings like r7_edit or r7_insert that also mutate documents.

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 pick this over r7_edit, r7_insert, or r7_table, nor any exclusion. The agent must infer that this is the low-level escape hatch versus the higher-level editing tools.

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

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

No annotations are provided, so the description carries the full burden. It does not disclose what happens when no window is focused, whether replace requires an existing selection, or any permission/error behavior for this desktop-control tool. 'Replace' implies mutation but nothing about reversibility or side effects is given.

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 wasted words. It could afford one more clause given the preconditions involved, but nothing is 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 no-annotation, no-output-schema tool that mutates desktop state, the definition is minimal-viable but incomplete: it omits return shape for 'get', focus prerequisites, and failure modes for 'replace'.

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 action enum and the text parameter are already documented in the schema. The description adds no syntax or format detail beyond that baseline.

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 pair (get/replace) and resource (selected text in the active R7-Office Desktop editor window), which is clear and distinguishable from most siblings. However, it does not differentiate from close siblings like r7_desktop_exec or r7_replace, so the agent must infer which to use.

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

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

No explicit when-to-use or when-not-to-use guidance. The phrase 'currently active ... window' implies a focus precondition but neither states it as a requirement nor points to alternatives such as r7_desktop_status or r7_replace.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the 'local bridge' dependency and that it reports live (as opposed to cached) state plus a security policy, which is real context. It stops short of saying whether the bridge must be running, what happens on failure, or whether it is strictly read-only.

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 with no filler, front-loading the action and the object being inspected. Every clause (live status, security policy, local bridge) 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 zero-parameter diagnostic whose only dependency (the local bridge) is named, the definition is nearly sufficient. The remaining gap is that no output schema exists and the description doesn't hint at what the returned status looks like, but little else 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; the baseline for a parameterless tool is 4. No syntax or argument context is needed.

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

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

States a specific verb (Check) and a specific resource (live connection status and security policy for open R7-Office Desktop windows). An agent can distinguish it from siblings like r7_desktop_exec (which acts) and r7_desktop_selection (which reads the selection), though it never explicitly names those alternatives.

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

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

There is no when-to-use guidance, no mention of when this status check is or isn't appropriate, and no reference to the sibling desktop tools it might precede or replace. The scope is implied by the name but nothing routes the agent here versus r7_desktop_selection.

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

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

With no annotations, the description carries full burden; it discloses the key behavioral trait that values are normalized (points, #RRGGBB, never raw OOXML), which materially shapes output interpretation. It stops short of explicitly confirming the operation is non-mutating, though 'Read' implies it.

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

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

A single dense sentence, front-loaded with the verb+resource and the 'before changing it' rationale, followed by the enumerated payload. It is long but every clause enumerates real content, so little 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?

No output schema exists, so the description bears the return-shape burden and does so thoroughly, enumerating paragraph, table, section and header/footer detail. For an 8-param read tool it is complete enough to call correctly.

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

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

Schema description coverage is 100%, so every parameter (count, fromParagraph, includeRuns, includeTables, etc.) is already documented in the schema with defaults. The description lists return content but adds no syntax or semantics beyond that, 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?

Specific verb ('Read') plus resource ('normalized formatting of a DOCX document') and an enumeration of exactly what is read (paragraph styles, table cells, sections, headers/footers). It stands apart from generic siblings like r7_inspect/r7_read through specificity, though it never names them explicitly.

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

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

The phrase 'before changing it' implies a when-to-use (inspection prior to an edit), which is useful implied guidance. It stops short of stating when-not to use it or pointing to the overlapping r7_inspect/r7_read tools for other needs.

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

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

With no annotations, the description carries the full behavioral burden and does so well for the highest-risk operation: it explains that setText rewrites only non-field runs and preserves PAGE/NUMPAGES/DATE fields, and that page-number fields are emitted in the fldSimple form both R7 and Word understand. It still omits in-place-vs-copy default behaviour and read/list return shape, keeping it 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 sentences, zero waste, front-loaded with purpose and then the two behavioural facts an agent most needs. Nothing is repeated from the schema or title.

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 12-parameter mutating tool with no output schema and no annotations, the description covers the critical risk (destroying existing page-number fields) and the field encoding used. Gaps remain around the default in-place edit versus outputPath copy, and what list/read return, but these are largely stated 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 the schema already defines all 12 parameters including enums and defaults; the baseline is 3. The description adds field-form context relevant to pageNumber, but does not add per-parameter meaning beyond what the schema 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?

The first sentence states a specific verb set (read, create, re-text) and an unambiguous resource (DOCX headers and footers), which no sibling tool (r7_docx_sections, r7_docx_formatting, r7_docx_image) covers. An agent can route here without opening the 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 only implied by the resource scope; there is no explicit when-to-use, when-not, or named alternative against the neighbouring docx tools. The action enum itself is documented in the schema, not the description, so routing between list/read/setText/remove is left to the schema.

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

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

With no annotations, the description carries the full disclosure burden and does real work: insert writes an external relationship deduplicated by URL plus a Hyperlink-styled run, re-text keeps the relationship and run formatting, and list returns text and target URL. It stops short of stating permission requirements, in-place vs copy semantics, or error behavior.

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

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

Two front-loaded sentences: the four verbs lead, then per-action behavior follows. Dense and largely waste-free, though the second sentence is long and could be split for 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?

For a 16-parameter mutation/read tool with no annotations and no output schema, the description usefully summarizes what 'list' returns and how writes behave, compensating for the missing output schema. It does not touch several formatting parameters (bold, italic, alignment) that only the schema covers.

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 88%, so the schema already documents url, text, index, style, paragraphIndex, etc. The description adds behavioral meaning for the actions but no syntax or format detail beyond the schema, so the 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 opens with a specific verb+resource pairing (read/insert/re-text/remove DOCX hyperlinks) and enumerates all four modes, which no sibling tool (r7_docx_formatting, r7_edit, r7_insert) covers. An agent can immediately tell this is the hyperlink-specific tool rather than a general text or formatting 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?

The four actions are listed and partly explained, implying when each applies, but there is no explicit when-to-use guidance, no exclusions, and no naming of alternative tools (e.g., when to prefer r7_edit or r7_insert over this). Usage is inferred from the action enum 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?

With no annotations, the description carries the full burden and does well: it discloses that inserting creates the media part, relationship, and content type, that aspect ratio is preserved with a single dimension, and that existing images and relationships are never touched (a non-destructive guarantee). It omits permission/auth context and the return shape for list mode.

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 primary action and resource, with the behavioral guarantees packed efficiently afterward. 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?

There is no output schema, yet the description never explains what the list mode returns or the format of inserted results. For a 12-parameter tool the insert path is well covered, but the list path's behavior and return are left unspecified.

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 schema documents all 12 parameters, and the schema already states for widthCm that height derives from aspect ratio. The description's aspect-ratio note largely restates that, so it adds little beyond structured fields; baseline 3 is correct.

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 specific verbs and resource: insert a PNG/JPEG/GIF into a DOCX, or list the images in it. This clearly distinguishes it from formatting, section, and table siblings without needing their schemas.

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

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

The dual 'insert or list' framing gives implied usage and the action enum reinforces it, but there is no explicit when-to-use guidance, no prerequisites, and no named alternative (e.g. use r7_docx_formatting for styling). Usage is inferable but not spelled out.

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

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

With no annotations the description carries the full burden, and it does add a genuinely useful behavioral fact: changing one property preserves the rest of the section (headers, footers, columns, grid, title-page). It still omits permission requirements, in-place vs copy side effects, and what 'read' reports, so disclosure is helpful but incomplete for a mutation tool with zero annotation support.

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, front-loaded with scope and followed by the key preservation guarantee. No filler or redundancy.

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

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

For a 17-parameter tool with nested objects and no output schema, the description covers scope, actions, and the section-preservation behavior well. The main gap is the shape of 'read' output, which the absence of an output schema leaves undocumented.

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

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

Schema description coverage is 100%, so the baseline is 3. The description names some property families that map to parameters (margins, columns, page-number restart) but adds no syntax, units, or defaults beyond what the schema already documents.

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 pair ('Read or change') and resource ('DOCX page setup and sections') and enumerates the exact properties covered (page size, orientation, margins, columns, page-number restart, breaks). An agent can distinguish this from siblings like r7_docx_formatting or r7_docx_header_footer 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?

The property list implies when the tool applies (page/section layout), and the schema's action enum conveys read/set/insertBreak/remove. However, there is no explicit when-to-use guidance or routing against siblings such as r7_docx_formatting, so selection remains partially inferential.

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

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

No annotations are provided, so the description carries the full load, and it does disclose meaningful behavior: the paragraph retains its own properties (section break, list numbering, spacing) and the new text inherits the previous first run's formatting unless overridden. It omits the destructive/overwrite implications of deleteParagraph and the in-place default write, which the schema alone covers.

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

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

Two sentences with no waste; the core action is front-loaded and the second sentence adds only genuinely new preservation semantics.

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

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

For an 8-parameter, mutation-capable tool with a nested formatting object and no annotations or output schema, the description covers the key behavioral contract (formatting inheritance, property preservation, removal). It leaves the in-place write default and delete semantics to the schema, which is a minor gap.

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

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

Schema description coverage is 100%, so the baseline is 3. The description clarifies the preserveFormatting/formatting interplay ('inherits the previous first run's formatting unless you ask for different formatting'), which adds slight meaning, but it does not explain paragraphIndex sourcing 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 set (edit, update, remove) and a precise resource (a specific paragraph in a DOCX document). An agent can tell this is the in-place paragraph editor rather than a document-wide replace, though the description never names the likely sibling alternatives (r7_replace, r7_insert).

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 only implied: 'a specific paragraph' suggests targeting by index, and 'remove a specific paragraph' hints at the delete case. There is no explicit when-to-use/when-not guidance and no routing to the closest siblings (r7_replace for text substitution, r7_insert for adding 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?

No annotations are supplied, so the description carries the full behavioral burden. It says nothing about whether the DOCX file is modified in place or a copy is produced (outputPath hints at a copy but this is unexplained), what happens to existing content at the anchor, or any permission/error behavior. For a 26-parameter mutation tool this is a substantial gap.

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 the core action front-loaded and no filler. The second sentence earns most of its place by scoping what formatting can accompany the inserted content, though it borders on restating schema fields.

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

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

For a tool with 26 parameters, nested objects, no annotations, and no output schema, two sentences are far too thin. Missing are mutation semantics (in-place vs outputPath copy), anchor/targetIndex interaction detail, and any cautionary context an agent needs before writing to a document.

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 88%, so the schema already documents nearly every parameter thoroughly. The description adds only a light gloss — that the inserted paragraph can carry alignment, indents, spacing and font — which loosely frames but does not extend the schema's own parameter docs. Baseline 3 applies when the schema does the heavy lifting.

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 verb (insert) and enumerates the resource variants (paragraph, heading, list item, page break) plus the anchor options (start, end, relative to another paragraph). This is clear and concrete, but it never distinguishes itself from overlapping siblings like r7_edit, r7_replace, or r7_create, so an agent gets no routing signal.

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 or when-not-to-use guidance, no prerequisites, and no named alternative despite several siblings that plausibly overlap (r7_edit, r7_replace). The usage is only inferable from the verb and the mention of insertion anchors.

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

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

No annotations are provided, so the description carries the full burden, and it discloses nothing about behavior: not that it is a non-destructive read, not whether it opens/locks the file, not what happens on an unsupported or corrupt file. Only the implied semantics of 'inspect' suggest read-only, which is thin for a 7-parameter tool.

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

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

A single front-loaded sentence with zero filler, opening with the verb and resource before the enumeration. The facet list is dense but each item maps to real output, so little 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?

With no output schema and no annotations, the description should say more about what an inspection returns and how it differs from r7_read/r7_pdf_inspect. It is adequate for a read-only survey tool with fully documented parameters, but the absence of routing and output context leaves 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 100%, so each parameter (includeLists, includeImages, includeStyles, etc.) is already documented in the schema, including its DOCX-only limitation. The description's facet list loosely echoes those parameters but adds no syntax, default, or interaction detail beyond the schema, 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 ('Inspect') and resource ('document structure') and enumerates the exact facets covered (outline, metadata, headings, tables, sheet/slide lists, sections, headers/footers, images, hyperlinks). This clearly separates it from content-reading siblings like r7_read and from r7_pdf_inspect, though it never names 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?

There is no guidance on when to choose this tool over r7_read, r7_sheet_read, r7_slide_read, or r7_pdf_inspect. The use case (surveying structure before extracting content) must be inferred entirely from the tool name and the facet list.

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

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

With no annotations provided the description carries the full burden, and it discloses the important behavioral trait that setting repair mutates the file in place to fix CMap entry counts, plus the concrete symptom (text copies out as garbage). It does not explicitly state that the default path is non-mutating or mention permission/auth needs, leaving a small gap.

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 purpose before the use case and parameter guidance, so nothing is buried. It is dense with enumerated clauses, which slightly taxes readability, but every clause carries distinct 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?

Though there is no output schema, the description effectively specifies the return content (page/font inventory, drawn-glyph counts, empty-fill counts, extractability, verdict), and it covers purpose, usage, and the single non-trivial parameter. Nothing an agent needs to invoke 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 coverage is already 100%, so the baseline is 3, but the description adds meaning beyond the schema by explaining what repair actually fixes (malformed ToUnicode CMap entry counts) and the real-world consequence it addresses (R7-exported body text copying out as garbage). That extra context exceeds the schema's drier 'rewrites filePath' wording.

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 ('Measure the text fidelity of a PDF') and enumerates exactly what is measured (page/font inventory, drawn glyph counts, empty glyph fills, extractability, a text/outlined/mixed verdict). The diagnostic scope distinguishes it from the generic sibling r7_inspect without needing to open 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?

Gives a clear triggering scenario: 'Use it to prove a PDF export kept its text instead of silently losing it,' and names the condition that selects the repair mode (malformed ToUnicode CMap making body text copy as garbage). It does not explicitly contrast with the sibling r7_inspect or state exclusions, so it falls just short of full routing guidance.

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

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

No annotations are provided, so the description carries the behavioral burden. It usefully signals that output can be normalized/structured across several document formats, but says nothing about failure modes (missing file, unsupported format), permissions, or what the returned text looks like.

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. It is slightly list-heavy but every clause identifies a supported capability, so it earns its length.

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 an 11-parameter, multi-format read tool with no annotations and no output schema, the description covers the surface but omits return-value expectations and format-to-parameter guidance. It is minimally adequate given the rich schema descriptions, but not complete.

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

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

Schema description coverage is 100%, so the schema already documents all 11 parameters with format-specific detail. The description adds only a broad mapping of formats to capabilities and does not explain parameter interactions beyond what the schema states; 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 (Read) and enumerates the resource types it handles (structured text, filtered paragraphs, markdown preview, spreadsheet ranges, slides). However, it does not differentiate itself from siblings like r7_sheet_read, r7_slide_read, or r7_inspect, so an agent cannot tell from the description alone which read tool to pick.

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

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

No explicit when-to-use or when-not-to-use guidance, and no mention of the several sibling read tools that overlap in scope (r7_sheet_read, r7_slide_read, r7_inspect). The only usage hint ('Read this before changing a document') lives inside a parameter description, not the tool description.

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

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

With no annotations, the description carries the full burden — and it does disclose one important behavioral trait: replacement preserves existing run formatting, fonts, colors, and styles. However, it says nothing about whether the original file is mutated in place versus only written to outputPath, nor about error behavior when the search text is absent.

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 with no padding, front-loading the action before the formatting-preservation guarantee. 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 6-parameter mutation tool with no annotations and no output schema, the description omits in-place-vs-outputPath semantics and any result/error information. The formatting-preservation guarantee is the main value added; the rest of the behavioral surface is thin.

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 six parameters (including matchCase and replaceAll defaults) are already documented in the schema. The description adds no syntax or format detail beyond that; the mention of 'run formatting' is behavioral rather than parameter-level. 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 gives a specific verb+resource ('search and replace text in DOCX') plus a distinguishing scope note ('strictly preserving all existing run formatting, fonts, colors, and styles'). It is clear what the tool does, though it never explicitly distinguishes itself from the sibling mutation tools r7_edit or r7_insert.

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 guidance: nothing says when to pick this over r7_edit or r7_insert, or what preconditions exist (e.g., file must exist, format must be DOCX). Usage is only implied by the verb 'replace'.

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

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

No annotations are provided, so the description carries the burden. It does add real behavioral context by promising 'Other sheets are left untouched', which reassures against collateral damage. It does not disclose whether the file is mutated in place, how outputPath affects the original, permissions needed, or whether an existing sheet with the same name is overwritten.

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 front-loads the action and resource, and the trailing clause about other sheets is the one piece of non-obvious scope information worth keeping. Zero waste.

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 five-parameter, fully schema-documented tool with no output schema, the description covers purpose and side-effect scope adequately. It is slightly thin on how outputPath interacts with the original file, which is the one thing an agent might need but cannot get from the schema alone.

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

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

Schema description coverage is 100%, so the schema already documents all five parameters (data, name, index, filePath, outputPath) with meaningful text. The description's phrase 'optionally with initial data' only loosely echoes the `data` parameter and adds no new semantics, so the baseline of 3 is appropriate.

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

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

States a specific verb and resource ('Add a new worksheet to an existing XLSX workbook'), so the agent knows exactly what it creates. It also scopes the effect ('Other sheets are left untouched'). It does not name the sibling it differs from (e.g., r7_sheet_write or r7_create), so it stops short of full sibling differentiation.

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?

Implied usage is clear from 'to an existing XLSX workbook', which establishes the prerequisite that the file must already exist. However, there is no explicit when-to-use guidance and no routing against alternatives like r7_sheet_write (write into an existing sheet) or r7_create (make a new workbook), leaving the agent to infer.

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

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

With no annotations, the description carries the full burden, and it does disclose a key non-obvious trait: values, formulas and unrelated styles are preserved, and pageSetup can be applied in the same save. It omits whether filePath must already exist and how outputPath vs filePath overwrite semantics work, which are relevant for a mutation tool.

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

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

Three sentences, front-loaded with the core action, then preservation guarantees, then the pageSetup extension. Dense but efficient; the enumerated facet list is long though it directly maps to the tool's scope and 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 15-parameter mutation tool with nested objects, no annotations and no output schema, the description covers the operation's scope and its non-destructive behavior. Return-value explanation is unnecessary since no output schema exists; remaining gaps are minor preconditions (file existence, overwrite behavior).

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

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

Schema description coverage is 100%, so the schema already documents all 15 parameters in detail (including edge styles, paper sizes, fitToWidth/fitToHeight pairing). The description restates categories rather than adding format/syntax detail beyond the schema, so the 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 precise verb and resource (apply formatting to a cell or range in an XLSX worksheet) and enumerates the exact facets it covers: font, fill, borders, alignment, number format, merge, column width, row height. This makes it cleanly distinguishable from siblings like r7_sheet_write or r7_sheet_formula 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 through the enumerated facets and the note that print layout 'can be written in the same call with pageSetup', but there is no explicit when-to-use routing against alternatives (e.g. use r7_sheet_write for values). The agent must infer the boundary with sibling tools.

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

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

No annotations are provided, so the description carries the full behavioral burden. 'Insert or update' hints at mutation, but it omits whether existing cell content is overwritten, permission/auth requirements, and how the formula is recalculated or persisted.

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 zero filler, and no repetition of the name. It is efficient, though arguably underspecified rather than maximally concise.

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 mutation tool with no annotations and no output schema, the description is too thin. With 7 parameters and a nested numberFormat object, an agent still lacks behavioral context such as overwrite semantics, output behavior, and sheet selection precedence.

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%, including the example-laden cell/formula descriptions and the nested numberFormat object, so the schema does the heavy lifting. The description adds no parameter-level meaning beyond that, 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?

States a specific verb (insert/update) and resource (a formula in an XLSX cell), which is more precise than the sibling r7_sheet_write's value-writing role. However, it never names or contrasts with r7_sheet_write/r7_sheet_format, so sibling differentiation is only implied by the word 'formula'.

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

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

Provides no when-to-use guidance and no alternatives. An agent cannot tell from this text whether to reach for r7_sheet_formula versus r7_sheet_write when populating a cell.

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

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

No annotations are provided, so the description carries the full burden. It implies values, formulas and formatting are all returned, yet the schema shows formulas and styles are opt-in via includeFormulas/includeStyles flags — a potentially misleading impression — and it says nothing about failure modes for a missing file or sheet.

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 names the verb, the resource and the scope with no filler or redundancy. Nothing could be removed 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?

For a six-parameter read tool with no output schema and no annotations, the description sketches the return content but does not explain the optional flags that materially change the response, nor error behavior. It is minimally adequate but leaves gaps the structured fields do not fill.

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 every parameter including the range example and the sheetName/sheetIndex precedence is already documented in the schema. The description's range example (A1:D10) merely repeats the schema and adds no extra semantics, making the baseline 3 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 (Read) and resource (spreadsheet values, formulas, formatting) scoped to a worksheet or range, which clearly separates it from r7_sheet_write and the generic r7_read. It stops short of naming which sibling to use for related tasks, so it is clear but not sibling-differentiating.

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 or when-not-to-use guidance and no mention of alternatives such as r7_read or r7_inspect, even though the sibling list contains several read-oriented tools. The agent must infer that this is the spreadsheet-specific reader.

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

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

No annotations exist, so the description carries the full behavioral burden. It never discloses whether existing cell contents are overwritten, whether the target file/sheet must already exist, whether a new sheet is created, or what happens on partial failure — all critical for a mutation tool.

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

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

A single front-loaded sentence with zero filler, clearly leading with the verb and resource. It is efficient, though its terseness contributes to the missing behavioral context rather than being a structural flaw.

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 7-parameter mutation tool with no annotations and no output schema, the one-line description is too thin. It omits overwrite/reversibility semantics, the roles of cells vs matrix, and file-existence requirements that an agent needs to 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 100%, so the schema already documents all seven parameters, including the cells/matrix distinction and date/numberFormat handling. The description only echoes the index-or-name addressing mode already stated in the schema, adding no new parameter meaning.

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 (write) and resource (values, dates, formulas into an XLSX worksheet) with scoping detail (addressed by index or name). It does not, however, differentiate from nearby siblings such as r7_sheet_add, r7_sheet_formula, or r7_edit, which an agent must disambiguate.

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 guidance, no mention of alternatives (e.g. r7_sheet_formula for formula-focused work or r7_sheet_add for adding sheets), and no prerequisites. The agent must infer choice among several sheet-related siblings entirely on its own.

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

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

With no annotations the description carries the full burden, and it delivers the key traits: appending is non-destructive, layout/master/theme are reused rather than replaced, and baseSlideIndex clones a slide. It does not touch permissions, return format, or in-place vs copy behavior (left to the outputPath param).

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, zero waste, front-loaded with the primary purpose and followed by the behavioral and cloning details. Each 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 9-parameter mutation tool with no annotations and no output schema, the description adequately conveys the create/append distinction and non-destructive behavior. Minor gaps (authentication, response expectations) remain, 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 the baseline is 3 and the schema already documents every parameter. The description echoes the baseSlideIndex cloning semantics already stated in the schema, adding only marginal meaning beyond structured data.

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 (create) and resource (PPTX deck/slide), and covers the dual behavior of creating a new deck versus appending a slide to an existing one. It separates itself from siblings like r7_slide_edit and r7_slide_format by making clear appending never modifies existing slides.

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

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

Gives clear context: a missing file creates a new deck, an existing one gets a new slide, and baseSlideIndex switches to clone mode. It does not explicitly name an alternative sibling (e.g., r7_slide_edit) 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?

With no annotations, the description carries the full behavioral burden. It usefully discloses that reorder rewrites no slide part so slide content is unaffected, but it is silent on the destructive/irreversible nature of delete, whether duplicate deep-copies or shares parts, and in-place vs. outputPath write behavior beyond what the schema states.

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 waste; the action list is front-loaded and the safety note on reorder follows immediately. 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 an 8-parameter mutation tool with no annotations and no output schema, the description covers the operations and the index-based addressing model but omits critical behavioral context an agent needs: that delete permanently removes a slide and that outputPath can protect the source. 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 100%, so the schema already documents every parameter (order, toIndex, fromIndex, position, slideIndex). The description only adds the addressing model, 'Slides are addressed by their position in the deck,' which is helpful but minimal; baseline 3 applies when the schema does the heavy lifting.

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 ('Change the structure of a PPTX deck') and enumerates the four exact operations (duplicate, move, reorder, delete). This scope cleanly separates it from sibling tools like r7_slide_create, r7_slide_format, and r7_slide_object, which touch content or formatting rather than slide ordering.

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

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

The description implies when each action applies by naming them, but gives no explicit when-to-use vs. when-not-to-use guidance or routing to alternatives (e.g., use r7_slide_read first to find slide positions, or r7_slide_create instead of duplicate). The distinction between 'move' and 'reorder' is left to the reader.

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

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

With no annotations, the description carries the full burden and does meaningful work: it discloses that only named properties change and that gradients, shadows, hyperlinks and author styling are left untouched, and that it edits in place unless outputPath is given. It also discloses the silent fallback to the slide's first text object when no target is named, which is a real behavioral surprise. It does not cover permissions or what precedence applies among competing object selectors.

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 plus a fallback clause, front-loaded with the action and scope before the property inventory. No filler sentences, though the long property enumeration is close to restating the schema and could be trimmed.

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 47-parameter, output-less mutation tool with no annotations, the description covers the non-destructive partial-update contract, in-place vs copy semantics, and target fallback. The remaining gap is precedence among the several object-selection parameters (objectId, objectName, objectIndex, placeholderType), which is left for the agent to infer.

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 94%, so the schema already documents the 47 parameters thoroughly and the baseline is 3. The description adds only the aggregate property list and the fallback rule rather than per-parameter meaning, so it does not materially exceed what the schema provides.

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

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

States a specific verb and scope: 'Format or reposition one object on a PPTX slide, in place,' then enumerates the property families it touches (font, geometry, fill/border, alignment, lists, spacing, text replacement). The 'one object' scope plus the explicit fallback rule distinguish it from the broader slide/object siblings like r7_slide_edit and r7_slide_object.

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 context is implied rather than stated: it tells the agent an objectId 'exactly as r7_slide_read reported it' is the most precise way to address an object, which routes the agent through r7_slide_read first. However, there is no explicit when-to-use-this-vs-r7_slide_edit/r7_slide_object guidance and no when-not-to-use condition.

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

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

With no annotations, the description carries the full behavioral burden. It does add real value by claiming existing media/relationships are "never damaged" and that geometry, fill, border, text and font are applied in one call. But it omits that 'remove' is a permanent destructive action, whether edits are in-place versus copied, and what the call returns (the schema references ids "reported by r7_slide_read", implying output exists but that is never stated).

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 the core verb+resource and object types, then behavior, then the replaceImage special case. The parenthetical shape list is verbose but informative. No filler sentences.

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 51-parameter tool with 94% schema coverage and no output schema, the description supplies the essential framing: what can be created/removed, the single-call composition model, and the swap-picture mode. Since the schema covers parameters and no output schema must be explained, the remaining gap (the five action modes are only partially elaborated) is minor.

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 94%, so the schema already documents nearly every parameter, including units, enums and defaults. The description mostly restates schema content (the shape preset list is duplicated) and adds only the replaceImage/geometry-preservation nuance. Baseline 3 is appropriate when the schema does the heavy lifting.

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+resource ("Add or remove objects on a PPTX slide") and enumerates the object kinds (shapes, text boxes, images) plus the special replaceImage mode. It is clearly distinguishable from sibling r7_slide_read, though it does not explicitly contrast with r7_slide_edit or r7_slide_format, which could also parse as object-mutating.

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

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

It gives one concrete usage hint ("Set action \"replaceImage\" with an existing image object's id to swap its picture"), which points the agent at the right action. However, there is no guidance on when to use this tool versus r7_slide_edit, when to prefer addShape over addTextBox, or any exclusion criteria. Usage is implied rather than stated.

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

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

With no annotations, the description carries the full burden and does substantial work: it discloses that placeholder geometry and typography are resolved from layout/master so inherited values are reported instead of null, and that the deck's layouts are returned as a side effect. It omits read-only/safety framing and error behavior, but the inherited-value resolution is real behavioral context beyond the schema.

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

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

Two sentences, front-loaded with the core verb and normalized structure before the inherited-value clarification. The first sentence is a long enumeration but every listed field earns its place in setting output expectations; the layout-return note is a useful trailing addition.

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 exists, so the description usefully takes on the job of describing the return shape (per-object fields plus deck layouts). With 100% schema coverage on the four parameters and the inherited-value behavior explained, an agent has enough to call it correctly, though return pagination/large-deck handling is unaddressed.

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 four parameters are already documented in the schema. The description's mention of resolving layout/master placeholders loosely maps to includeInherited but adds no syntax, default, or format detail beyond what the schema provides; 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 gives a specific verb+resource ('Read a PPTX slide') and enumerates the normalized fields returned (id, type, geometry, text, font, fill, stroke, alignment, paragraphs), which goes well beyond the name. It does not explicitly distinguish itself from siblings like r7_read or r7_inspect, so the agent must infer the PPTX-slide-specific scope from the name plus content.

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/when-not-to-use statement or named alternative among the many siblings. The closing clause ('so the next slide can be built on a real one') implies a read-before-create workflow, but the agent must infer this rather than being told to prefer this over r7_read or r7_inspect.

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

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

No annotations are present, so the description carries the full burden. It does disclose one genuinely useful, non-obvious trait: cell formatting 'never rewrites the text or the properties of neighbouring cells.' But it is silent on the biggest behavioral question for a multi-action writer tool — whether edits mutate the source file in place or honour outputPath, and whether operations are destructive/irreversible.

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, tightly front-loaded with the capability list followed by the one caveat. No filler, though the long comma-separated operation list is dense for an 11-action tool.

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 20-parameter, 11-action tool with no annotations and no output schema, the description is only high-level. It does not indicate which parameters each action requires (e.g. cell for setCell/formatCell, rowIndex/columnIndex for removals, merge block for merge/unmerge) or what inspect/compute-style returns look like, leaving real gaps for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents all 20 parameters with aliases, units and enums; the baseline is 3. The description's mention of shading, borders, alignment and width loosely maps to the cell object but adds no syntax or format 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?

The description states a specific verb set and resource ('Create, inspect, or modify tables in DOCX documents') and then enumerates the sub-operations (rows, columns, merge, widths, cell formatting). An agent can tell this is the table-specific tool rather than a document-wide one, though it never names or contrasts the nearest sibling, r7_docx_formatting.

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 lists what can be done but gives no when-to-use guidance: no routing versus r7_docx_formatting or r7_edit, no prerequisites (e.g. an existing file and tableIndex are needed for modify actions), and no hint about which action suits which goal. The action enum is left to be inferred from the prose.

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

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

No annotations are provided, so the description carries the behavioral burden. It usefully discloses the scope of validation (structure, XML, formatting) and the word 'validate' implies a non-mutating operation, but it never states that nothing is modified, what happens when validation fails, or how results are surfaced.

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

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

A single front-loaded sentence with no filler; every clause names a distinct validation concern.

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 diagnostic tool with no output schema and no annotations, the description should say what a caller gets back (pass/fail, error list) and whether the file is touched. The scope of checks is covered, but the return/error behavior 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?

One parameter with 100% schema description coverage, so the schema already documents filePath adequately; the description adds no format, path-type, or file-type constraints. Baseline 3 is appropriate when the schema does the heavy lifting.

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 (validate) and resource (document package), and enumerates the three checks performed: structure, XML integrity, formatting health. This distinguishes it from mutation siblings like r7_edit or r7_create, though it does not explicitly contrast with the closest sibling, r7_inspect.

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

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

No guidance on when to choose this over r7_inspect or r7_read, no preconditions, and no mention of when validation should be run (before/after edits, pre-conversion, etc.). The agent must infer usage entirely.

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