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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and closed-world, so the safe/non-mutating profile is fully covered by structured data. The description's genuinely additive disclosure is that it performs no recalculation and that formulas only yield values if cached — a real behavioral limitation. Beyond that it says nothing about cost, large-sheet behavior, or truncation at maxRows.

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

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

Two sentences, zero padding; the verb and scope come first and the enumeration is dense but each item conveys an actual output. The caveat sentence is short 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?

With no output schema, the description does useful work by enumerating the produced statistics, so return content is reasonably covered. But for a 6-parameter tool with 17% schema coverage, the near-total silence on range, maxRows, hasHeader, and topValues leaves real gaps in how 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 description coverage is only 17% (just 'path'), and the description mentions none of range, maxRows, hasHeader, sheet, or topValues. 'Top categories' loosely maps to topValues, but maxRows, hasHeader, and the A1-style range pattern are left entirely undocumented in both schema and prose.

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 ('Profile') plus resource ('XLSX dataset') and enumerates the exact statistics produced (column types, missing values, numeric summaries, duplicates, IQR outliers, top categories, Pearson correlations), which clearly separates it in substance from excel_query_dataset or excel_inspect_workbook. It never names a sibling or makes an explicit comparative claim, so differentiation is inferential rather than stated.

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

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

The clause 'Descriptive analysis only; formulas need cached results or native recalculation' gives one real applicability constraint that implies excel_native_batch is the fallback for computed values. However, there is no explicit when-to-use statement and no named alternative, so the agent must infer routing.

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 carry the safety profile (destructiveHint=true, idempotentHint=false, openWorldHint=false), so the bar is lower, but the description adds nothing beyond them. It never says what is destroyed (an existing file at the target path when overwrite is set), what happens when overwrite is left at its default false, or whether the call is idempotent, all of which matter for a write tool that can overwrite 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?

A single front-loaded sentence with no wasted words. It is efficient, but the terseness is also the source of the definition's gaps rather than a deliberate trimming of redundant detail.

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

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

There is no output schema, so the description must carry the return-value burden, and it does not. For a destructive write tool with four parameters at 25% schema coverage and rich nested sheet options, the definition leaves an agent without enough to call it confidently.

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

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

Schema description coverage is only 25% – just the path parameter is documented. The description's phrase 'one or more worksheets and tabular data' barely gestures at the sheets array and says nothing about creator, overwrite, or the per-sheet options (headerRow, autoFilter, freezeRows, columnWidths) that are entirely undocumented in both places. It does not compensate for the coverage gap.

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 ('Create a new XLSX workbook') plus the scope ('one or more worksheets and tabular data'), so an agent knows exactly what the tool produces. It does not differentiate itself from nearby siblings that also create files (word_create_document, powerpoint_create_presentation) or from excel_write_range, which also writes spreadsheet data.

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 indication of when to use this versus excel_write_range, excel_native_batch, or the other create_* siblings. Critically, there is no guidance on the overwrite flag and whether an existing file at the path is replaced or the call fails, which is the main decision an agent faces here.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds value by naming what the inspection surfaces (formulas, dimensions, sample rows), which is a behavioral/return-content claim, but it does not describe size limits, performance, or how much data is returned.

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

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

A single dense sentence with no filler, and the key content categories are front-loaded after the verb. It loses a point only because the compact list form leaves out routing and parameter cues that would have been worth the space.

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

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

With no output schema, the description must carry the return-value burden, and it does enumerate the inspection coverage (metadata, worksheets, dimensions, formulas, sample rows). The remaining gap is that return format and the effect of sampleRows on output are not described, which leaves the agent guessing at the response shape.

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

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

Schema coverage is 50%: the required 'path' parameter is documented in the schema, while 'sampleRows' has only default/min/max bounds and no prose. The description's mention of 'sample rows' gives that parameter meaning by implication, which is modest compensation, but the max of 100 and behavior at 0 are left unexplained.

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

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

States a specific verb (inspect) and resource (workbook) and enumerates the aspects inspected: metadata, worksheets, dimensions, formulas, sample rows. This distinguishes it well from sibling inspect tools for other formats, though it does not explicitly contrast with overlapping excel siblings such as excel_read_range or excel_analyze_dataset.

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

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

No when-to-use guidance at all. Given siblings like excel_read_range, excel_analyze_dataset, and excel_query_dataset, an agent has no stated rule for choosing inspection over reading or analyzing data, nor any prerequisite or sequencing hint.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false, so the safety profile is covered. The description adds that execution is 'ordered' (order-dependent, consistent with non-idempotent) and that it drives 'real Microsoft Excel' over active or closed workbooks, which hints at a native-app dependency. It still omits what gets destroyed, session/permission requirements, and whether saving is implicit.

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?

Purpose is front-loaded in the first clause, followed by a dense but scannable capability list. It is a run-on sentence with a long enumeration, but every listed item corresponds to real supported behavior, 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?

For a tool exposing 40+ discriminated union operations with a nested target object and no output schema, the description gives a good capability map but no guidance on batch failure semantics, ordering constraints between ops, or how target/overwrite behave. Annotations cover the destructive profile, but a batch executor of this complexity needs more.

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 three top-level parameters (target, overwrite, operations) have no descriptions in the schema (coverage reported 0%), and the description never explains them or their interplay. It partially compensates for the operations array by enumerating capability areas (tables, charts, pivots, Goal Seek, filtering, validation, protection, print setup, PDF export) that map onto the op enum values, but 'overwrite' and the target/workbook selection remain unexplained.

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

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

