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

With no annotations, the description carries the full burden of behavioral disclosure. It explains that coordinates are percentages, which is helpful, but it does not state whether the image replaces existing content, how layering works, what happens on invalid paths, or any side effects on the slide.

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

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

The description is brief and front-loaded: the primary action is in the first clause, and the coordinate clarification follows immediately. Both sentences carry substantive information, though the result is minimal and leaves gaps.

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 seven-parameter tool with no annotations, no output schema, and no sibling differentiation, this description is incomplete. It covers coordinate semantics but omits the meaning of doc_id and slide, any behavioral expectations, and any guidance on how this relates to insert_image or other slide-editing tools.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaningful semantics for path ('absolute path') and for x/y/w/h ('percent of the slide'), which are critical details. However, doc_id and slide are left unexplained beyond their names, and no format or indexing information is given.

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

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

The description states a specific action and resource: 'Place an image from an absolute path.' It also usefully explains that x/y/w/h are percentages of the slide, clarifying the core operation. However, it does not distinguish this tool from the sibling insert_image, so the purpose is clear but not uniquely differentiated.

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

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

The description gives no guidance on when to use this tool versus alternatives such as insert_image, set_slide_background, or add_shape. It mentions input conventions but no context around prerequisites, coordinate origin, or typical use cases.

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

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

No annotations are present, so the description carries the full burden of behavioral disclosure. It does state the append behavior and the ordered/bulleted distinction, but it omits side effects, insertion location, relationship to doc_id, and any return behavior.

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

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

The description is one concise, front-loaded sentence with no filler. It communicates the core operation and the key conditional behavior efficiently.

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

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

This is a five-parameter tool with no annotations, no output schema, and no schema description coverage. The description is too thin to enable reliable invocation: it does not explain size/color semantics, where the list is appended, or what happens upon success.

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

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

Schema description coverage is 0%, so the description must compensate. It clarifies 'items' via 'one string per item' and 'ordered' via 'if ordered=true', but it says nothing about doc_id, size, or color, leaving two required/three optional parameters underspecified.

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

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

The description clearly states the verb 'Append' and the resource ('bulleted or numbered list'), with the detail that each string corresponds to an item. It does not explicitly differentiate this tool from siblings like add_paragraph or insert_text, so it misses the top score.

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 about when to use add_list versus alternatives such as add_paragraph or insert_text, and no stated prerequisites or exclusions. The only usage hint is that ordered=true switches to a numbered list, which is a parameter detail rather than tool-selection guidance.

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

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

No annotations are supplied, so the description carries the burden. It discloses important behavior: coordinates are page-relative percentages (0-100), fill accepts null for transparency, and optional text is styled via color/size/bold/align. It stops short of describing side effects or return value, but the core behavior is transparent and useful.

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 compact sentences front-load purpose, then lay out coordinate/fill/text semantics and a concrete use case. There is no redundant wording, no tautology, and every sentence adds useful information.

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

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

For a basic required call, the description covers x/y/w/h and implies doc_id, and the schema provides defaults for many optional fields. But with no annotations or output schema, an agent is left without guidance on pad/font semantics or what the tool returns, so completeness is adequate but not strong for full optional use.

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

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

With 0% schema description coverage, the description compensates for key parameters: x/y/w/h are explained as percentages, fill is explained as hex or transparent, and text-related style properties are listed. However, it leaves pad, font, color defaults, and the exact relationship between text and styling mostly to inference, so coverage over the 13 parameters is incomplete.

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?

Uses a specific verb (Place) and object (page-anchored box), reinforced by concrete examples (colored band, header, pull-quote callout). This clearly distinguishes it from sibling tools like add_textbox or add_shape, which have different anchoring and content roles.

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 use-case context ('Great for letterheads and report headers') but never contrasts the tool with siblings such as add_textbox or add_shape. The intended conditions are implied by the page-anchored framing rather than explicitly stated, so guidance is moderate but not fully directive.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds meaningful behavior context by naming parameter semantics: size is points, color is hex, align has an enumerated set, and spacing is in centimeters. The word "Append" also signals that the paragraph is added at the end of the document. It does not disclose error behavior or invalid style handling, but it goes well beyond the bare schema.

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

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

The description is compact and front-loaded, with the core action stated first. Every clause adds value: the heading tip is practical, and the parameter annotations are packed into two sentences without repetition or filler. It is efficient while being 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?

Given the 11 parameters, 0% schema coverage, and no annotations, the description covers most of the information an agent needs to call the tool correctly: units, formats, allowed values, and optional style behavior. It lacks explicit guidance on font/italic semantics and does not name sibling alternatives for selection, but the core calling requirements are well covered.

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 for the most important parameters. It clarifies units for size and spacing, hex format for color, allowed align values, and the role of the style parameter. It does not explain font or italic, but these are reasonably inferable from their names, and text/doc_id are self-evident.

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

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