States a specific verb and scope ('Execute an ordered batch through real Microsoft Excel') and the 'batch' framing distinguishes it in spirit from the single-op excel_* siblings. However, it never names an alternative like excel_write_range or excel_set_formulas, so the agent must infer the boundary between batch and single-op tools.

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

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

Context is only implied: 'ordered batch' plus 'active or closed workbooks' signals multi-step, native-app scenarios, but there is no explicit when-to-use, when-not-to-use, or named alternative among the many excel_* siblings. Adequate but leaves routing to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds only "bounded output" as new behavioral context, without explaining what the bounds are (limit default 100 vs maxRows default 10000), what gets truncated, or whether exceeding a bound errors or silently trims.

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

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

Two sentences, zero filler, capabilities front-loaded before the usage clause. Nothing redundant with the title or 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?

For a 10-parameter analytical tool with no output schema and near-zero schema coverage, the description is too thin. It does not explain the interaction of range/sheet, the two separate row-bound parameters, or the shape of aggregated versus row-level results, all of which an agent needs to call this 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 only 10% (essentially just 'path'), so the description must carry the burden for 10 parameters. It gestures at filters, groupBy, metrics, sort and bounded output, but adds no operator semantics, no distinction between limit and maxRows, and nothing about range, hasHeader, or the metric aliasing field.

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 (query) and resource (Excel dataset) and enumerates the capability set: typed filters, group-by, aggregations, sorting, bounded output. It is clear what the tool does, but it never distinguishes itself from close siblings such as excel_analyze_dataset or excel_read_range, which an agent could easily confuse it with.

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?

"Use for focused analytical questions without changing the workbook" gives implied usage context, but no explicit when-to-use/when-not or named alternatives. With excel_analyze_dataset and excel_read_range in the sibling list, the routing guidance is left to inference.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds only the useful nuance that raw formulas and optionally styles are returned, but says nothing about pagination, large-range limits, or error behavior on missing sheets/ranges.

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

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

A single tight sentence with the verb and resource front-loaded and no 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?

With no output schema, the description must convey return contents, and it does list values, text, formulas, and optional styles. Combined with annotations that fully describe the safety profile, this is largely sufficient, though it omits any note on range size or missing-sheet failure 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 25%: only 'path' is documented, while 'sheet', 'range', and 'includeStyles' carry no descriptions. The description's mention of 'optional styles' loosely maps to includeStyles (default false) and 'range' implies an A1-style reference, but it does not explain sheet naming or range syntax beyond what the pattern already enforces.

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 (XLSX range) and enumerates what is retrieved: cell values, text, formulas, and optional styles. This is clearly distinguishable from write-side siblings like excel_write_range and excel_set_formulas, 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?

There is no when-to-use guidance or routing to alternatives, despite rich siblings such as excel_query_dataset, excel_inspect_workbook, and excel_analyze_dataset that an agent must choose between. The agent is left to infer that this is the low-level raw-cell read.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds genuine value with the recalculation note ('request recalculation when opened in Excel'), clarifying that results are not computed server-side, but it omits the in-place mutation risk and overwrite 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?

A single tight sentence with no filler, and the core action is front-loaded. It is efficient, though the recalculation caveat slightly obscures rather than sharpens the main statement.

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

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

For a destructive 5-parameter mutation tool with no output schema and 40% schema coverage, the description is thin. It says nothing about whether existing formulas are replaced, how the optional cached 'result' interacts with recalculation, or what happens when outputPath is supplied.

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

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

Schema description coverage is only 40% and the description names no parameters at all. It never explains 'overwrite' (defaults to false), 'outputPath' (in-place vs. copy), or the optional 'result' field per formula, leaving the caller to guess at write semantics that directly affect data safety.

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 and resource ('Set formulas in specific XLSX cells'), which is more precise than the generic write tools in the sibling set. It does not, however, explicitly contrast itself with excel_write_range or excel_native_batch, so the differentiation is implied rather than stated.

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

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

There is no guidance on when to choose this tool over excel_write_range (which writes values) or excel_native_batch. No prerequisites, no exclusions, no alternative named — the agent must infer the boundary from the tool name alone.

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

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the write and destructive profile is carried by structured data. The description adds only that the worksheet must already exist; it says nothing about what overwrite=false does to occupied cells, how styling flags (bold, fillColor, numberFormat) alter the sheet, or that omitting outputPath mutates the source file in place.

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 tight, front-loaded sentence with no filler or repetition. It is well structured but under-specified rather than padded, which is a completeness problem rather than a verbosity one.

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 destructive write tool with 22% schema coverage and no output schema, a single sentence covering none of the optional styling, overwrite, or output-path parameters is far too thin. An agent cannot determine in-place vs. new-file behavior or collision semantics from this definition.

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

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

Schema description coverage is only 22% across 9 parameters, so the description must compensate and largely does not. 'Rectangular matrix of values' loosely clarifies the shape of the values array, but overwrite, bold, fillColor, numberFormat, startCell and outputPath get no explanation beyond the bare 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 gives a specific verb ('Write'), a specific resource ('XLSX worksheet'), and constrains the payload ('rectangular matrix of values'). It does not, however, distinguish itself from close siblings such as excel_set_formulas or excel_native_batch, so an agent must infer the boundary from the name alone.

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 single phrase 'existing XLSX worksheet' implies the target file must already exist, but there is no explicit when-to-use guidance, no pointer to excel_create_workbook for new files, and no mention of when excel_set_formulas or excel_native_batch would be preferred.

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, idempotentHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered elsewhere. The description adds only the envelope of returned content categories (operations, path roots, converters, limitations), which is useful but thin; it says nothing about result size, caching, or whether the capability list is environment-dependent.

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, and the four returned categories are front-loaded. Every word earns its place and it fits the scope of a no-argument introspection 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?

There is no output schema, so the description must carry the return-value burden, and it does list the four content categories an agent will receive. What is missing is any indication of the shape or granularity of the result (e.g., whether limitations are per-format or global), but for a simple listing tool this is close to sufficient.

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

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

The tool takes zero parameters with an empty object schema, so there is nothing for the description to disambiguate. The baseline for parameterless tools applies, and the description correctly avoids inventing or implying any arguments.

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 ('List') and enumerates the exact resource categories returned: supported Office operations, path roots, converters, and known limitations. That is far more informative than a tautology like 'Show capabilities'. It does not explicitly contrast itself with the similarly meta-sounding sibling office_native_status, so it falls short of a 5.

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

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

Usage is only implied: an agent can infer this is the discovery tool to call before/instead of guessing which office_* operation exists. There is no explicit statement of when to call it (e.g., first, before unknown operations) or when not to (e.g., when the operation is already known), and no named alternative such as office_native_status.

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 readOnly, idempotent, non-destructive and non-open-world, so the safety profile is covered. The description still adds real context by naming what the report contains (removed paragraphs, slide content changes, sheet/cell changes) and confirming neither file is modified. It omits behavior around result truncation/limits, which keeps it from a 5.

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

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

Two sentences, zero filler, with the core action and scope front-loaded and the non-mutation guarantee placed at the end as a supporting clause. Every phrase 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 read-only comparison tool with no output schema, the description gives a reasonable sketch of the report contents, but it never explains the maxChanges cap or what happens when changes exceed it — the single most important behavioral detail an agent needs when interpreting results.

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

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

Schema coverage is 67%: beforePath and afterPath are documented in the schema, but maxChanges has no schema description and the tool description never mentions it at all, despite a default of 100 and a 1-1000 range that materially bounds the output. The description adds no parameter meaning beyond the schema.

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

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

States a specific verb (compare) and resource (two Office files of the same format) with the semantic scope and the reported artifact types (Word paragraphs, PowerPoint slides, Excel cells). An agent can distinguish this from office_inspect_file or office_quality_check 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 before/after framing implies the revision-comparison use case, and 'of the same format' implies a constraint, but there is no explicit when-to-use guidance, no statement of when the tool is not appropriate, and no named alternative among the many sibling inspect/audit 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is partly covered. The description adds the LibreOffice dependency, which is genuine behavioral context, but omits what happens when LibreOffice is unavailable, how 'overwrite' interacts with existing files, and where output lands by default.

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

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

A single tight sentence with the operation front-loaded and no filler. It is efficient, though the brevity arguably costs it needed detail rather than serving conciseness.

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

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

With no output schema and a destructive mutation, the description should cover overwrite semantics and failure behavior, which it does not. The 'when available' clause is a partial acknowledgment of a fallback path but leaves the agent without enough to act correctly in edge cases.

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 67%, and the undocumented parameter is 'overwrite' — the one most tied to the destructiveHint. The description mentions no parameter at all, so it fails to compensate for the coverage gap on a mutation-relevant flag.

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) with explicit source formats (XLSX, DOCX, PPTX) and target (PDF), which is clearly actionable. However, it never distinguishes itself from the sibling office_export_pdf, which an agent could easily confuse with this 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 guidance on when to use this versus office_export_pdf or office_convert alternatives, nor any stated prerequisites. The only hint ('when available') gestures at a condition but does not tell the agent how to react to its absence.

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 the mutation/destruction profile (destructiveHint=true, idempotentHint=false), so the description earns credit for adding non-structured context: output is a separate file, no visible window, hidden Office on Windows, and a LibreOffice fallback. It still does not explain overwrite semantics, which is the operation's main destructive 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 tight sentences, front-loaded with the conversion and engine mechanism, followed by the non-obvious side effects (separate file, no visible window). 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?

Annotations cover the safety profile and no output schema is needed, but the definition omits overwrite/outputPath semantics and any disambiguation from office_convert_to_pdf. Adequate but with clear, actionable gaps for a 4-param converting tool.

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

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

Schema coverage is 50%: path and outputPath are documented in-schema, but engine and overwrite are not. The description's mention of a 'LibreOffice fallback' implies the engine choice, but the destructive overwrite parameter is left entirely undocumented in both places, so it only partially compensates.

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 (export) and resource (XLSX/DOCX/PPTX to PDF) with the added qualifier 'reviewable'. However, it never distinguishes itself from the sibling office_convert_to_pdf, which appears to overlap directly, so an agent cannot route between the two from this text alone.

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 hints at engine context ('hidden native Microsoft Office on Windows, with optional LibreOffice fallback'), which implies when each engine applies, but it never states when to use this tool versus office_convert_to_pdf or any prerequisite/exclusion. Usage is only implied.

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

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

Annotations already disclose destructive=true, non-idempotent, non-openWorld. The description adds genuinely useful behavior beyond them: the no-overwrite guarantee on outputPath and the required validation gate (hash unchanged, full review). It does not say what happens on validation failure or whether publishing is reversible, but the added context is substantive.

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

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

Two sentences, front-loaded with the action, no filler. The first sentence is dense but every clause earns its place as a precondition.

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

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