The description opens with a specific verb and resource: "Append a styled paragraph to a Writer doc." This clearly distinguishes the tool from siblings like add_textbox, add_list, and insert_text by stating it adds a styled paragraph to a document. The parenthetical "workhorse" and heading guidance further reinforce its intended role.

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 common use cases, such as using a large bold size for headings, which gives practical formatting guidance. However, it does not explicitly state when to choose this tool over alternatives like add_textbox or insert_text, nor does it mention any exclusions. The usage context is implied rather than explicit.

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?

Because no annotations are provided, the description carries the full behavioral burden. It does cover the rendering semantics of fill, gradient, border, text, and corner rounding, but it does not disclose side effects, return value, coordinate anchor behavior, or whether the shapes are appended or replace existing content.

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

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

The description is a dense but efficient paragraph with no filler. Every clause adds a distinct piece of parameter semantics, and the core purpose is front-loaded in the first two words.

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

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

For a 17-parameter mutation tool with no annotations and no output schema, the description is strong on units and formatting but incomplete on important context: whether x/y is a top-left anchor or center, what the 'round' shape means relative to 'ellipse', and what happens after insertion. These are meaningful gaps for an agent deciding how to invoke the tool 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 0%, yet the description compensates with unit and format details for most parameters: x/y/w/h percentages, hex fill/null handling, fill2+angle gradients, border units, text color/size/bold, and corner units. Only the self-explanatory doc_id and slide parameters are not explicitly revisited.

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

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

The description opens with 'Draw a shape' and lists the shape enum (rect|round|ellipse|line), making the tool's purpose concrete and distinct from text/image tools. However, it does not name sibling alternatives or explicitly say which adjacent tool it is not, 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?

The intended use is implied: use this when a shape with coordinates, fill, border, or text needs to be added to a slide. There is no explicit when-to-use versus add_textbox or add_image guidance, and no exclusions or alternatives are mentioned.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose the insertion behavior (appended or at index) and the return shape, but it does not mention potential side effects, duplicate-name behavior, or permissions.

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

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

A single sentence that front-loads the action and packs in the key behavioral nuance, return value, and optional index parameter. 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 simple 3-parameter add operation with no output schema, the description covers the primary behavior and return value. Minor gaps remain around doc_id semantics and edge cases, but the tool is otherwise complete enough to invoke correctly.

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

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

Schema description coverage is 0%, so the description must compensate. It explains 'name' and 'index' meaningfully, but it does not describe 'doc_id' beyond its schema title, leaving one parameter unsupported by the description.

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

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

States a specific verb and resource: 'Add a worksheet by name'. The term 'worksheet' clearly differentiates this from sibling add_* tools, and the optional index behavior is included.

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?

Clear context is provided: use this when you need to add a worksheet by name, optionally at a specific position. It does not explicitly name alternatives or exclusions, but the resource type makes the intended use obvious.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal the return value 'Returns {index, count}' and the layout default behavior, which is helpful. It does not mention permissions, error conditions, or the fact that this mutates the presentation, limiting transparency.

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

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

The description is extremely efficient: two sentences with no filler. The primary action and return value are front-loaded, followed by a relevant caveat about new presentations and a precise note about the layout parameter.

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 description covers the operation, return format, and a key behavioral gotcha, which is solid for a simple append tool. However, it omits any explanation of doc_id and does not describe failure behavior or prerequisites. Given the absence of an output schema and annotations, this is a noticeable gap.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the layout parameter ('Impress autolayout id' and default) but does not clarify the required doc_id parameter at all. Partial coverage of two parameters yields an adequate but incomplete semantic description.

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

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

The description clearly states the specific operation 'Append a slide to an Impress presentation' with a concrete verb and resource. It is easily distinguishable from sibling tools like add_text, add_shape, and add_image, which operate on different resource types.

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 first sentence implies the use case (adding a new slide), and the note about a new presentation already having one slide provides useful context. However, it does not explicitly state when to use this tool versus alternatives or mention any exclusion criteria, leaving the 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?

With no annotations, the description carries the burden of behavioral disclosure. It adds useful behavioral detail: coordinates are percent of the slide, size is in points, color is hex, align/valign have specific allowed values, and newlines create multiple lines. However, it does not disclose side effects such as whether a new text box is always added, how overlapping is handled, or any error behavior.

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

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

The description is compact and front-loaded. The main purpose appears first, followed by concise semicolon-separated parameter semantics. Every sentence adds useful information and there is 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?

Given 14 parameters, 0% schema description coverage, and no output schema, the description provides the essential geometry and formatting details but omits important contextual pieces like slide indexing convention, the meaning of doc_id, font semantics, and whether it replaces or appends. It is adequate for common calls but not fully complete for a tool with this 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?

Schema description coverage is 0%, so the description must compensate. It explains x/y/w/h as percent, size in points, color as hex, align/valign values, and newline handling in text. But it does not explain doc_id, slide, bold, italic, or font, leaving several parameters underspecified.

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

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