For a 4-required-parameter, nested-object finalize tool with no output schema, the description conveys the workflow gate but omits parameter guidance, failure behavior, and result semantics. Adequate but with clear gaps given the tool's complexity.

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

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

With 50% schema coverage and deeply nested contract/review objects, the description only loosely gestures at parameters (hash, review, criteria) and does not explain the path vs outputPath distinction or the contract structure. Baseline 3 is appropriate; it neither compensates for nor ignores the coverage gap.

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 (Publish) and resource (a separate XLSX/DOCX/PPTX output), plus the precondition that makes it distinct from inspection/quality-check siblings. It does not explicitly name the sibling it follows (office_prepare_review, office_quality_check), so it stops short of full 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?

Gives a strong precondition: run only after recomputing machine checks and verifying a complete review of every unit and criterion against the unchanged hash. However, it never names the prerequisite tools or states when NOT to use it, leaving the workflow order to inference.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds two things annotations don't: the return channel ('MCP image content') and a validation behavior ('Rejects stale or changed evidence'), which tells the agent calls can fail on outdated input.

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

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

Two tight sentences with no filler; the core action is front-loaded and each clause (preview coverage, stale rejection) 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?

No output schema exists, but the description states the return is MCP image content and discloses the stale-evidence rejection, which covers the main unknowns for a 2-param read tool. It relies on the reader inferring the prior render/manifest workflow, which keeps it just short of fully self-contained.

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

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

Schema description coverage is 50% - manifestPath is documented in-schema while unit only has a pattern. The description's 'one ... slide' weakly maps to the unit selector and 'evidence' loosely evokes the manifest, but it adds no syntax, format, or identifier semantics beyond the schema. Baseline 3 fits this partial coverage.

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

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

States a specific verb (Return) and resource (one previously rendered PowerPoint slide as MCP image content), plus the scoping nuance that it covers slides omitted from the initial inline preview. It is distinguishable from render/inspect siblings but does not name 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 'slides omitted from the initial inline preview' implies when this tool is needed, and 'Rejects stale or changed evidence' hints at a precondition. But it never names an alternative (e.g. powerpoint_render_presentation) or states explicit when-not conditions, so usage is implied rather than 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds that it returns a 'semantic summary' for three format types, but says nothing about inspection depth, cost, or how sampleLimit affects 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?

A single, front-loaded sentence with zero wasted words. It is efficient, though its brevity edges toward under-specification rather than optimal conciseness.

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

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

With no output schema, the description carries the burden of explaining what a 'semantic summary' contains, which it does not. Combined with the undocumented sampleLimit parameter, an agent lacks the detail needed to call this tool with confidence.

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

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

Schema description coverage is 50%: 'path' is documented in the schema but 'sampleLimit' (default 20, max 500) is undocumented in both the schema and the description. Its meaning and effect on the returned summary are unclear, and the description does not compensate for this gap.

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), the resource (XLSX, DOCX, PPTX file), and the return (semantic summary). However, it does not differentiate itself from the format-specific siblings excel_inspect_workbook, word_inspect_document, and powerpoint_inspect_presentation, so an agent cannot tell from the description alone why it would choose the generic tool over a format-scoped one.

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 and no mention of alternatives. Given several sibling tools that also inspect documents, the description should say when this cross-format inspector is preferable, but it offers nothing.

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, idempotentHint=true, and destructiveHint=false. The description adds genuinely useful behavioral scope beyond them: it only sees documents inside currently running native applications, which prevents an agent from mistaking it for a filesystem scan. It stops short of describing behavior when no apps are running.

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 action and resource, and free of filler. Every word earns its place.

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

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

With no output schema present, the description should ideally state the return shape (file paths, names, application types) and what happens when nothing is open. For a zero-parameter tool that is the main remaining gap, but the core selection information is present.

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 to disambiguate and the baseline of 4 applies. The description correctly reflects a no-argument operation.

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 ("List") and a precisely scoped resource ("files currently open in running native Excel, Word, and PowerPoint applications"). It implicitly separates itself from office_search_files and office_inspect_file, though it never names a sibling to make the distinction explicit.

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

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

Usage is implied rather than stated: an agent can infer this is for discovering live open documents rather than files on disk. However, there is no explicit when-to-use, no exclusions (e.g. when to prefer office_native_status instead), and no prerequisites.

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

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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior. The description usefully adds that detection covers both installation state and running state, and constrains the platform to Windows — 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?

A single front-loaded sentence with no filler; every word carries scope (installed vs running, the three apps, Windows).

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

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

With no output schema, the description should ideally hint at the return shape (e.g., per-app installed/running flags) and interpretation. It covers what is detected but leaves the response format and how to act on it 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate. Baseline 4 applies per the no-params rule.

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 ('Detect') and a precisely scoped resource: installed and currently running native Excel, Word, and PowerPoint apps on Windows. This distinguishes it from batch-manipulation siblings by its diagnostic nature, though it does not explicitly name a contrasting sibling.

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 call this versus alternatives such as office_capabilities or office_list_open_files, and no stated preconditions (e.g., 'call before native batch operations'). 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.

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

Annotations already declare this is a non-read-only, destructive, non-idempotent write, so the safety profile is covered. The description adds genuinely non-obvious behavior (PowerPoint renders use hidden windows) and names the outputs (hash + manifest). It does not disclose what is destroyed or overwritten in outputDirectory, which matters given destructiveHint=true.

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

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