The description opens with a clear verb+resource: 'Place a styled text box.' It then gives concrete formatting semantics. It does not explicitly distinguish itself from sibling tools like add_paragraph or add_shape, but the notion of a text box is clear enough to identify its core purpose.

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 about when to use this tool versus alternatives such as add_shape, add_paragraph, or insert_text. No conditional context, no exclusions, and no mention of sibling tools. The usage context must be inferred entirely from the tool name and general purpose.

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

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

With no annotations, the description carries full responsibility for disclosing behavior. It reveals the refusal-with-warning behavior for unsaved changes, explains the rationale (not silently discarding in-flight work), and clarifies that force=true discards. This is exemplary behavioral disclosure.

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

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

The description is compact, front-loaded with the main action, and uses a follow-up sentence to warn and provide guidance. Every sentence earns its place with no filler.

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

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

For a simple two-parameter close operation with no output schema, the description covers the essential behavior, edge case (unsaved changes), and resolution path. Nothing critical is missing for an agent to call 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?

The schema provides no descriptions, so the description must compensate. It adds meaningful semantics for force=true (close and discard unsaved changes), but doc_id is not explicitly explained beyond the tool's context. Still, doc_id is self-evident for identifying the document to close.

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

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

The description opens with a clear verb+resource statement: 'Close an open document.' It is immediately distinguishable from sibling tools like open_document and save_document, and leaves no ambiguity about the operation.

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

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

It explicitly states when to use the tool and how to handle unsaved changes: save_document first, or pass force=true to discard. This gives the agent actionable routing between close_document, save_document, and the force parameter.

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

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

No annotations are present, so the description carries the disclosure burden. It explains the return shape, the doc_id-based workflow, and show behavior in detail, including live mode, defaulting, off-screen building, and headless-server no-op. It stops short of covering persistence or error behavior, but the critical behavioral traits are disclosed.

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

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

The purpose is front-loaded in the first sentence, and each parameter has a focused explanation. The show explanation is slightly longer than strictly necessary, but every sentence adds meaningful information.

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

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

For a two-parameter creation tool, the description covers parameters, return value, and the doc_id lifecycle handoff. It does not mention persistence, file naming, or how it relates to open_document, but these are secondary for a create call.

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 fully compensates. It documents the allowed kind values, the return relationship to kind, and the show parameter's meaning, defaults, and runtime context. This goes well 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?

States a specific verb ('Create'), a specific resource ('new empty LibreOffice document'), and enumerates document kinds. It also names the return value and the doc_id handoff, which distinguishes it from sibling tools like open_document and save_document.

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

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

The description implies usage as the starting point for a new document ('pass doc_id to subsequent tools'), giving some context. However, it does not explicitly say when to use this tool versus open_document for existing documents, or mention any exclusions.

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

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

With no annotations, the description carries the behavioral disclosure burden. It states the destructive action and the zero-based index, and mentions the return value, but it does not disclose side effects such as reindexing of remaining slides, irreversibility, or error behavior. The core behavior is clear, but context is minimal.

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

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

The description is exceptionally compact, front-loads the operation, and includes only useful information: the action, the index convention, and the return value. There is no unnecessary text or duplication of schema fields.

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

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

For a low-complexity tool, the description covers the main action and return value, but it omits practical caveats such as index shifting after deletion and whether the document must remain open or be saved afterward. An agent working with multiple slides could misuse it without those hints.

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

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

Schema description coverage is 0%, so the description must compensate. It usefully specifies that 'index' is 0-based, which the schema does not say, but it leaves 'doc_id' to be inferred from its parameter name alone.

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

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

The description clearly names the operation ('Delete'), the target resource ('slide'), and the indexing convention ('0-based index'). This distinguishes it well from sibling tools like add_slide, read_slide, and list_slides, making the tool's purpose unambiguous.

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

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

The description gives no guidance on when to use this tool versus alternatives, no prerequisites, and no mention of important considerations like indices changing after deletion. The only usage cue is the implicit one from the verb 'Delete', which is not enough to route an agent with confidence.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It does communicate a read-only operation via 'Get', requires an open document, and lists the returned fields. However, it does not disclose error behavior, access requirements, or what happens if doc_id is invalid.

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 short, front-loaded sentence with no filler. Every phrase adds information about the action, the required context, or the return shape.

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

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

For a simple metadata getter, the core action and return values are defined, but important context is missing: doc_id semantics are undocumented, there is no output schema, and there is no guidance on errors or preconditions beyond 'open document.' An agent would need to infer doc_id provenance from sibling tools like open_document.

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

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

Schema description coverage is 0%, and the description says nothing about doc_id: not its format, not how to obtain it, not that it must reference an already-open document. The sole parameter's meaning is left entirely to inference from its name.

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

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