Three tight sentences, front-loaded with the core action and followed by the render caveat and the verification instruction. No filler, though the sentence on hidden windows is slightly parenthetical to the main point.

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 it correctly enumerates the returns (PNGs/PDF, source hash, artifact manifest), which is useful. But for a 4-parameter tool with a deep contract object it leaves the contract semantics unexplained and omits how the produced evidence is later retrieved (presumably office_get_review_image) or how contract failures manifest.

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

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

Schema description coverage is only 50% and the large nested contract object (objective, criteria, powerpoint, word, excel, baseline, requiredText/forbiddenText) is entirely undocumented by either schema or description. The description never explains what contract or maxInlineImages control, so it fails to compensate for the coverage gap.

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 artifact: creating hashed review evidence (slide PNGs or a PDF, source hash, artifact manifest) for a quality-checked draft. That is far more concrete than the name alone and distinguishes it from office_quality_check and office_finalize. It stops short of naming the sibling it pairs with for retrieving the evidence.

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 usage instruction — inspect every slide or the complete PDF before attesting quality — which implies a verify-then-attest workflow. It does not say when to choose this over office_quality_check, office_finalize, or office_compare_files, nor any prerequisites (e.g., is the draft required to have passed quality_check first?).

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, non-destructive), so the bar is lower. The description adds real context beyond them: it enumerates the return payload (file hash, blocking issues, warnings, review units) and warns that machine checks alone do not certify quality, which is a meaningful behavioral caveat about the tool's limits.

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

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

Three sentences, front-loaded with the verb, and each carries distinct information: what it validates, what it returns, and its limitation. No filler or restatement of the title/name.

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

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

With no output schema, the description usefully enumerates the return values and the tool's caveat. Given the highly complex nested contract parameter, it stops short of fully documenting how to construct the contract, but for an agent's core calling decision it is largely complete.

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

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

Schema coverage is 50% and the 'contract' parameter is a deeply nested object with no top-level schema description. The description loosely maps its phrasing ('prompt-specific requirements', 'Office package integrity') onto the contract's objective/criteria/baseline structure, but does not explain the contract's sub-fields, tolerance, or forbiddenText/requiredText, so it only partially compensates for the coverage gap.

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 ('an XLSX, DOCX, or PPTX draft') with the scope of validation (prompt-specific requirements plus Office package integrity). This is clearly distinct from generic inspectors like office_inspect_file, though it does not explicitly name or contrast against office_prepare_review or office_compare_files.

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 line 'Machine checks alone never certify quality' and the promise of 'units requiring visual or analytical review' imply this is a machine pre-check feeding a human/visual review step, but no alternative tool is named and no explicit when-to-use/when-not guidance is given. Usage is inferable rather than stated.

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

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds the useful constraint that the search is confined to an 'allowed directory', but says nothing about recursion default, result caps, or truncation 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?

One sentence, front-loaded with the verb and resource, with no wasted words. It is efficient, though it spends its single clause on orchestrator motivation rather than on the undocumented parameters.

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

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

For a read-only search tool with four parameters and no output schema, the definition is only partially complete: it omits what a result entry looks like, whether paths are returned, and how recursion and maxResults interact. Adequate but with clear gaps given the low schema coverage.

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% - just the directory parameter is documented. The description does map the file types to the extensions parameter, but recursive (default true) and maxResults (default 500, max 5000) are undocumented in both schema and description, leaving meaningful behavior to guesswork.

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 ('Find'), the exact resource types (XLSX, DOCX, PPTX), and the scope ('inside an allowed directory'), so the agent knows precisely what operation it is. It is reasonably distinct from siblings like office_list_open_files, though it does not explicitly contrast with 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?

The clause 'so an orchestrator can discover relevant Office documents' implies a discovery use case, but there is no explicit when-to-use, when-not-to-use, or reference to any alternative such as office_list_open_files or office_inspect_file. The agent is left to infer selection criteria.

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 readOnly/idempotent/non-destructive, so the safety profile is covered. The description adds real value beyond that by disclosing that results are heuristic and may miss issues that require visual inspection — an honesty caveat that shapes how an agent should trust the output.

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, no filler. The scope enumeration is front-loaded and the heuristic caveat is placed where it matters, after the capability statement.

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 reasonably stands in by naming the flag categories an agent can expect. For a 3-parameter read-only audit, the main remaining gap is the meaning of the two numeric threshold parameters.

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

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

Schema coverage is only 33% — minimumFontPoints and denseSlideCharacters have bounds and defaults but no prose descriptions. The description's 'small explicit text' and 'dense slides' phrases loosely map to those two parameters, giving partial semantic anchoring, but units and how thresholds are applied remain undocumented.

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 ('audit') + resource ('PPTX') with an enumerated detection scope: off-slide objects, small explicit text, dense slides, missing alt text. It is clearly distinguishable in spirit from powerpoint_inspect_presentation, though it never names a sibling to sharpen 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?

It implies the use case (pre-review of a deck) and gives one caution ('render and visually inspect the deck as well'), which points at a complementary tool without naming powerpoint_render_presentation. No explicit when-not conditions or prerequisite/auth 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, and non-idempotent, so the safety profile is partly covered. The description usefully adds format traits (widescreen, typography, imagery) and a post-create verification workflow, but it never discloses the destructive/overwrite behavior implied by destructiveHint=true and the 'overwrite' parameter defaulting to 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?

Two front-loaded sentences with no filler, and the use-case preference plus verification step are compactly stated. The first sentence leans on undefined adjectives ('editorial compositions,' 'readable typography') that spend words without adding precise 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 complex creation tool with 5 parameters, a nested oneOf slide union, no output schema, and a destructive overwrite flag, two sentences are insufficient. An agent cannot learn the layout vocabulary, style effects, or overwrite semantics from the description, and no structured field fills those gaps.

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

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

Schema coverage is only 20%, so the description must compensate and does not. It gestures at style ('editorial compositions') but never explains the editorial/cinematic enum, the five slide layout variants (cover, imageText, statement, comparison, panorama), the overwrite flag, or path semantics, leaving most parameters undocumented in both places.

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 ('Create a widescreen narrative deck') with concrete attributes (editorial compositions, readable typography, optional cropped imagery). It hints at differentiation from other create tools via 'Prefer this for new story decks,' but never names the sibling it is preferred over (e.g. powerpoint_create_presentation or powerpoint_create_from_template), so the boundary is inferred rather than stated.

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

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

Gives clear use context ('new story decks') and a workflow directive ('render and critique the result before delivery'). It does not name an alternative tool for non-story decks or state when-not-to-use, so routing requires inference, but the usage signal is stronger than a bare 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?

Annotations already declare this as a non-read-only, destructive, non-idempotent write. The description adds non-obvious behavior beyond that: native PowerPoint execution with hidden presentation windows and that the source template is left unchanged. It omits overwrite behavior on outputPath and any failure-mode or idempotency context.

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 purpose front-loaded and no filler. Each clause contributes either scoping information or behavioral context.

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 creation tool with a complex oneOf slides schema, no output schema, and only 40% parameter description coverage, the description covers core mechanics and template safety. It still omits sibling-routing guidance and the overwrite/keepTemplateSlides behavior an agent needs before invoking it.

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 40%, so the description needs to compensate more than it does. It conceptually maps to the two slide source modes and to filling placeholders or named text shapes, but never mentions templatePath, outputPath, overwrite, or keepTemplateSlides, leaving those semantics to the schema alone.

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

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

States a specific verb (Create), resource (PPTX), and source modes (existing deck's masters/layouts or duplicated slides) plus the filling operations. It implicitly distinguishes itself from from-scratch creation tools, but does not name an alternative or explicitly say when to prefer it over siblings like powerpoint_create_presentation or powerpoint_create_designed_presentation.

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 the applicable scenario: template-based creation by filling placeholders or named text shapes. However, it gives no when-not guidance, no prerequisites, and no explicit routing among the several sibling presentation-creation 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?

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — it never mentions the destructive overwrite behavior, that an existing file at 'path' may be replaced, or that creation is non-idempotent.

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; the resource type and capability list arrive immediately. It is efficient, though the element enumeration is somewhat schema-redundant rather than informative.

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, deeply nested, non-idempotent, destructive-write tool with no output schema and near-zero schema coverage, one sentence is far too thin. Nothing explains coordinates units, slide sizing, theme application, or the overwrite flag's consequences.

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

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

Schema description coverage is only 11% across 9 parameters, so the description is expected to compensate, but it only lists element categories that are already visible in the schema's oneOf branches. Key parameters (theme, layout, overwrite, title/author/company/subject metadata) receive no explanation in either place.

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 presentation) and enumerates the supported element types, which lets an agent match it to visual-content generation. It does not, however, differentiate itself from close siblings like powerpoint_create_designed_presentation or powerpoint_create_from_template.

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 the template- or design-based creation siblings, nor any stated prerequisites (e.g. target directory existence, overwrite behavior). The agent must infer selection entirely from the name.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the inventory of what gets inspected, which is genuinely useful, but says nothing about how maxSlides truncates results or how failures (missing/corrupt file, unlocked PPTX) surface.

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 and then lists the inspected facets with zero filler. It is efficient, though the fragmentary list style leaves room for one clause of clarifying context at no real cost.

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

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

There is no output schema, so the description reasonably enumerates the returned facets (size, text, notes, object counts). However, it omits the maxSlides truncation behavior, which materially affects results for large decks and is the one piece of information an inspecting agent most needs.

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

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

Schema description coverage is only 50%: path is documented in the schema, but maxSlides (default 200, max 1000) carries no description anywhere. The description does not mention the slide limit or what happens when a deck exceeds it, so it fails to compensate for the uncovered 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 pairs a specific verb ("Inspect") with a specific resource ("PPTX") and enumerates what is examined: slide size, text, notes, and object counts. This clearly distinguishes it from write-oriented siblings like powerpoint_replace_text or powerpoint_native_batch, though it never contrasts itself with the close neighbor powerpoint_audit_presentation.

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 statement of when to use this tool versus alternatives, no prerequisites, and no exclusion of cases. With sibling tools such as powerpoint_audit_presentation and powerpoint_inspect_template present, the agent is left to infer the boundary entirely.

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?

Goes well beyond the annotations (readOnly, idempotent, non-destructive) by disclosing that inspection runs through a hidden desktop PowerPoint instance, requires Windows PowerPoint, and refuses to run when a user PowerPoint session is active. The only gap is that 'by default' hints at an override without explaining how to enable 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?

Two tightly written sentences: the first states the action and returns, the second states the environment requirements. Zero filler and the most important content is front-loaded.

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

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

With no output schema, the description does carry the burden of describing results and does name the three returned collections, plus platform and session constraints. It stops short of describing the shape of the returned indexes or failure modes, leaving a small 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?