The description names a specific action (Get), a resource (open document), and exactly which fields are returned (kind, url, modified). It distinguishes itself from content-reading siblings like get_text and read_slide by limiting its scope to metadata, though it does not explicitly name those alternatives.

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

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

No guidance is provided about when to use this tool versus alternatives, and there are no exclusionary conditions or references to sibling tools. The only contextual hint is that the document must already be open, but the criteria for choosing document_info are left entirely implicit.

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

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

With no annotations, the description carries the disclosure burden. It states the core write behavior and adds the format-inference rule, but does not mention potential overwrites, permissions, document-state requirements, or the return value.

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 concise, front-loaded sentences with no filler. The core operation comes first, and the second sentence adds only necessary format/default details.

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 description provides the essential calling details and format default behavior, which is enough for a basic call. But with no annotations and no output schema, the missing usage differentiation and side-effect/return disclosure make it incomplete for confident tool selection.

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

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

Schema description coverage is 0%, so the description must compensate. It does for path ('absolute path') and format (examples plus inference from extension), while doc_id is left implicit but its name is self-evident.

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

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

The description names a specific action and resource: 'Export a document to an absolute path in the given format.' It also enumerates concrete formats and explains extension inference, making the tool's scope clear and distinguishable from siblings like save_document or open_document.

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

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

Usage context is implied: this is the tool for producing a document file in a specified format at an external absolute path. However, no explicit when-to-use or when-not-to-use guidance is given, and no alternatives are named.

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

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

With no annotations, the description does carry the behavioral burden and does disclose that this is a mutating operation, that it affects all occurrences, and that it returns a count. It also explains regex semantics. However, it omits side-effect context such as whether changes are persisted automatically, whether the document must be open, or whether the operation is reversible.

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

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

The description is compact and front-loaded: two sentences cover the core action, the return value, and the optional regex behavior. Every sentence earns its place with no unnecessary 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 mutating tool with no annotations and no output schema, the description states the core behavior and return value but leaves out important context: whether the document needs to be open, whether changes are saved immediately, and what happens when no matches are found. These are operational gaps an agent must resolve to invoke the tool 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?

Schema description coverage is 0%, so the description must compensate. It successfully explains regex=true, clarifies that search and replace are literal values, and implies the operation is document-scoped through doc_id. It doesn't delve into edge cases like case sensitivity, but the core paramter meanings are conveyed beyond the bare schema titles and types.

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

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

The description states a specific operation ('Replace all occurrences of search with replace') with a clear resource (the document identified by doc_id) and notes the return value. The verb-action-object structure makes the tool's purpose unmistakable and distinguishable from sibling text tools like get_text or insert_text.

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

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

The description provides no guidance on when to use this tool versus alternatives such as insert_text or get_text, and no prerequisites are mentioned. The only usage hint is the regex flag, which is about parameter behavior rather than tool selection.

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

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

With no annotations, the description carries the burden. It makes the read-only nature explicit ('Return... full plain text') but does not disclose requirements like whether the document must be open, permission needs, or error behavior. The lack of contradiction keeps it from being lower.

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

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

One tightly worded sentence that leads with the action, specifies the resource and output shape, and contains 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 single-parameter read tool, the description covers the core behavior and return shape, but with no annotations and no output schema it leaves context like document-state requirements and failure modes unstated. It is minimally complete for simple use but not fully self-sufficient.

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

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

Schema description coverage is 0% and the description adds no direct explanation of doc_id beyond referencing a Writer document. The parameter is simple and self-explanatory, so the gap is minor, but the description still does not compensate for the missing schema description.

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

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

The description states a specific verb ('Return'), a specific resource ('Writer document'), and the output shape ('as {text}'). It does not explicitly call out sibling tools, but 'full plain text' sets it apart from slide-level tools like read_slide.

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

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

No guidance is provided on when to use get_text versus alternatives such as read_slide, document_info, or find_and_replace. The expected invocation context is left implied rather than stated.

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

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

With no annotations, the description carries the full burden of disclosure. It usefully conveys that the image is inserted inline and scaled while preserving aspect ratio, but it does not mention insertion position, side effects, file type requirements, or return behavior. It adds some behavioral context but leaves significant gaps.

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

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

The description is a single, focused sentence with no wasted words. It front-loads the main action and immediately provides the most relevant constraints.

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

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

For a 3-parameter tool with no output schema and no annotations, the description is incomplete. It does not clarify where the image is inserted, whether the document must be open, what file formats are accepted, or what the tool returns. An agent would need additional context to invoke it reliably.

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

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

Schema description coverage is 0%, so the description must compensate. It adds meaning to path by requiring an absolute path and to width_cm by explaining scaling and aspect preservation, but it does not explain doc_id or its role. The description partially compensates for the schema's lack of parameter descriptions.

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

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

The description clearly states the action (insert), resource (image), and key constraints (inline, absolute path, scaled to width_cm, aspect preserved). It is specific but does not explicitly differentiate from the sibling tool add_image, so it stops short of full distinction.

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

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

The description provides no guidance on when to use this tool versus alternatives such as add_image or insert_table. It also omits any exclusions, prerequisites, or context about document state, leaving the agent without criteria for choosing this tool.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does reveal one meaningful behavior: with header=true, the first row receives the accent background and white bold text. However, it omits other behavioral details such as where the table is placed, whether it appends or replaces content, or what side effects occur. For a mutating operation, this is a significant gap.

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

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

The description is appropriately brief, two concise sentences with the key input format and the most notable styling behavior front-loaded. There is no wasted text, though it prioritizes brevity over completeness, which is acceptable given the format.

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

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

This tool has no annotations, no output schema, and a 0% schema description coverage, so the description alone must make the tool fully understandable. It fails to explain the required doc_id parameter, the meaning of size/color/accent, or the context of use relative to siblings. An agent would likely guess at several parameters and could misapply the 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 0%, so the description must compensate. It explains the meaning of 'rows' and 'header' (the header styling effect), but completely ignores doc_id, size, color, and accent. With 6 parameters and only 2 partially addressed, the description does not provide enough semantic grounding for an agent to confidently set all parameters.

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

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

The description states a specific verb ('Insert'), a resource ('a table'), and the input format ('a 2D list of rows'). This distinguishes it from sibling insert tools like insert_image and insert_text, and the '2D list of rows' detail clarifies what kind of table data is expected. However, it could be confused with add_sheet or style_cells without additional context.

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

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

No guidance is given about when to use this tool versus alternatives like add_sheet, style_cells, or insert_text. The description does not state whether the table is inserted into a slide, document, or spreadsheet, nor does it mention any prerequisites such as having a document open or a specific mode.

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

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

The description discloses the core behavior: text is appended at the document's end, and paragraph_break controls whether a new paragraph starts first. However, with no annotations, it does not cover side effects such as formatting implications, whether an open document is required, or what happens on failure.

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

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

The description is two short sentences, front-loaded with the main purpose and then focused on the one non-obvious parameter. There is no wasted text.

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

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

For a tool with no annotations, no output schema, and no parameter descriptions, the definition is incomplete. An agent still needs to infer how to obtain a valid doc_id, whether the document must already be open, and what the operation returns. The paragraph_break behavior is helpful but does not fill 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 description coverage is 0%, so the description must explain the parameters. It explains paragraph_break but text and especially doc_id are left entirely to their property names, which is thin for an agent that needs to know where doc_id comes from.

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 clear action ('Append text') on a clear resource ('a Writer document') and specifies the location ('at the end'). It is easy to distinguish from read-oriented siblings like get_text, though it does not explicitly name alternative 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?

There is no guidance about when to use this tool versus related tools like add_paragraph, add_textbox, or insert_text. The only instruction, about paragraph_break, is parameter-level guidance, not tool-selection guidance.

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

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

No annotations are provided, so the description carries the transparency burden. It discloses the exact return format and the scoping ('currently open'), which tells the agent this is a read-only enumeration rather than a mutating operation. It does not discuss permissions or side effects, but the 'List' verb and zero parameters make the behavior straightforward.

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 concise sentence that states the action, the scoping, and the return-type shape. Every element is useful and there is no redundant filler.

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

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

For a zero-parameter, low-complexity tool, the description fully equips an agent: no arguments are needed, and the output format is specified. Nothing essential is missing for correct invocation.

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

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

The tool has zero parameters, and the schema description coverage is 100% (an empty properties object). The description adds meaningful output-shape information even though no parameter documentation is needed, so the baseline of 4 applies.

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

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

The description uses a specific verb ('List') and resource ('currently open documents'), and names the exact return shape. It is clearly distinguishable from sibling tools like list_slides (slides within a document) and open_document (which opens, not lists).

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 'currently open documents' gives clear context: this is the tool to use when you need to enumerate docs that are already open. It does not explicitly name alternatives or exclusions, but for a zero-param list tool the intended context is reasonably clear.

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

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