Only one parameter, and the schema already documents it at 100% coverage (absolute path or path relative to the server working directory). The description adds no extra syntax, path constraints, or file-type requirements, 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 (an existing PPTX template) and enumerates the concrete outputs: designs, custom layouts and placeholder indexes. The template-generation framing implicitly separates it from the sibling powerpoint_inspect_presentation, which is not template-oriented.

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 'for template-based generation' implies the workflow context (inspect before calling powerpoint_create_from_template), but no alternative is named and there is no explicit when-not-to-use guidance, e.g. versus powerpoint_inspect_presentation or powerpoint_audit_presentation.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is carried elsewhere. The description adds concrete behavioral context the annotations do not: it drives 'real Microsoft PowerPoint', works on active or closed presentations, and uses points as native coordinates. It does not discuss persistence (is a save op required?), failure/rollback, or rate/complexity limits for a destructive batch.

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?

Front-loaded with the core verb and resource, and the remaining content is compact. The long capabilities enumeration is dense but arguably earns its place by signaling the batch's breadth; it could be trimmed but is not padded with 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?

With no output schema and a destructive, non-idempotent batch, the description should clarify persistence requirements, ordering semantics, and failure behavior. It states 'ordered batch' but says nothing about how partial failures are handled or whether a 'save' op is mandatory, leaving real gaps for a 40-op tool.

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

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

Schema description coverage is reported at 0% for a 3-parameter, deeply nested tool, so the description must compensate and partially does: '!!' prefix for Morph matching, list_shapes as the source of shape references, and 'native coordinates are points' clarify units the schema leaves implicit. However, the vast majority of operation fields (animation timing, export quality, transitions, etc.) receive no explanation, leaving the burden on the schema alone.

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

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

The opening sentence names a specific verb (execute) and resource (ordered batch through real Microsoft PowerPoint), and the 'batch' framing distinguishes it from the single-purpose powerpoint_create_* / powerpoint_replace_text siblings. The feature enumeration that follows broadens scope but doesn't dilute the core identity. It stops short of explicitly naming which sibling covers a given task.

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?

One concrete instruction ('Use list_shapes before targeting shapes') is genuinely useful, but there is no when-to-use/when-not guidance relative to overlapping siblings like powerpoint_render_presentation, powerpoint_replace_text, or powerpoint_inspect_presentation, all of which are subsumed by operations here. The agent must infer when the batch tool beats the dedicated 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotent, so safety is covered. The description adds one genuinely useful trait the annotations cannot convey: rendering goes through 'real Microsoft PowerPoint,' implying an installed-Office dependency and faithful native rendering. It does not explain what gets written/overwritten on disk despite destructiveHint=true, so credit is partial.

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: verb, engine, output format, and intended workflow. Every clause earns its place.

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

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

The output form is stated and there is no output schema to compensate for, but the 33% schema coverage and the silent maxSlides=10 default (which silently truncates renderings) mean an agent could call this and misread the result. The write/overwrite behavior also goes 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 coverage is only 33% — width, height, maxSlides, and overwrite have no description text. The description mentions none of them, leaving the default maxSlides=10 cap and the overwrite flag completely unexplained by either source.

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 (Render), a specific resource (PPTX with real Microsoft PowerPoint), and the distinct output artifact (slide PNGs as MCP images). The phrase 'real Microsoft PowerPoint' differentiates it from a structural sibling like powerpoint_inspect_presentation, so an agent can route correctly without opening a schema.

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

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

'for visual inspection and iterative correction' gives a clear scenario context for when to reach for this tool. There is no explicit when-not or named alternative (e.g., use inspect for structural checks instead), 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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description usefully adds that matching spans multiple runs, but omits any warning that the default behavior is an in-place overwrite that can destroy the original file with no backup.

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, and the run-splitting caveat is the most valuable detail placed early. It is efficient, though arguably too terse given the 6-parameter 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?

For a destructive 6-parameter mutation with no output schema and 33% schema coverage, the description is far too thin. It should explain in-place vs outputPath behavior, the meaning of overwrite, and whether a backup/existing file is affected.

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

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

Schema description coverage is only 33% (just path and outputPath), leaving find, replacement, matchCase, and overwrite undocumented anywhere. The description adds nothing about case sensitivity, the default matchCase=true, or the destructive default of overwrite=false writing over the input file.

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 (Replace) and resource (literal text in PPTX slides), and adds a meaningful scope note about text split across runs. It does not, however, differentiate itself from siblings like word_replace_text or powerpoint_native_batch, which handle overlapping editing needs.

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 whether to prefer this over powerpoint_native_batch, word_replace_text, or the batch tools, and no preconditions (file must be open? template loaded?) are given. The agent must infer everything from the name.

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

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

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is covered. The description adds one useful behavior note — the DOCX package is preserved — but omits the more consequential detail that in-place modification happens by default unless outputPath is supplied, which matters given destructiveHint=true.

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 or redundancy. It is efficiently structured, though the brevity borders on under-specification rather than optimal density.

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 mutating tool with no output schema and 40% schema coverage, the description is too thin. It should clarify what append means (new paragraph at end), how style and overwrite interact with outputPath, and what the agent gets back.

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

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

Schema description coverage is only 40%: only path and outputPath carry descriptions. The description adds nothing about text, style, or overwrite, leaving three parameters — including a required one and a defaulted mutation flag — undocumented in both places.

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 (append) and resource (paragraph) targeted at an existing DOCX document, which implicitly separates it from word_create_document and word_replace_text. However, it does not name or contrast those siblings explicitly, so the 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?

No when-to-use guidance and no alternatives named. The description never says to use word_create_document for new files or word_replace_text for substitutions, nor does it state prerequisites such as the file needing to already exist as a valid DOCX.

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 flag destructiveHint=true and idempotentHint=false, so the description should disclose what gets destroyed (e.g., that an existing file at path is replaced and that overwrite must be set). It says nothing about overwrite behavior, file clobbering, or permissions, leaving the most important behavioral risk undocumented.

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 leads with the verb and resource, then signals scope. It is dense but every clause earns its place by enumerating supported content; slightly list-heavy but 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 7-parameter, destructive, no-output-schema creation tool, the description covers content but omits the destination/overwrite semantics and the blocks-vs-sections choice that the schema only hints at. Adequate but with clear gaps for an agent deciding how to invoke it safely.

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 43% schema description coverage and 7 parameters, the description must compensate; it does partially by naming the block types and source-backed citation/bibliography capability, which maps to blocks/sources. However, path, title, author, overwrite, sections layout options, images, hyperlinks, and footnotes are left entirely to the schema.

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

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

States a specific verb and resource ('Create a DOCX') and enumerates the content the tool can produce (sections, headings, paragraphs, lists, tables, TOC, citations, bibliography), which clearly separates it from word_append_paragraph and word_inspect_document. It does not name the sibling alternatives, so it falls short of a 5.

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

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

There is no guidance on when to reach for word_create_document versus word_append_paragraph, word_native_batch, or the various template/presentation creation siblings, nor any mention of prerequisites like a writable path or working-directory context. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered elsewhere. The description adds the scope of what is read (metadata, paragraphs, styles, tables), which is genuine added context. It omits any mention of truncation or size behavior for large documents, which matters for this 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; the verb and enumerated scope come first. Nothing is wasted 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?

For a two-parameter read-only tool with no output schema, the description usefully enumerates what comes back, and the annotations carry the safety story. However, the undocumented maxParagraphs limit and the absence of any note on result shape or large-file behavior leave a meaningful gap for an agent inspecting a long 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 coverage is 50%: path is documented in the schema, but maxParagraphs has no description anywhere and the description never mentions it, even though its default of 200 implies silent truncation of paragraphs. The listed items (paragraphs, styles, tables) describe output content, not parameter meaning, so the description does not compensate for the gap.

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?

Names a specific verb (inspect) and resource (DOCX document) and enumerates the inspected content: metadata, paragraphs, paragraph styles, tables. That is enough to separate it from word_create_document, word_append_paragraph, and word_replace_text, though it never explicitly contrasts itself with the generic office_inspect_file sibling.

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

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

The description gives no when-to-use guidance, no prerequisites, and no routing hint against the many sibling inspectors (office_inspect_file, powerpoint_inspect_presentation, excel_inspect_workbook). Read-only usage is only inferable from the annotations and the verb '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?

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotency, so the safety profile is covered. The description adds real behavioral context beyond that: operations run in an ordered sequence and the tool can drive either active or closed documents. However, it never says whether a failing operation aborts the batch or leaves partial edits, nor what 'overwrite' does on save.

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, purpose front-loaded, then a dense capability list. The list is long but each item earns its place by advertising an operation family the agent can request; no filler or restatement of the name.

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

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

For a destructive, 28-operation batch tool with no output schema and a deeply nested target object, the description covers the 'what' but omits execution failure semantics, whether results are returned per operation, and the caution implied by driving a user's live application window. 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 0%, so the description must compensate, and it does partially by naming capability areas (formatting, tables, styles, fields, bookmarks, headers/footers, protection, PDF export) that map onto the op constants. But it adds nothing about target.path vs active vs create vs visible, or about the character-offset semantics of start/end — the schema's structure carries most of the 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 and resource ('Execute an ordered batch through real Microsoft Word') and enumerates the operation surface it covers, which lets an agent tell it apart from single-op siblings like word_append_paragraph or word_replace_text. It stops short of explicitly contrasting itself with those siblings, but the batch framing is unambiguous.

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

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

Signals that this is the multi-operation path but gives no explicit when-to-use/when-not guidance and names no alternatives (e.g., use word_replace_text for a one-off substitution). The phrase 'Supports active or closed documents' hints at targeting modes but is not framed as 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?

Annotations already declare destructiveHint=true, idempotentHint=false and non-read-only, so the risk profile is covered. The description adds one genuinely useful behavioral detail — that matches spanning multiple runs are handled — but omits whether all occurrences or only the first are replaced, and what happens to the original file.

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; the strongest signal (literal replacement in DOCX) comes first and the run-splitting caveat follows.

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

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

For a destructive, non-idempotent mutation with 6 parameters, 33% schema coverage and no output schema, the description is under-specified: replacement scope (all vs. first match), in-place vs. outputPath behavior, and the untouched regions of the document are all unexplained.

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

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

Schema coverage is only 33%: find, replacement, matchCase and overwrite have no schema descriptions, and the description supplies none of them. The default matchCase=true and overwrite=false semantics, and whether replacement can be empty, are left for the agent to guess.

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

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

States a specific verb (replace) plus resource (literal text in DOCX paragraphs) and identifies the sibling scope by naming DOCX, which cleanly separates it from powerpoint_replace_text. It does not explicitly contrast with word_native_batch, so it stops short of a 5.

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

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

No when-to-use, when-not-to-use, or alternative is given. An agent is not told when to pick this over word_native_batch for edits, or that the tool is limited to paragraph body text rather than headers, footers or tables.

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