No annotations are provided, so the description carries the burden. It does disclose the return contract ({slides: [{index, title}], count), which is helpful. It does not mention side effects, ordering, errors, or auth requirements, though 'list' suggests a read-only operation.

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

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

A single sentence, front-loaded with the verb and resource, and it includes the output shape with no 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?

For a simple one-parameter retrieval tool, the description gives the output schema and a clear listing behavior. It is slightly incomplete by not explicitly stating the slides are from the document identified by doc_id and not covering edge-case behavior, but it is adequate for correct invocation.

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

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

Schema description coverage is 0%, and the description never mentions doc_id or explains how it relates to the listing. Schema only gives the parameter name and type. Since coverage is low, the description does not compensate.

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

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

The description uses a specific verb and resource ('List slides') and specifies the exact result shape. This clearly distinguishes it from siblings like read_slide (single slide content) or add_slide/delete_slide (mutations).

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 function is self-evident for retrieving slide metadata, so the intended use is implied. However, there is no explicit guidance about when to prefer this over read_slide or list_documents, and no exclusion or alternative mentioned.

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

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

With no annotations provided, the description carries the burden of explaining behavior. It usefully discloses the return value shape {doc_id, kind, path} and the semantics of the show parameter, including its default fallback. However, it does not mention side effects such as whether the opened document becomes the active document, what happens if the path does not exist, or whether multiple documents can be open simultaneously.

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

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

The description is compact and front-loaded, with the core purpose stated in the first sentence and the parameter/return details following directly. It avoids filler, repetition, and unnecessary detail.

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

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

The description covers the return contract and both parameters, which is sufficient for a low-complexity tool with no output schema. It could be more complete by stating error behavior or whether opening changes the active document, but the essential calling inforation 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?

Schema description coverage is 0%, so the description must explain both parameters. It does: path is specified as an absolute filesystem path, and show is explained with concrete behavior (visible window vs off-screen, defaulting to the server's live setting). This adds real meaning beyond the bare schema titles and types.

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

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

The description clearly states the action: 'Open an existing document from an absolute filesystem path.' This specifies a precise verb and resource and distinguishes the tool from siblings like create_document (new document) and list_documents (listing). It leaves no ambiguity about what operation is performed.

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 communicates a clear usage context: use this when you have an existing document and its absolute filesystem path. It does not explicitly name alternatives or state when not to use it, but the 'existing document' wording effectively rules out creation use cases. The show parameter guidance also clarifies when visible vs. off-screen editing is relevant.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It does add useful details beyond the schema, such as margin applying to left/right/bottom, top overriding the top margin, and the header-band tip. However, it does not disclose likely side effects, whether the document needs to be open, or what happens when only some parameters are provided.

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

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

The description is compact: two sentences, with the primary purpose first and parameter clarifications second. Every phrase earns its place, and the header-band tip provides practical value without bloat.

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

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

For a simple four-parameter setup tool with no output schema, the description covers the tool's purpose, parameter semantics, and units. The main gap is the lack of guidance on when to choose this tool over similarly named siblings, and it does not mention any side effects on existing formatting.

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 supply all parameter meaning, and it does. It explains margin as left/right/bottom, top as an override for the top margin, and color as a hex background color. doc_id is self-evident as the target document identifier.

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

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

The description opens with a specific verb and resource: 'Set page margins (cm) and/or page background color (hex) for a Writer doc.' It clearly differentiates from siblings like set_slide_background by targeting Writer documents rather than slides. The scope of what the tool modifies 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?

The description implies usage for adjusting page margins or background color, but provides no explicit guidance on when this tool should be preferred over alternatives such as set_slide_background or add_page_box. No prerequisites, exclusions, or sibling comparisons are mentioned, leaving the agent to infer when to use it.

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

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

With no annotations provided, the description discloses key runtime behavior: rows are lists, numbers vs strings are returned, formula=true changes values to formula strings, and sheet defaults by name or 0-based index to the first sheet. This is exactly the behavioral context an agent needs.

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?

Every sentence earns its place: first sentence states purpose and output shape, second explains row types, third explains formula mode, fourth explains sheet selection. No filler or repetition.

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

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

Given there is no output schema and no annotations, the description covers return format, value types, formula behavior, and sheet addressing, which is sufficient for safe invocation. Only doc_id semantics and explicit read-only status are left implicit.

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?

Input schema has 0% property descriptions, so the description compensates well for range, formula, and sheet with examples and semantics. It does not explicitly describe doc_id, though the parameter name is reasonably self-evident.

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

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

The description uses the specific verb 'Read' with a concrete resource ('cell range') and gives the return shape '{values: [[...]]}', so an agent understands exactly what operation is offered. It does not explicitly name sibling tools like set_cells or get_text, but the cell-range focus makes it distinguishable.

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 clear context for when to use the tool (reading a cell range from a spreadsheet) and useful conditional guidance ('Set formula=true ... useful for inspecting an existing model'). It does not explicitly list alternatives or exclusion cases, so it stops short of 5.

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

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

With no annotations, the description carries the full burden of behavioral disclosure. It clearly explains the return contract: title placeholder, bullets placeholder split into lines, and all non-empty strings in z-order, including text boxes and shape labels. It does not discuss error behavior or side effects, but this is a read operation and the core semantics are well disclosed.

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

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

The description is compact, front-loaded with the core purpose, and uses a clear return signature. Each sentence adds meaningful detail about field semantics, with no filler or redundancy.

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

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

The description provides a rich output contract despite the absence of an output schema, which is valuable for an agent. It omits edge-case behavior such as out-of-range indexes and does not explain doc_id, but the level of detail is otherwise sufficient for typical use of a read operation.

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

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

The description adds meaning to 'index' by explicitly stating it is 0-based and ties it to slide position. However, 'doc_id' is left entirely to the schema's bare name with no explanation of its format or how to obtain it. Since schema description coverage is 0%, the description only partially compensates for the missing parameter documentation.

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 ('Read'), a precise resource ('a slide's text content'), and quantifies the indexing scheme ('by 0-based index'). It also distinguishes itself from siblings like list_slides or get_text by focusing on a single slide's full text content, including non-placeholder shapes.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as get_text or list_slides. The inclusion of graphics-built text boxes implies broader coverage, but no direct comparison, exclusions, or decision criteria are provided.

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

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

With no annotations, the description carries the disclosure burden and does disclose important behavior: saving in place requires an existing location, an absolute path triggers a copy, and format is derived from the extension if omitted. It doesn't cover overwrite behavior, errors, or side effects, but the core behavioral traits are transparent enough for a 4.

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

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

The description is short, front-loaded with the operation, and each sentence adds distinct information. There is no filler or redundant restatement of the tool name.

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

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

The main call paths (in-place and save-as-copy) are documented, but several edge cases remain unspecified: what happens when format is passed without a path, whether an existing file is overwritten, and whether the document must already be open before saving. These gaps prevent full completeness for a tool with no output schema or annotations.

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

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

Schema coverage is 0%, so the description must compensate. It explains path behavior and format inference with examples, but it never explicitly defines doc_id or how format interacts when path is omitted, leaving some parameter meaning implicit.

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 concrete action ('Save a document') and specifies two modes (in-place vs. save-as-copy), clearly identifying the tool's responsibility. It does not explicitly distinguish itself from sibling export_document, so it earns a 4 rather than a 5.

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

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

The description provides operational guidance for choosing path vs. no path (in-place vs. copy), and when format can be omitted. However, it does not discuss when to prefer save_document over sibling tools such as export_document or close_document, so comparative usage guidance 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?

With no annotations, the description carries the full burden and discloses substantial behavior: numeric values are written numerically and other values as text, formulas starting with '=' are evaluated by Calc, and sheet defaults to the first sheet. The main gap is that the promised return '{written}' is not explained (count vs. list), and overwrite behavior of existing cells is never mentioned.

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

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

The description is compact and front-loaded, opening with the core action and return before moving to the parameter format. Each sentence adds distinct information — example structure, coercion rules, formula evaluation, sheet selection — with no filler or repetition of what the schema already shows.

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

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

For a three-parameter mutation tool with no annotations and no output schema, the description covers invocation well: both required parameters are usable from the text and the optional sheet parameter is fully explained. It falls short only in not clarifying what the '{written}' return value contains and in not routing the agent away from formatting siblings.

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: the cells parameter is fully explained with a concrete example and distinct rules for value vs. formula entries, and sheet is specified as name-or-index with a default. Only doc_id is left to inference, though its name and schema title make it self-evident.

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, 'Write cells in a Calc document. Returns {written},' uses a specific verb and resource, making the contrast with sibling read_cells obvious (write vs. read). The value/formula entry examples further distinguish it from formatting siblings like style_cells and set_column_width, which target presentation rather than content.

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

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

The description thoroughly explains how the tool behaves — entry format, value vs. formula handling, sheet selection — but never states when to prefer it over alternatives such as read_cells for reading or style_cells for formatting. Usage context is implied by the tool's purpose rather than explicitly declared with exclusions or alternative 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that the width is set, with no mention of potential side effects, whether the change is reversible, scope constraints, or permission requirements. 'Set' implies mutation, but nothing else is disclosed.

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

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

The description is a single efficient sentence with a helpful example. It is front-loaded with the action and target, and every word adds value with no redundancy.

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

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

This is a relatively simple mutation tool, and the description covers the key action and format details. Still, with no annotations and no output schema, it omits side-effect expectations, success/error behavior, and the meaning of the optional 'sheet' parameter, leaving 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%, but the description adds useful meaning for 'columns' ('A' or 'A:E') and 'width_cm' (cm). However, it leaves 'sheet' unexplained even though it accepts string, integer, or null, and it does not clarify the role of 'doc_id' beyond its name.

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

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

The description states a specific verb ('Set'), the resource ('column or column span'), and the unit ('cm'), with a concrete syntax example ('A' or 'A:E'). This makes the tool's purpose unambiguous and clearly distinct from related sibling tools like style_cells or set_cells.

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 about when to use this tool versus alternatives, nor any exclusions or prerequisites. The only usage signal is implied by the name and description, which is not enough for an agent to decide between this and similar editing tools.

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

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

With no annotations, the description carries the behavioral burden. It discloses that the operation affects the whole deck, identifies the default value, and warns to call it once before layout. It does not describe what happens if called after slides already exist, but for a simple setter this is mostly sufficient.

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

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

Two short, purposeful sentences with no filler. The purpose is front-loaded, and the usage guidance is placed directly after the operation definition.

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 low-complexity tool with 2 parameters and no output schema, the description covers the action, valid values, default, and timing. The only notable gap is the unstated meaning of doc_id and any effects on existing slides if called after layout.

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

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

Schema description coverage is 0%, so the description must compensate. It does clarify the 'preset' parameter by listing valid values and the default, but it does not explain 'doc_id' at all, leaving one of two parameters to be inferred.

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

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

The description clearly states the verb 'Set' and the resource 'slide aspect ratio for the whole deck', and it enumerates the valid values ('16:9' or '4:3'). This is specific enough to distinguish the tool from siblings like set_slide_background or content-insertion 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?

It gives explicit usage guidance: 'Call this once on a new presentation before laying out slides.' This tells the agent when in the workflow to invoke it, though it does not mention alternatives or when-not-to-use conditions.

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

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

With no annotations, the description carries the safety and behavior burden. It discloses the stacking/back-layer behavior and the gradient effect of color2/angle, which is useful context beyond the bare schema. It could mention repeated-call or overwrite behavior, but the core side effect is clear.

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

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

Three compact sentences deliver the main purpose, the key ordering constraint, the gradient option, and color format. Every sentence adds value and 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?

The description covers the tool's main behavior and gradient parameters well, but with no annotations and no schema descriptions, it should also clarify doc_id and slide identification. The slide index base (0-based vs 1-based) is a notable missing detail for correct invocation.

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

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

Schema description coverage is 0%, so the description must compensate for the parameters. It clearly explains color, color2, and angle semantics, including hex format and gradient direction. However, doc_id and slide are left entirely to inference, and the slide indexing convention is not specified.

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?

It states a specific action, 'Fill a slide's background', with the resource and purpose explicit. This clearly distinguishes it from sibling slide tools like set_slide_content or add_slide.

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 explicit ordering advice, 'Call this FIRST on a slide', and explains when color2 should be passed for a gradient. It does not explicitly list when-not scenarios or alternatives, but the layering instruction is strong usage 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?

With no annotations, the description carries the full burden of behavioral disclosure. It indicates a mutating action ('set') but does not explain whether existing title/bullets are overwritten, what happens when both title and bullets are omitted, what happens if the index is out of range, or what the response contains. This is a meaningful transparency gap for a write operation.

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

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

The description is highly concise and front-loaded, stating the core operation in the first sentence and then supplying necessary detail about the bullets parameter. Every sentence earns its place, and there is no redundant or filler content.

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

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

The description provides enough information for an agent to construct a basic call with doc_id, index, title, and bullets. However, without annotations or an output schema, it leaves out edge-case behavior such as clearing existing content, handling an invalid slide index, or what the tool returns. This makes it minimally viable but not fully complete.

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

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

The schema provides no parameter descriptions, so the description must compensate. It adds critical meaning by specifying that the index is 0-based and that bullets is a list of strings with one string per bullet line. The title parameter's role is also clarified through 'title and/or bullet body,' and doc_id is self-evident as the document identifier.

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

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

The description clearly states the tool's function: 'Set a slide's title and/or bullet body by 0-based slide index.' This is a specific verb and resource and it distinguishes the tool from siblings like set_slide_background or add_shape. However, it does not explicitly differentiate itself from alternatives within the description.

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

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

The intended use is implied by the phrase 'set a slide's title and/or bullet body,' making it clear this is for editing slide content rather than background or layout. There is no explicit guidance about when to prefer this tool over siblings like add_textbox or find_and_replace, and no mention of prerequisites such as the slide needing to already exist.

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

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

No annotations are provided, so the description carries the full behavioral burden. It clearly communicates that styling is applied without resetting unmentioned properties ('Only the args you pass are applied'), which is a meaningful behavioral guarantee. It does not cover permissions, return value, or failure modes, but for a formatting operation these are less critical.

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

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

The description is a single front-loaded sentence with no filler. Every clause contributes either a parameter explanation, an example, or a critical behavioral caveat.

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

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

Given 11 parameters, no output schema, and no annotations, the description covers the core styling parameters and the important partial-application behavior. It does not explicitly explain how sheet is selected or mention what the tool returns, but this is unlikely to prevent correct use for a styling operation.

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

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

Schema description coverage is 0%, so the description must add meaning to the parameter names. It does this well: it explains size is in points, align's allowed values, and gives concrete number_format examples. It leaves sheet and doc_id implicit, but those are conventional identifiers and less likely to confuse.

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 concrete action ('Format') and a specific resource ('a cell range'), then enumerates the styling dimensions. This makes it immediately clear this is a formatting operation, distinct from sibling data-manipulation tools like set_cells or read_cells.

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 does not explicitly name alternatives or state when to prefer style_cells over set_cells/read_cells, but 'Format a cell range' and 'Only the args you pass are applied' provide usable guidance for the typical styling use case. The partial-update note helps an agent know it does not need to specify every style property.

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