KitchenSink4Word
Server Quality Checklist
Latest release: v1.6.1
- Disambiguation3/5
Most tools target distinct resources and actions with thorough descriptions, but the sheer volume creates overlapping families (validate_document vs diagnose_document vs com_validate_opens_clean; revision_summary vs revision_analytics; find_text vs find_formatted). An agent selecting among 189 tools is likely to mispick between close siblings despite the documentation.
Naming Consistency3/5The dominant get_/set_/add_/delete_/insert_/list_ pattern is readable and many families are internally consistent. However, conventions are mixed with com_* and live_* prefixes, noun-first names like comment_report and revision_summary, and outliers like search_and_replace and word_live_repair.
Tool Count1/5189 tools is an extreme count for any single MCP server, far beyond the 50+ threshold for severe over-scoping. Even with clear descriptions, the surface is overwhelming and makes tool selection a bottleneck rather than a convenience.
Completeness4/5The surface is impressively comprehensive across Word documents: paragraphs, tables, notes, headers/footers, sections, citations, fields, images, charts, comments, tracked changes, forms, redaction, validation, and document assembly are all covered. Minor CRUD gaps exist—no delete_bookmark, delete_image, or remove_hyperlink—but these are workable rather than blocking.
Average 4.4/5 across 171 of 189 tools scored. Lowest: 3.1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 45 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
This server has been verified by its author.
How to sync the server with GitHub?
Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.
To manually sync the server, click the "Sync Server" button in the MCP server admin interface.
How is the quality score calculated?
The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).
Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.
Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).
Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.
Tool Scores
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does meaningful work: it discloses auto-backup behavior, the backup=False rotation behavior, atomic validated saving, and refusal when the document is open in Word. This goes well beyond a bare action statement, though it does not mention what happens to existing page numbers or fields.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, then adds safety and behavioral details. The backup sentence is dense but efficient. Some jargon like 'prev/anchor slots in .ks4w-backups' could be clearer, but every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with eight parameters, no annotations, and zero parameter-description coverage, this description is not complete enough. It supplies useful behavioral context but omits parameter semantics and usage alternatives, so an agent would still need to infer or probe the meaning of position, section, start_at, prefix, and alignment.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 only clarifies x_of_y (renders 'Page N of M') and partially backup (skips rotation only). The other six parameters — position, section, start_at, prefix, alignment, and file_path — receive no semantic explanation, leaving an agent to guess valid values and interactions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Add page numbers (PAGE field) to the header or footer') and a distinguishing behavior ('x_of_y renders Page N of M'). It is unambiguous about the resource, though it does not explicitly name sibling tools like set_page_number_format or set_header/set_footer to draw a contrast.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives such as set_page_number_format, set_header, or set_footer. The note about refusing documents open in Word is a constraint, not usage direction. The intended context is only implied by the tool's name and purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description supplies useful behavioral context: auto-backup to .ks4w-backups, backup parameter effect, atomic validated save, and refusal of Word-open documents. However, the meaning of 'prev/anchor slots' and 'rotation only' is cryptic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loads purpose in the first sentence, with additional behavior in a compact second line. The compressed 'rotation only' phrase and jargon ('prev/anchor slots') sacrifice clarity for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter tool with no annotations and no schema descriptions, the description leaves significant gaps—placement parameters, default positioning, and parameter interactions are not explained. The output schema covers return values, but the call semantics are incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description explains only backup behavior and indirectly width via aspect ratio. Parameters like after_index, after_anchor, at_end, and alignment remain undocumented, leaving placement semantics unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Insert') and resource ('inline image'), names supported formats, and adds the aspect-ratio behavior. It distinguishes add_image from siblings like resize_image and replace_image by operation, though it doesn't name them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative routing is provided; the agent must infer from 'Insert' that this is for adding a new image rather than resizing or replacing. It gives a usable constraint (refuses Word-open documents) but doesn't tell when to prefer replace_image or list_images.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that documents open in Word are read live, that the entry shape is the same, and that live IDs are comment positions rather than XML IDs. It does not explicitly state that the operation is read-only, but the name and content make that reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two tight sentences with no filler. The most important content is front-loaded, and the technically important live-mode caveat is placed at the end without bloating the description.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return shape, but with no annotations and no parameter documentation, the description needs to do more. It handles the live behavior well but omits file_path and author semantics and gives no usage context relative to sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 some meaning around the live parameter by explaining live-id behavior, but it does not explain file_path or how the author filter behaves, leaving most parameter semantics undocumented.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('comments') and enumerates what is included: authors, anchored text, threading, and resolved state. It is clear that this is a read operation, but the description itself lacks an explicit verb like 'retrieves' or 'lists'; the name 'get_comments' supplies that role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus siblings such as comment_report, comment_report_multi, or get_document_info. The live-mode note describes behavior but does not help an agent decide between alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full behavioral disclosure burden. It discloses backup behavior (prev/anchor slots in .ks4w-backups), the subtle effect of backup=False ('skips rotation only'), atomic validated saving, and refusal to operate on documents open in Word. These are meaningful safety and edge-case details beyond the plain 'set' implication, though permissions and reversibility are not mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three compact sentences with the core action front-loaded before behavioral caveats. Every sentence adds information, and there is no filler. The phrase 'atomic validated save' is terse jargon but still earns its place by conveying data-integrity behavior.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given 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 zero schema descriptions, the description delivers strong operational context around backups and Word-lock refusal. However, it leaves several parameters (section, alignment) and the effect on existing header variants unexplained. The presence of an output schema covers return-value shape, so the primary gaps are parameter semantics and alternative routing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% property description coverage, so the description must compensate. It explains ref_type values and backup's semantic nuance, but leaves section, alignment, text, and file_path to be inferred from their names and defaults. This is only partial compensation for a schema that is entirely silent about parameter meanings.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Set a section's header text', naming a specific verb, resource, and scope. It also enumerates the ref_type variants (default|first|even), which clearly distinguishes header editing from footer or chapter-header operations. This separates it from siblings like set_footer and setup_chapter_headers without needing to read the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does 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 instead of alternatives such as set_footer, get_headers_footers, or setup_chapter_headers. The only implicit signal is the header-specific wording and ref_type list, but no when-to-use or when-not-to-use conditions are provided. An agent must infer applicability from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden, and it does well by enumerating scan scope: fragmented runs, tracked deletions, field instructions, attributes, metadata, and hyperlink targets. It also reveals that binary parts are listed under not_examined rather than silently trusted. The unexplained 'clean=True' reference is a notable gap since no such parameter exists in the input schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is fairly dense and front-loads the core purpose before enumerating the scan scope. Some redundancy exists between 'without changing anything' and 'Read-only', and the unexplained 'clean=True' adds noise, but overall it remains efficient and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description gives strong context on use cases, read-only behavior, XML coverage, and binary handling, which is substantial for an audit tool. However, it is incomplete because it references 'clean=True' without support for it in the schema and does not define the pattern format, leaving important invocation details unresolved.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 lack of parameter documentation. It only loosely implies that 'targets' are patterns and that file_path points to a document, but it does not explain the expected structure of targets or the file_path handling, leaving the agent with inadequate parameter-level guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies verify_redaction as a read-only rescan that checks whether given patterns still appear anywhere in the XML, including hidden locations. It is distinguishable from sibling tools like redact_text and find_text by its explicit audit framing, though it does not name alternatives and introduces the ambiguous 'clean=True' flag.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when to use the tool: to audit a third-party file or a file redacted elsewhere. The 'without changing anything' and 'Read-only' wording clearly signal it is not for performing redaction, but it does not explicitly name alternatives or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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: auto-backup to prev/anchor slots in .ks4w-backups, the specific effect of backup=False, atomic validated save, and refusal to operate on documents open in Word. It does not cover duplicate-name behavior, but this is a strong disclosure for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core purpose in the first sentence, then packs behavioral details into a second sentence. Every phrase earns its place, though the density might make it slightly harder to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no schema descriptions, the description provides a solid baseline: purpose, backup behavior, and a safety constraint. Still, it omits the meaning of 'occurrence' and duplicate-name handling, which an agent would need to confidently invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 parameter meaning. It explains the backup parameter's rotation behavior and hints at anchor_text, but it never describes 'occurrence' (a non-obvious integer) or the exact format of 'file_path'. This leaves significant semantic gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Bookmark') and resource ('a text range'), and clarifies its intended role as the target for add_cross_reference. This distinguishes it from the many other bookkeeping and reference tools among the siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The parenthetical '(the target add_cross_reference points at)' implies when this tool is relevant, but there is no explicit when-to-use guidance or mention of alternatives such as list_bookmarks or add_cross_reference. Usage context is clear enough to infer, but not fully stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It discloses auto-backup behavior, the effect of backup=False, atomic validated save, and the refusal to operate on documents open in Word. These are meaningful behavioral traits that an agent would not otherwise know, though it does not explain behaviors around at_start, after_index, or update_on_open.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose, then defaults, then backup behavior, then a critical constraint. Each sentence carries distinct useful information and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite the presence of an output schema and a concise description, the tool has 7 parameters and no annotations. The description leaves key behaviors such as at_start, after_index, and update_on_open unexplained, which is a significant gap for correct invocation. While the output schema reduces the need to document return values, the invocation semantics are incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 lack of parameter documentation. It covers label ('Table | Figure | Equation'), the default title pattern, and backup semantics partially. However, it does not explain file_path, at_start, after_index, or update_on_open, leaving 4 of 7 parameters without meaningful guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Insert a List of Tables/Figures/Equations'. It further distinguishes itself by specifying that the list is 'built from add_caption SEQ entries', which sets it apart from related tools like add_caption or insert_toc. The label options are also enumerated, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'built from add_caption SEQ entries' implies that this tool is for after captions have been added, providing some usage context. However, there is no explicit statement of when to use this tool versus alternatives like insert_toc or add_caption, and no exclusions beyond refusing documents open in Word.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure, and it does this well: it reveals auto-backup behavior, that backup=False only skips rotation, that the save is atomic and validated, and that the tool refuses documents open in Word. It stops short of stating irreversible consequences beyond the backup mechanism, but the disclosed behaviors are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense clauses convey the core action, scoping, backup behavior, safety guarantees, and a hard failure condition without filler. The main verb and action are front-loaded, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 3-parameter schema and presence of an output schema, the description covers the essential execution context: scope, backup semantics, save guarantees, and an important file-lock refusal. It could mention what 'validated' means or compare to accept_revisions, but for this tool's complexity it is close to complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although schema description coverage is listed as 0%, the description actually adds meaning to the author and backup parameters: 'one author's only' maps to author, and 'backup=False skips rotation only' clarifies a subtle default behavior. file_path is not described, but its purpose is self-evident from the schema and required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Reject tracked changes.' It also scopes the operation to all revisions or one author's, which tells an agent exactly what the tool acts on. It does not explicitly name the sibling accept_revisions, so it misses the differentiation needed for a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to choose this tool over accept_revisions or revision_summary. The scope options ('all of them, or one author's only') imply usage, but there is no 'when not to use' or pointer to an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden and does well: it discloses auto-backup rotation semantics, atomic validated saves, and the hard refusal for documents open in Word. This goes beyond a simple 'adds a comment' and gives the agent meaningful behavioral expectations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences contain no filler: the core action, backup behavior, and critical document-open constraint are each stated. The structure front-loads the most important information and earns every sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema exists, so return-value details are not required, and the description covers backup and Word-open constraints well. However, it does not explain how anchor_text and occurrence interact or what constitutes a text range, leaving an agent to infer key invocation semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only explains backup=False semantics. 'anchor_text' and 'text range' are loosely connected, but 'occurrence', 'file_path', 'author', and 'text' are left entirely to parameter names. This is insufficient for a 6-parameter tool with required arguments.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a comment'), the resource ('a text range'), and the threading behavior ('threaded-comment infrastructure created as needed'). This distinguishes it from siblings like reply_to_comment, resolve_comment, and delete_comment, even without naming them explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternatives are given. The phrase 'threaded-comment infrastructure created as needed' implies use for adding new comments, and 'Refuses documents open in Word' is a useful constraint, but the agent is not told to prefer reply_to_comment for existing threads or when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the transparency burden and does a good job by disclosing the scope of the operation and the data categories returned: legacy fields with name/value/options, and content controls with tag/alias and placeholder state. It does not explicitly state 'read-only', but the verb 'list' and the output-focused wording make the non-mutating nature clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
One compact, well-organized sentence front-loads the core purpose and then efficiently enumerates the field categories and their attributes. Every clause 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a listing tool with one simple parameter: it states the full scope, the form field types covered, and that tables are included. The output schema is present, so return-value details are not the description's responsibility, though the undocumented file_path parameter is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single required parameter file_path with 0% description coverage, and the tool description never mentions this parameter. The parameter name is somewhat self-explanatory, but the description adds no explicit meaning about what kind of path is expected or how it should be supplied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description precisely identifies the resource: every fillable form field in the document, covering both legacy FORMTEXT/FORMCHECKBOX/FORMDROPDOWN fields and modern content controls, across body and tables. It lacks an explicit verb like 'lists' and does not name sibling alternatives, but the intended behavior is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a clear usage context: use this tool when you need all fillable form fields, including legacy and modern controls, in both the body and tables. It does not explicitly discuss when not to use it or name alternatives such as list_content_controls or list_fields.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden and does so well: it reveals the invisible XE field behavior, the `see` cross-reference behavior, automatic backup slots, atomic validated saving, and refusal to operate on documents open in Word. The backup rotation wording is slightly cryptic, so it is not a perfect 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states the core operation first, then the specialized `see` behavior, then safety and persistence details. Every sentence carries useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main operational behavior, the non-obvious backup mechanics, and an important environmental constraint (refuses open Word documents). However, with 9 parameters, no schema descriptions, and no annotations, the missing parameter semantics for `occurrence`, `subentry`, and page-number formatting leave meaningful gaps. The presence of an output schema reduces the need to document return values, but does not compensate for those parameter gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It clarifies `see` and partially clarifies `backup`, but leaves 7 parameters—such as `occurrence`, `subentry`, `bold_page`, `italic_page`, `entry`, and `anchor_text`—without semantic explanation. This is only partial compensation for the missing schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action—marking a location for the index—and identifies the concrete artifact created (an invisible XE field at the anchor). It also explains the `see` mode, which differentiates this from simply inserting raw fields and from sibling tools like `insert_index` or `add_cross_reference`.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied rather than explicit: the tool is for creating index entry markers, with `see` providing a cross-reference variant. It does not explicitly state when to prefer this over alternatives, nor does it describe exclusions or when not to use it, though the `see` and backup notes offer some contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does so well: it discloses auto-backup rotation in .ks4w-backups, the meaning of backup=False, atomic validated saving, and refusal when the document is open in Word. It leaves some side effects unspecified, but the most important ones are surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and front-loaded with the core purpose, then packs caveats into three tight clauses without filler. The telegraphic style costs a little readability but earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For an 8-parameter mutation tool with no annotations, the description covers core behavior and the most safety-relevant details. It is less complete on parameter semantics and alternative selection, though the presence of an output schema means return-value documentation is not the gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds real semantics for restart (allowed values), remove (clears line numbering), and backup (skips rotation only), but leaves start, count_by, distance_pt, and section largely to inference from their names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Set manuscript line numbering') plus the domain context ('journal submissions') and section granularity. It is clear and distinct from sibling page-numbering/formatting tools, though it does not explicitly name a contrasting alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool applies (manuscript/section line numbering in journal submissions) and documents the remove=True clearing mode. It does not state explicit exclusions or name alternatives, but the use case is sufficiently scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It discloses auto-backup behavior, the precise effect of backup=False, atomic validated saving, and the Word-open refusal. These are substantive side-effect details beyond what the schema alone conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences, with the primary purpose front-loaded and backup/locking caveats efficiently appended. There is some dense jargon like 'prev/anchor slots' and 'atomic validated save', but every sentence adds relevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, format examples, backup behavior, and the Word lock refusal, but it leaves open how this relates to add_page_numbers, whether existing page numbers are overwritten, and what the exact section indexing semantics are. Since an output schema exists, return-value documentation is not required, but the zero annotation coverage leaves some gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 number_format with concrete examples and hints at start_at via 'decimal restarting at 1', and it explains backup behavior. However, file_path and section semantics remain mostly implicit, and valid number_format values are not exhaustively defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: setting the page-number format per section. It enumerates concrete format examples (lowerRoman, decimal, upperRoman, letters), which makes the tool's purpose immediately distinguishable from siblings like add_page_numbers or set_section_properties.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys that this operates per section and includes a useful caveat about refusing documents open in Word, but it does not explicitly state when to choose this tool over alternatives such as add_page_numbers or set_section_properties. There is no direct when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and handles it well: it explicitly says the tool is read-only, flags its heuristic nature, and clarifies that results are review candidates rather than definitive verdicts. This is substantial transparency, though it does not discuss edge cases or failure behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences front-load the main action, then cover the two checking directions, the heuristic caveat, and the read-only safety property. There is no filler and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is largely complete for a single-parameter, read-only, heuristic checker with an output schema: it covers purpose, scope, severity, and safety. It would be more complete with explicit parameter guidance and clearer placement among the many citation-related sibling tools.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the single file_path parameter or its expected format. The parameter name is self-explanatory at a basic level, but the description adds no semantic detail beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Cross-check') and a specific resource (APA in-text citations vs. the reference list), and it defines the two directions checked. This clearly differentiates it from generic validation tools like validate_document or validate_cross_references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool should be used for APA citation/reference-list parity checking and sets expectations that results are review candidates, not verdicts. However, it names no alternatives and gives no explicit guidance on when not to use it, so sibling differentiation is left mostly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It explicitly states that the tool is read-only, opens an invisible Word instance, requires Word installed, and warns that proper nouns/technical terms appear as spelling errors. This goes beyond basic purpose.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short sentences with no filler. It front-loads the return content, then adds use context, caveat, and runtime requirements in natural order.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return structure, and the description adds necessary prerequisites, side-effect behavior, and a practical caveat. It could be more explicit about limit semantics or expected file types, but overall it gives enough context for a read-only proofing tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain file_path or limit. The parameter names are somewhat self-explanatory, but the description fails to clarify what file_path refers to or how limit affects the returned errors, so it does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states that the tool returns Word's spelling and grammar error lists with surrounding context, including error type, sentence, and suggested corrections. This distinguishes it from sibling tools like word_count, get_text, or validate_document by specifying the exact proofing output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It identifies a concrete use case: a review aid before submission. However, it does not explicitly contrast itself with alternatives like validate_document or com_readability_statistics, so when not to use it is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden, and it delivers: it discloses that textbox matches are labeled separately, do not affect body indices, live mode returns the same flat-list shape, adds in_sdt entries, and caps at 500 matches with a truncated sentinel. This is unusually detailed and goes well beyond generic search-tool language.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The core purpose is front-loaded in the first sentence, and the subsequent details about textboxes and live mode are all behaviorally relevant. The sentence structure is dense but not bloated; no filler or repeated schema information appears.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so detailed return-shape documentation is not required. The description covers search scope, result labeling, mode differences, and truncation behavior. The main gap is parameter semantics for regex and context_chars, but overall the description is sufficiently complete for a search tool with a clear schema and defaults.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 include_textboxes thoroughly and describes the live-mode behavior, but it does not explain query, regex semantics, context_chars units/effect, or file_path handling. Two of six parameters are meaningfully annotated; the rest are left to inference from names and types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Find text in paragraphs and table cells; returns locations + context.' This clearly states the tool's function. It does not explicitly contrast with sibling search tools like find_formatted or search_and_replace, but the scope and output focus are concrete enough to avoid major ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when behavior changes: include_textboxes is 'file-mode only,' and documents open in Word are searched live with a different match set and a 500-match cap. It does not explicitly state when to prefer this over alternatives like search_and_replace, but the mode-specific guidance is actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does well: it discloses auto-backup behavior with '.ks4w-backups', clarifies that backup=False only skips rotation, mentions atomic validated save, and warns about Word-open refusals. It does not describe the output/return shape, but an output schema exists, so that gap is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense: purpose first, then target/formatting syntax, then backup and behavioral caveats. Every sentence adds operational value, and there is no repetition of schema fields beyond what is necessary for clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with nested parameters, no annotations, and 0% schema description coverage, the description covers the essential calling semantics: target selection, formatting attributes, backup behavior, and an important failure condition. It lacks explicit usage routing to sibling tools, but the core information needed to invoke it correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 meaningfully explains targets with '[{row, cell?}]' and the special whole-row shorthand, lists the formatting object's keys, and clarifies the backup parameter's semantics. file_path and table_index are left to their names, but those are self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening phrase 'Format table cells in bulk' states a specific verb and resource, and the enumerated formatting fields (shading, bold, italic, alignment, etc.) make the operation concrete. It does not explicitly name a differentiating sibling, but 'bulk' and 'formatting' clearly separate it from value-setting tools like set_cells or set_cells_block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for bulk cell formatting and gives a hard constraint with 'Refuses documents open in Word.' However, it never explicitly says when to prefer this tool over alternatives like set_cells_block or apply_table_style, nor does it state when not to use it beyond the Word-open refusal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It explicitly closes the mutation question with 'Read-only,' discloses the live-read behavior for documents open in Word, and reveals the flat-list output shape and detected_via field on entries.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with the core action front-loaded and technical detection details in the follow-up. Every sentence earns its place, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter list tool with an output schema, the description covers the behavior, both heading systems, output shape, live behavior, and read-only safety. It is slightly incomplete on parameter semantics and usage route, but the output schema absorbs the return-value burden.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the required file_path or the live parameter and its 'auto' default. The phrase 'Documents open in Word are read live' is the only indirect hint about live behavior, leaving the main parameter semantics mostly unaddressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Opens with 'List every heading with its body paragraph index and level' – a specific verb, resource, and output detail. It further distinguishes itself from sibling tools by explicitly covering both Heading styles and w:outlineLvl overrides, making its role as an outline-extraction tool clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies outline extraction but gives no explicit when-to-use guidance, exclusions, or alternatives. An agent is not told when to prefer get_outline over related tools like get_text, get_styles, or get_headers_footers.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and handles it well. It discloses auto-backup with prev/anchor slots, the precise meaning of backup=False, atomic validated saving, refusal of documents open in Word, and the graceful [DEFINITION NEEDED] fallback. This goes well beyond what the schema or annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the main purpose, and every clause adds useful information: detection source, format, fallback behavior, placement, backup, save semantics, and a refusal condition. It is dense but not padded; the semicolon-heavy single paragraph is still easily scanable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core behavior, edge cases, placement, backup, and document-open refusal are well covered, and an output schema exists to fill return-value details. However, key parameters such as heading_level and definition_patterns remain undocumented, and the relationship to check_defined_terms could be more explicit for a fully self-contained definition.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 backup semantics and placement related to at_end/after_index, but it leaves heading, heading_level, and definition_patterns semantically unexplained. For a 7-parameter tool, this is only partial compensation for a schema with no parameter descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Build a glossary section from the document's defined terms.' It also distinguishes itself from the sibling check_defined_terms by referencing 'same detection as check_defined_terms' while describing a distinct output artifact. The expected structure is detailed: heading, alphabetized paragraphs, bold terms, and harvested definitions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides useful context such as placement options and the Word-open refusal, and it references check_defined_terms as the detection sibling. However, it never explicitly says when to use this tool versus check_defined_terms or other insertion tools, so the usage boundary is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, this description carries the behavioral burden and does substantial work: it discloses the document regions scanned, the attributes returned, coverage of complex and simple fields, and flagging of unclosed fields. It stops short of explicitly stating the operation is read-only, though 'current cached result text' strongly implies no mutation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the tool's purpose in the first clause. The colon-separated attribute list and final completeness statement carry dense, relevant information without wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the full field enumeration scope, field types, cached result text, location information, and edge-case handling, while the output schema can cover return formatting. A brief explicit read-only statement would make it fully complete, but it is already sufficient for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description adds no meaning to the file_path parameter. The parameter is a simple, conventional path, so this is not a severe gap, but the description does not compensate for the schema's lack of any property description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description immediately states the exact scope — every field in body, headers, footers, footnotes, and endnotes — and enumerates the returned attributes. This makes it clearly distinct from field-related siblings like insert_field and com_refresh_fields.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a listing/inspection use case by specifying coverage and the fact that unclosed fields are flagged, but it never explicitly says when to choose this over alternatives or when not to use it. Context is present, but exclusions and alternatives are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It goes beyond the basics by revealing that the tool refuses before writing anything on collisions, duplicate names, or missing required values, and that the template is never modified. These are meaningful safety guarantees.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, well-organized, and front-loaded with the core behavior. Every sentence adds value, covering input formats, filename syntax, failure handling, and template safety without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex tool with no annotations and 0% schema coverage, the description provides enough to select and invoke it correctly: inputs, outputs, filename syntax, and failure modes are covered. Small gaps remain around path semantics, missing parameter options beyond 'error', and output return details, though the presence of an output schema reduces the need for the last.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It does well for data_rows and filename_pattern, including supported input formats and placeholder syntax. However, template_path and output_dir are only implied by context, and the missing parameter's full value set is not explained beyond the default error case.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation: generate one filled .docx per data row into output_dir. It clearly communicates the core resource and output, but it does not explicitly compare itself to siblings like fill_template or batch_apply, so differentiation is implicit rather than stated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful parameter-level guidance for data_rows and filename_pattern, but it provides no explicit guidance about when to choose mail_merge over alternatives such as fill_template or batch_apply. There are no when-to-use 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses auto-backup behavior, the effect of backup=False, atomic validated saving, and refusal to operate on documents open in Word. Some details like 'prev/anchor slots' and 'rotation only' remain somewhat cryptic, but the key behavioral traits are surfaced.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loads the core action. The backup and refusal clauses are dense and information-rich, though the phrasing is occasionally jargon-heavy and might confuse an agent about what 'rotation only' means.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main operation, backup behavior, and a key precondition (document not open in Word). However, with no annotations and no parameter-level guidance, an agent still has to infer important semantics for image_index and new_image_path, making the definition not fully complete for a mutation tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 all four parameters. It only meaningfully explains backup behavior; file_path, image_index, and new_image_path are left to name inference and are not defined or contextualized beyond the phrase 'Swap an image's file.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: swapping an image's file while preserving placement and display size. This clearly differentiates it from siblings like resize_image, add_image, and extract_images, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended context clear: replace an existing image's underlying file without changing its layout. It does not explicitly name alternatives or exclusion criteria, but the contrast with resize_image and add_image is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It explicitly states 'Read-only,' documents how footnote/endnote revisions are categorized, and specifies the inclusion of the 10 heaviest body paragraphs by revision churn. This adds meaningful behavioral context beyond the bare operation name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a dense, information-rich paragraph with no filler or redundant phrases. Every clause adds either a metric, a scoping detail, or a behavioral qualifier, and the most important outcome—per-author analytics—is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return-value documentation is already covered. The description contributes the input context, metric breakdown, footnote/endnote aggregation rule, and read-only nature. It would be more complete with an explicit note about when to prefer this over revision_summary or get_tracked_changes, but it is sufficiently complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only a bare file_path string with 0% schema description coverage, and the description does not explain the parameter's meaning, expected format, or constraints. While file_path is a relatively self-evident name, the description adds no semantic value for this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies a specific analytical deliverable—tracked-change analytics per author—and enumerates concrete metrics such as insertion/deletion counts, word additions/removals, move/format change counts, and heading-path breakdowns. This clearly differentiates it from sibling tools like get_tracked_changes and revision_summary without requiring the agent to open their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The use case is implied: an agent should call this when it needs aggregated per-author churn analytics rather than raw tracked-change lists. However, there are no explicit when-to-use or when-not-to-use statements, nor any named alternative tools or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing auto-backup behavior, the effect of backup=False, atomic validated saving, and refusal to operate on documents open in Word. It does not detail return values or error behavior, but the output schema covers return structure and the mutation/safety profile is reasonably clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: purpose first, then placement/label options, then backup and safety behavior. Every sentence contributes useful information without fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the 7-parameter schema with 0% parameter-level descriptions and no annotations, the description covers the main behavioral context: what a caption is, where it can be placed, label options, backup semantics, and Word-open refusal. The main gap is that the selection between table_index and after_anchor is not made explicit, which could lead to incorrect invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 for label ('Table | Figure | Equation'), above/below placement, backup behavior, and the anchor concept. However, it leaves key parameters like file_path, table_index, and the relationship between table_index and after_anchor only vaguely implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Insert') and resource ('numbered caption (SEQ field)') and gives the exact format 'Table N: text'. It also specifies placement contexts (above/below a table or at an anchor), which clearly distinguishes this single-caption tool from sibling tools like insert_caption_list or add_cross_reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when inserting a single caption for a table, figure, or equation, placed above/below a table or at an anchor. However, it does not explicitly state when not to use it or name alternatives such as insert_caption_list for bulk caption insertion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses important behaviors: auto-backup to .ks4w-backups with rotation control (backup=False skips rotation only), atomic validated save, and refusal to operate on documents open in Word. This goes beyond typical descriptions, though it does not mention potential side effects on existing section formatting or error handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action, then moves to backup and atomic-save details, and ends with the key constraint. Every sentence adds value and there is no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and annotations are absent, the description covers the essential operational details: the action, allowed types, backup behavior, and a critical constraint. It does not explain edge cases (e.g., invalid index, invalid break_type), but these are likely handled by the output schema or validation errors. The description is sufficient for an agent to decide when and how to invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 break_type by listing valid values and clarifies backup rotation behavior, but it does not describe after_index (which is implied by 'after a body paragraph') or file_path (standard for file tools). The description partially bridges the coverage gap but not completely.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 section break'), and its placement ('after a body paragraph'). It also enumerates the allowed types (nextPage | continuous | evenPage | oddPage), making the purpose unmistakable and distinguishing it from sibling tools like add_page_break, which handles page breaks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it (to insert a section break after a paragraph) and provides a key usage condition ('Refuses documents open in Word'), but it does not explicitly contrast with alternatives such as add_page_break, move_section, or set_section_properties. The usage context is implied rather than explicitly stated with exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly: it discloses that missing style definitions are injected, that auto-backup uses .ks4w-backups slots, that backup=False only skips rotation, and that saves are atomic and validated. It also surfaces the refusal of documents open in Word, a critical failure condition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences cover purpose, style values, backup behavior, save guarantees, and a refusal condition without filler. The main verb and allowed styles are front-loaded, and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is behaviorally rich and return values are covered by the output schema, but it is not fully complete because several input parameters are semantically unexplained and no alternative-selection guidance is provided. Still, the core workflow and safety-critical behaviors are clearly conveyed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the prose must compensate, but it only clarifies the style values and the backup flag. file_path, table_index, banded_rows, and first_row_header get no semantic explanation, such as indexing basis or header-row behavior, leaving the agent to guess from parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Apply a named table style') and enumerates the exact accepted values (TableGrid, PlainTable, BandedTable) with parenthetical meanings. The table-style scope distinguishes it from generic siblings like apply_style or format_cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for the intended operation and notes a hard precondition: it refuses documents open in Word. However, it does not explicitly contrast this tool with alternatives such as format_cells, set_cells, or apply_style, so the agent must infer the right choice from the 'table style' framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and discloses key behaviors: it uses Word's own engine, requires Word installed, opens an invisible instance, and is read-only. This gives an agent a solid model of side effects and prerequisites.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: it states what the tool produces, the main prerequisite, and the behavior. Every sentence adds useful information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so return-value documentation is not needed. However, the description omits an explanation of the file_path parameter and does not discuss when to prefer this tool over word_count or com_word_status, leaving moderate gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only file_path with no description and 0% schema coverage, so the description needed to define acceptable path values or constraints. It does not mention file_path at all, leaving the sole parameter under-specified beyond its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool as computing Word's own readability statistics via COM and enumerates the specific outputs (Flesch Reading Ease, Flesch-Kincaid Grade Level, word/sentence/paragraph counts, averages). This distinguishes it from related tools like word_count or get_document_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context by requiring Word to be installed and noting that an invisible Word instance is opened. It does not explicitly name alternatives or when-not-to-use, but the conditions for use are clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden of behavioral disclosure. It states that the source file is modified in place, the operation uses an invisible Word instance, requires Word to be installed, and produces corrected values immediately. This is strong behavioral context, though it does not mention potential side effects like file locking or failure modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action and scope. It includes useful context about when to use it and prerequisites like Word installation, though some phrasing could be tightened without losing information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and an output schema, the description covers the main operational context: what it updates, when it is needed, that it modifies the source file, and that Word is required. It is missing explicit details about file_path semantics, but overall it is complete enough for most agent workflows.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate for the undocumented file_path parameter. It does not explicitly define that file_path is the path to the Word document or state any format/access expectations. The meaning is inferable from the tool name and context, but for a single required parameter the lack of explicit guidance is a notable gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Update every field in the document') and lists concrete field types it affects, such as TOC page numbers, PAGEREF, NUMPAGES, and cross-references. It distinguishes itself by naming the context after insert_toc/insert_index/insert_caption_list operations, which helps differentiate it from generic field tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says when to use the tool: after inserting TOCs, indexes, or caption lists, and after any edit that shifts pages. It does not mention alternatives or exclusions, but the stated use cases are sufficiently clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description takes on the full behavioral disclosure burden. It discloses auto-backup behavior, backup=False semantics, atomic validated save, and refusal to operate on documents open in Word. These are meaningful side-effect and failure-mode details beyond what the schema shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no filler. It front-loads the core purpose, then provides the key alternative, then adds safety and side-effect context. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers safety, backup behavior, and the import alternative, but it leaves several insertion and formatting parameters unexplained. Because there is no annotation coverage and only 0% schema description coverage, the description is not fully sufficient for an agent to confidently choose and invoke all parameter combinations correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameter meaning. It clarifies that data is '2D string data' and gives backup rotation semantics, but it leaves at_end, after_index, after_anchor, header_row, width_pt, and file_path largely to inference. This is a significant gap for an 8-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Create a table from 2D string data with single-line borders.' It also differentiates from the sibling import_table by pointing out that CSV/JSON imports should use that tool instead. This makes the intended purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit alternative: 'To build a table from a CSV/JSON file, use import_table.' This tells the agent when not to use create_table for file-based data. It does not discuss broader placement or styling alternatives, but the main competing case is clearly addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well. It discloses the backup mechanism and location ('prev/anchor slots in .ks4w-backups'), the effect of backup=False ('skips rotation only'), the atomic validated save, and the refusal to operate on documents open in Word. This goes well beyond a generic deletion statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, with no wasted words. The first sentence states the core action, and the second sentence packs important safety and backup behavior into an efficient block. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the operation, backup behavior, and a refusal condition, but it omits the essential parameter selection logic between note_id and position. Given that the schema has 0% description coverage and this is a destructive mutation with several siblings, the definition is not fully complete for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 missing parameter explanations. It only clarifies the backup parameter ('backup=False skips rotation only') but gives no guidance on note_id versus position, how they relate, or which to supply. An agent cannot confidently choose the correct parameter without additional inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete an endnote.' It further clarifies scope by specifying 'the definition AND the body reference mark,' distinguishing this from deleting just one component. This also separates it from sibling tools like delete_footnote and edit_endnote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use (deleting an endnote) and provides an important operational exclusion: 'Refuses documents open in Word.' However, it does not explicitly name alternatives or state when to prefer this tool over related ones such as convert_notes or validate_notes. Usage context is inferred rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses the always-both deletion behavior, the backup mechanism and backup=False semantics, atomic validated saving, and that the tool refuses documents open in Word. This is rich behavioral context beyond what the schema provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, each earning its place: scope first, then backup behavior, then a failure condition. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers behavior, backup, and failure conditions well, and an output schema exists for return values. However, the central targeting parameters (note_id, position) are left unexplained, so an agent may not know how to identify which footnote to delete without extra inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only explains the backup parameter ('backup=False skips rotation only'). It does not explain how note_id and position select a footnote, whether they are alternatives, or what happens if both are provided. This is a significant gap for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description states a specific verb and resource ('Delete a footnote') and defines exactly what is removed: 'the definition AND the body reference mark, always both.' This scope clearly distinguishes it from partial-deletion or cleanup siblings such as cleanup_orphan_notes and delete_endnote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes it clear that this tool fully removes a footnote, so usage is implied. However, it does not explicitly name alternatives or state when not to use it, such as when only an orphaned definition should be removed or when an endnote should be deleted instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 does this well by listing the returned fields (tag, alias, type, current value, lock state, placeholder flag, block/inline) and clarifying that the tool targets only the document body. It reasonably implies a read-only listing behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but purposeful, front-loading scope and then adding useful detail about output fields and index addressing. The second sentence about the index being the handle for set_content_control_value earns its place, though the long enumeration of types makes it slightly heavier than necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists and the single parameter is simple, the description covers the essential context: scope, available fields, and how the index relates to another tool. It does not discuss errors or empty documents, but those are minor omissions for a listing tool with this clarity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not compensate by explaining the file_path parameter at all. The parameter name is self-explanatory, and there is only one parameter, so this is a minor gap, but the description still adds no semantic value for the input parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the tool's scope precisely: it enumerates every content control (SDT) in the document body, including types and fields. It also distinguishes itself from fill_form_fields by explicitly noting the types that fill_form_fields skips, making the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on when this tool is useful: when you need the full set of content controls beyond what fill_form_fields covers, and when the returned index should be used as the handle for set_content_control_value if tags are missing or duplicated. It does not explicitly state when not to use it, but the routing guidance is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden. It goes beyond a simple verb by explaining that the change is persistent, returns the previous state for later restoration, and requires an open Word document. It does not cover error behavior when no document matches file_path, but the disclosed behaviors are substantive and non-obvious.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with the action front-loaded, followed by the persistence contrast, return value, and prerequisite. Every sentence adds distinct value with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the action, persistence, return value, and prerequisite, which is solid for a simple toggle tool. However, because both parameters are undocumented in the schema and the description leaves `file_path` semantics implicit, an agent may struggle to invoke the tool correctly. Error handling for a missing open document is also unstated, so the description is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining both parameters. 'On or off' indirectly maps to the boolean `enabled`, but `file_path` is never mentioned by name, nor is its format or role in targeting the open document explained. Since file_path is required, this is a meaningful gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Turn') and a clear resource ('track changes on or off') scoped to the open document. It also differentiates itself from sibling edit tools like search_and_replace by noting that this is a persistent state change, so an agent can distinguish it from similar track-related flags.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly contrasts this tool with the auto-restoring track flag on edit tools like search_and_replace, giving a clear exclusion condition. It also states the important prerequisite that the document must be open in Word. It does not list all alternative contexts (e.g., inspecting tracked changes), but the key when-not guidance is present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden and does well: it discloses auto-backup into prev/anchor slots in .ks4w-backups, notes that backup=False skips rotation only, promises atomic validated save, and states refusal for documents open in Word. This provides concrete side-effect knowledge beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The main purpose is front-loaded in the first sentence, and the backup/refusal details are packed into a compact, information-dense paragraph with no filler. Every clause adds operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating tool with no annotations, the description covers the main behavior, backup/recovery, validated saving, and the Word-lock precondition. It relies on the output schema for return values and leaves some parameter semantics and alternative routing unstated, but is otherwise strong.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does explain widths_pt (explicit per-column widths vs equal), separator (draws a line), and backup (False skips rotation only), but count, section, space_pt, and file_path receive no explicit semantics. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 multi-column text layout for a section," and immediately differentiates the scope from table-column operations by mentioning section-level layout, equal widths, widths_pt, and separator lines. This is clearly distinct from sibling tools like set_column_widths or insert_columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description scopes usage to section multi-column layout and warns that documents open in Word are refused, which gives some context. However, it never names alternatives or states when set_columns should be preferred over similar section/column tools, so routing guidance 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.
- Behavior4/5
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 discloses auto-backup mechanics, the backup=False nuance ('skips rotation only'), atomic validated save, and the Word-open refusal condition. This is substantial beyond the bare operation, though permission requirements and post-failure state are not covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three terse sentences: purpose first, then backup/save semantics, then a clear failure condition. Every sentence earns its place, there is zero filler, and the most actionable information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given this is a mutation tool with no annotations but an output schema, the description covers purpose, units, backup behavior, and a key refusal condition. It stops short of explaining table_index indexing or width validation constraints, but a competent agent would likely invoke it correctly with the provided information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 widths_pt by giving the unit (points) and the requirement of one value per grid column, and it adds backup behavior details. However, file_path and table_index are only named in the schema without explanation of indexing base or document scope, leaving moderate gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pair: 'Set every grid column width in points.' This distinguishes it from sibling tools like set_columns (page columns) and set_cells_block (cell content/formatting). The phrase 'one value per grid column' further defines the exact operation scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied clearly—set grid column widths—but there is no explicit guidance about when to prefer this tool over alternatives like set_columns, format_cells, or apply_table_style. The refusal condition ('Refuses documents open in Word') provides operational context but does not serve as alternative-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: it discloses the auto-backup rotation mechanism, the effect of backup=False, atomic validated saving, and refusal to modify documents open in Word. This goes well beyond the tool name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences convey purpose, options, and safety behavior with no filler. The main action is front-loaded, and every sentence adds information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers critical behavioral context and the presence of an output schema reduces the need to describe return values. However, given 7 parameters with 0% schema coverage, the lack of guidance on ref_type and alignment leaves a meaningful gap for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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, but it only clarifies backup and include_page_number. file_path and text are name-implied, while section, ref_type, and alignment remain semantically opaque, especially ref_type, which has no enum or further explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Set a section's footer text', and it calls out the optional page-number field. This clearly distinguishes it from sibling set_header and add_page_numbers by naming footer and page-number behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by 'Set a section's footer text', but there is no explicit when-to-use guidance or mention of alternatives such as set_header, add_page_numbers, or get_headers_footers. An agent is left to infer when this tool is preferred over those siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses auto-backup with prev/anchor slots, backup=False semantics, atomic validated save, and refusal when the document is open in Word. It does not clarify whether setting on=false removes an existing repeated header or how it interacts with existing table formatting, but the disclosed side effects are strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the core purpose front-loaded, followed by dense behavioral guarantees. No filler or repetition; every clause adds operational information the schema does not provide.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and no annotations are present, the description is unusually complete: main behavior, backup side effects, save safety, and a refusal condition are all covered. It still leaves minor gaps around toggle semantics and table-indexing conventions, but nothing that makes the tool uncallable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 rows via 'first N rows' and backup via 'backup=False skips rotation only', but leaves on, file_path, and table_index semantically unexplained, including whether the index is zero-based or the effect of on=false.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a precise operation: repeat the first N rows of a table as the header on every page. This clearly distinguishes it from page-header tools like set_header and from other table-manipulation siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied by the first sentence, but no explicit when-to-use or when-not-to-use guidance is given, and no alternative sibling is named. The only exclusion is the operational constraint about documents open in Word, which is a precondition, not a usage alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It discloses auto-backup behavior across prev/anchor slots, the effect of backup=False, atomic validated saving, and refusal to operate on documents open in Word. This is strong behavioral context, though it could say more about overwriting existing alt text or restoring backups.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose in the first sentence. The additional behavioral notes are terse and information-dense, with no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and only 0% schema coverage, the description covers the essential invocation path, side effects, and a critical refusal condition. The main gaps are unaddressed parameter semantics and lack of explicit alternative routing, but an agent can still call the tool correctly with what is provided.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 source of image_index and the meaning of backup, but file_path, description, and especially the optional title parameter receive no explicit semantic clarification. Some parameters are self-evident, but not all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Set accessibility alt text for an image') and identifies the resource via 'image_index from list_images'. This clearly distinguishes it from image manipulation siblings like add_image, replace_image, resize_image, and extract_images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides a useful pointer that image_index comes from list_images, implying a prerequisite call. However, it does not explicitly say when to use this tool versus alternatives such as audit_accessibility or fix_accessibility, nor does it mention any exclusions beyond refusing documents open in Word.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses auto-backup behavior, the nuance that backup=False only skips rotation, atomic validated saving, and refusal to work on documents open in Word. These details materially affect whether and how an agent should call the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences: the first states the core action, and the second packs the critical behavioral caveats. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers safety and save behavior well, and an output schema exists, so return values are not a major gap. However, with 5 parameters, no annotations, and zero property descriptions, the lack of coordinate/parameter context leaves the agent with meaningful assumptions about 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.
Parameters2/5Does 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 only clarifies the backup parameter; file_path, table_index, row, and cell receive no guidance about coordinate basis, zero-indexing, or how they relate to the merged cell.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Split a merged cell back into single cells (horizontal and vertical).' This clearly states the tool's operation and makes the inverse relationship to the sibling merge_cells evident even without naming it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is implied: apply this when a merged cell needs to be split. However, there is no explicit when-to-use versus alternatives, no exclusions beyond the Word-open refusal, and no mention of the opposite merge_cells operation or related table-level tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden, and it does so well: it discloses auto-backup behavior, atomic validated save, refusal of documents open in Word, and that contested elements are itemized in not_applied. Minor ambiguities like the meaning of 'flagged' and the 'All three' count prevent a perfect score.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient, front-loading the purpose before diving into style specifics, exclusions, and operational details. It could be better structured with bullets, and the 'All three' inconsistency slightly mars readability, but every sentence contributes substantive information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool, the description is quite complete: it covers supported styles, style-specific formatting rules, refusal conditions, backup behavior, and save guarantees. Since an output schema exists, return values don't need description. Remaining gaps such as the meaning of 'flagged' and how the reference list is found keep it from a 5.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 rich meaning for 'style' and useful context for 'running_head' and 'author_last_name', but 'backup=False skips rotation only' is ambiguous about whether backup is disabled entirely, and 'file_path' is never mentioned. The compensation is partial, not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Apply a style's page-level manuscript conventions,' and then enumerates exactly which styles are supported (apa7, apa7-professional, mla9, chicago17). This clearly distinguishes it from generic tools like apply_style or apply_template, which do not target page-level manuscript conventions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-not conditions: it refuses IEEE/Vancouver/ASA/Harvard formats and states that contested items are not applied. However, it does not name alternative tools for cases where this tool should not be used (e.g., apply_style, set_paragraph_format), so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the default save behavior, the effect of save=False, the file-lock release, and the Word prerequisite, giving the agent a solid model of side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and every sentence adds useful information. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core behavior, default side effect, usage context, and prerequisite. It lacks explicit guidance on error cases such as the document not being open or how file_path resolves to the target document, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate for both parameters. It explains the save parameter clearly, but file_path—the only required parameter—is never semantically defined, leaving ambiguity about how the target document is identified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action with a clear resource: tell the running Word instance to close an open document. It also identifies the purpose of releasing the file lock, which differentiates it from live-editing tools and file-mode operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit use case: switch from live editing to file-mode tools. It does not name alternative tools like com_save_open_document, nor does it state when not to use it, so it stops short of full alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden, and it discloses the key operation: opening the file in an invisible Word instance and reporting clean/fail. It also signals isolation and read-oriented validation via 'invisible Word instance' and 'definitive corruption check'. It does not mention prerequisites like Word/COM availability or possible error conditions, but the core behavior 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The primary behavior is front-loaded in the first sentence, and the second sentence adds valuable sibling context without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a low-complexity tool with one parameter and an output schema, so the description does not need to explain return values. It provides the essential operation, the isolated execution model, and the relationship to closely related validators. It is slightly incomplete only in not giving explicit conditionals for choosing this over validate_document or diagnose_document.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not meaningfully document the file_path parameter beyond saying 'open the file.' It does not explain expected path format, whether the file must already exist, or what file types are supported. The parameter name is somewhat self-explanatory, but the description fails to compensate for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Run the definitive corruption check'), a concrete resource ('open the file in an invisible Word instance'), and an explicit outcome ('report clean/fail'). It also distinguishes itself from closely related siblings by calling itself the 'Word-verdict companion to validate_document / diagnose_document', so an agent can tell it apart from those alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this tool is relevant: it is the Word-based or 'definitive' corruption check, positioned as a companion to validate_document and diagnose_document. It does not spell out explicit exclusion criteria or a precise decision tree, but naming the sibling tools and labeling this one as the 'Word verdict' is enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral disclosure burden. It covers destructive scope, backup behavior, atomic validated saving, the effect of backup=False, and a hard operational refusal, which is unusually rich 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences with no filler. The primary action is front-loaded, and the caveats are organized into a compact second sentence, each clause adding meaningful behavioral information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the destructive behavior, backup mechanics, and a blocking condition, while the presence of an output schema reduces the need to explain return values. The main gap is undocumented required parameters and the lack of explicit alternative routing, but overall it is nearly complete for a moderately complex delete operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must document parameters, but it only explains backup semantics. file_path and comment_id receive no guidance about their format, source, or relationship to get_comments, leaving agents to infer their meaning from parameter names alone.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Delete a comment and its replies, including all body markers.' This precisely distinguishes it from comment-management siblings like resolve_comment, add_comment, and reply_to_comment by emphasizing full recursive removal.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The core use case is implied clearly by 'Delete a comment and its replies,' and the refusal to operate on documents open in Word is a useful when-not condition. However, it does not explicitly name alternatives or state when a sibling like resolve_comment should be chosen instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavior disclosure. It explicitly states 'Read-only' and precisely describes the live-mode variant: same key names, added 'words' and track_revisions, omitted part list. This gives an agent a clear model of what will happen without surprises.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no fluff. The main purpose and scope are front-loaded, and the parenthetical second sentence earns its place by explaining the critical live-mode behavior. Nothing repeats the schema or annotations.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return values, so the description's lack of output detail is acceptable. It covers purpose, read-only safety, and live-mode differences. The main gaps are explicit usage routing and the live parameter's allowed values, so it is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 effect of live mode but does not clarify what values the live string parameter accepts or what 'auto' means. file_path is self-evident from its name, but the core live parameter's semantics are only partially covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and names a precise resource: a one-call document overview with enumerated elements (paragraph/table/footnote/comment/revision counts, sections, package parts). This clearly distinguishes it from single-purpose siblings like word_count, get_outline, or list_tables. 'Read-only' further reinforces intent.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'one-call document overview' implies use when an aggregate summary is needed rather than a specific detail, but the description does not explicitly state when not to use it or name alternative tools. With a large sibling list, routing is left partly to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It explicitly says 'Read-only' and discloses that internal bookmarks are excluded, which is useful context beyond the schema. It does not mention errors or path requirements, but the read-only and exclusion disclosures are strong for a simple listing tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three tight sentences with no wasted words. It front-loads the core behavior, then adds purpose and a key exclusion, and ends with a clear read-only note. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter list tool, the description is complete: it defines what is listed, what is excluded, the read-only nature, and the downstream use cases. The presence of an output schema means return-value details do not need to be repeated in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one required parameter, file_path, with no description coverage. The tool description does not explain file_path's format or semantics, so the description adds no parameter-level meaning. However, a single required string named file_path is fairly self-evident, making this adequate but not exemplary.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a clear verb-plus-resource: list every user-visible bookmark, with specific fields (name, paragraph index, bookmarked text). It also distinguishes user-visible bookmarks from internal/TOC/field-generated bookmarks, making the tool's scope precise and separating it from add_bookmark and add_cross_reference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by noting bookmarks serve as targets for add_cross_reference and anchors for navigation, but it does not explicitly say when to use list_bookmarks versus alternatives, nor does it state when not to use it. The guidance is present but indirect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 explicitly labels the operation 'Read-only' and reveals the output contract: list of tables with dimensions, merge flags, header previews, and stable indexes. It does not mention failure-mode behavior, but for a read-only list operation this is a solid disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences deliver the operation, the returned information, the positional contract, and the safety profile with no wasted words. Critical info is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single file_path parameter and the presence of an output schema, the description covers the essential call context: what is returned, how positions are used by siblings, and that it is read-only. It could add whether nested tables are included or how empty documents are handled, but those are minor gaps for a list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description had to compensate for the undocumented file_path parameter, but it does not mention file_path at all. The param name is self-explanatory in context, but no additional meaning is added; the table_index note concerns output/other tools, not this tool's input.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') with a clear resource ('tables') and names the concrete fields returned (dimensions, merge flags, header previews). This distinguishes it from single-table tools such as get_table and table-mutation tools in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
By stating that the returned position is the 0-based table_index other table tools consume, the description signals that this tool is the discovery/preflight step for table operations. It does not name alternative tools or explicit when-not-to-use conditions, but the intended usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral transparency burden. It usefully discloses the auto-backup mechanism, the effect of backup=False, atomic validated saving, and refusal to operate on documents open in Word. This goes well beyond a bare mutation warning, though it could also clarify reversibility or failure behavior more.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core action is first, followed by essential behavioral details and a key constraint. Every clause adds information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter tool with an output schema present, the description covers the action, scope, backup behavior, save semantics, and a critical operational constraint. No essential calling information appears to be missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 backup parameter's behavior ('backup=False skips rotation only'), but file_path semantics are left entirely to the parameter name. The open-in-Word refusal indirectly informs file_path usage, but the description still does not fully cover all parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Remove watermark shapes from every header.' This clearly distinguishes the tool from siblings like add_watermark or get_headers_footers by stating both the action and the scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the verb 'remove,' but there is no explicit guidance about when to choose this over alternatives, such as add_watermark or manage_backups. The 'Refuses documents open in Word' line provides a condition, but not a fuller when-to-use or when-not-to-use explanation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 adds substantial context: auto-backup behavior, the backup=False flag effect, atomic validated saving, and the refusal to operate on documents open in Word. It does not enumerate all failure modes, but it covers the most important behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately short and front-loaded with the core operation. The second and third sentences add real behavioral value without fluff. Some terminology like 'prev/anchor slots' is terse but acceptable given the tool's audience.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the moderate complexity and the presence of an output schema, the description covers the operation, row semantics, backup behavior, save behavior, and a key edge case. It could be more complete with explicit table_index and file_path conventions, but it gives enough context for an agent to invoke the tool correctly in most situations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explain at_row meaningfully and partially explains backup behavior, but it does not explicitly define file_path or table_index semantics, indexing conventions, or expected formats. The parameter names are fairly self-explanatory, but not every parameter receives added meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Split a table into two at a row.' It also clarifies the exact row semantics by stating that the specified row starts the new table. This clearly distinguishes it from sibling tools like split_document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly states the operation and gives a key usage constraint: it refuses documents open in Word, which tells the agent when the call will fail. It does not explicitly compare itself to alternatives like copy_table or split_document, but the table-specific wording provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 discloses non-mutating behaviors ('Check', 'report', 'flag'), the adjacency/SEQ requirement, and the specific numbering convention checks. It stops short of explicitly stating that the document is not modified, but the verbs strongly imply read-only validation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one dense but efficient compound sentence. Every clause adds a distinct requirement or output detail: caption adjacency, SEQ field, missing-caption reporting, and mixed numbering conventions. It is front-loaded with the main purpose and contains no filler, though it is slightly packed.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a validation tool with one parameter and an output schema present, the description covers the essential scope, missing-caption reporting, and numbering-flagging behavior. Terms like 'body-level' and 'adjacent' are somewhat implicit, but the output schema likely covers return details, and no critical calling requirement is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention file_path at all. However, the single parameter is an unambiguous string named file_path, and the tool's validation context makes its purpose clear enough for an agent to populate it correctly. Minimal but adequate for a single obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Check... report... flag') applied to a specific resource (captions for body-level tables and images). It clearly distinguishes this tool from siblings like add_caption and validate_document by naming the exact validation scope and the mixed-numbering detection behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: validating caption presence and numbering conventions. It does not explicitly name alternatives or exclusions, but the specificity of the scope makes the intended use inferable without ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses 'Read-only' and details the kinds of findings: broken refs, unreferenced bookmarks, and heuristic plain-text references. Explains the Word rendering consequence for broken refs and states paragraph indices are included, giving agents a full safety and output picture without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and organized as a lead action plus concise finding categories and a read-only note. Each clause adds operational value without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only validation tool with one parameter and an output schema, the description covers scope, finding categories, heuristic behavior, and output location. It is nearly complete, though it relies entirely on the schema for the only input parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only the name 'file_path' with 0% description coverage, and the tool description never mentions or elaborates on that parameter. There is no guidance about accepted path formats, file types, or how file_path is used, so the description does not compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a precise action: 'Check every REF/PAGEREF cross-reference against the bookmarks that actually exist.' It enumerates the finding categories, making it distinct from validation siblings like check_reference_field_integrity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Clear about what it validates but not explicit about when to choose it over sibling validation tools such as check_reference_field_integrity or validate_notes. No when-not/alternative guidance, so usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and explicitly states 'Read-only' plus the meaning of ok and needs_cleanup flags. It also names the follow-up remediation tool. It could add more about failure behavior, but for a read-only validation tool this is solid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, front-loaded with the core purpose, then output interpretation, then adjacent tools. Every sentence earns its place and there is no wasted wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, output semantics, read-only safety, and related tooling, which is sufficient for a single-parameter validation tool. A fuller treatment might state what ok=false means beyond orphan cleanup, but the output schema can carry that detail.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter file_path is not addressed in the description, and schema description coverage is 0%, so the description had the responsibility to explain it. The name is inferable, but the description contributes no semantic detail about the parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Check') and resource ('footnote/endnote structural integrity'), and names the exact conditions it detects: mismatched note definitions/references and orphan definitions. This clearly distinguishes it from siblings like cleanup_orphan_notes and list_footnotes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides conditional routing: if needs_cleanup=true, run cleanup_orphan_notes; use list_footnotes/list_endnotes to inspect note contents. It does not explicitly contrast with broader validators like validate_document, but the targeted scope makes intended use clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden and handles it well: auto-backup rotation behavior, the effect of backup=False, atomic validated save, and the Word-open refusal are all disclosed. Some nuance about 'prev/anchor slots' is missing, but the key safety-relevant behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The entire description is two tightly packed sentences. Main purpose is front-loaded, followed by backup behavior and the refusal condition. No filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a document-mutating operation, the description covers scope, backup behavior, save semantics, and a critical refusal condition. Combined with the output schema, an agent has enough context to invoke correctly. Minor ambiguity around 'prev/anchor slots' prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining the two non-obvious parameters: author ('all of them, or one author's only') and backup ('backup=False skips rotation only'). file_path is self-evident, so leaving it undocumented is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb-resource pair ('Accept tracked changes') and immediately states the two supported scopes ('all of them, or one author's only'). This makes the tool's function unambiguous and easily distinguishable from sibling reject_revisions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states its scope and a key operational caveat ('Refuses documents open in Word'), but it never explicitly tells an agent when to prefer accept_revisions over alternatives such as reject_revisions or revision_summary. Usage context is implied rather than clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does it well: Word computes the value on update, auto-backup behavior and the backup=False semantics are explained, save is atomic and validated, and open Word documents are refused. These are exactly the behavioral details 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler. The core purpose is front-loaded, and each sentence adds distinct useful information about semantics, backup behavior, or failure conditions.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers insertion point, kind semantics, field evaluation, backup/save behavior, and a key failure condition. It does not specify matching semantics for after_anchor or prerequisites for to_bookmark, but these are reasonably inferable and an output schema is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates for the two least obvious parameters: kind is explicitly defined and backup's rotation behavior is clarified. The required parameters file_path, after_anchor, and to_bookmark are not formally defined, but their meaning is strongly implied by the description and parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Insert a cross-reference field after anchor text') and explains the two kind variants ('page' vs 'text'). This clearly distinguishes it from related tools like insert_field, add_bookmark, or validate_cross_references.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when to prefer this tool over alternatives such as insert_field, validate_cross_references, or add_bookmark. The refusal of documents open in Word is an operational constraint, not usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses auto-backup behavior, the meaning of backup=False, atomic validated saving, and refusal to work on Word-locked documents. This is strong, useful behavioral context, though it does not detail the return value or no-op behavior when no orphans exist.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, followed by usage context and critical behavior. Every sentence adds distinct value, with no filler or repetition of the tool name or input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and zero annotations, the description covers the main operational details: what it removes, when to use it, backup semantics, save behavior, and a safety constraint. An output schema exists, so return-value documentation is not required. Minor gaps include exact behavior when no orphans exist and error handling beyond the Word refusal.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 the backup parameter ('backup=False skips rotation only') but does not explain file_path beyond its self-evident name. The description partially compensates for the missing schema descriptions but not fully.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action and target: 'Remove footnote/endnote definitions no body reference points to.' It precisely defines the scope (orphaned notes only) and distinguishes the tool from generic note-deletion tools like delete_footnote and delete_endnote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit guidance: content-deleting tools already handle orphan cleanup automatically, and this tool is specifically for 'documents that arrived with orphans.' It also provides a usage constraint (refuses documents open in Word), though it does not name a specific sibling alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and handles it well: it discloses non-destructive behavior ('Inputs are untouched'), that a new file is created rather than modifying in place, that differences become tracked changes, that a revision summary is generated, and the default output filename. It doesn't state what the function returns or failure conditions, but the presence of an output schema covers return values.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler: purpose is front-loaded, then output format, then safety and naming. Every sentence earns its place, and the example is woven in without bloating the text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter COM operation with an output schema available, the description covers the essential ground: purpose, output format, non-destructiveness, and default naming. Minor gaps remain — the author parameter semantics and explicit differentiation from com_merge_documents/com_combine_documents — but nothing an agent needs to invoke the tool safely is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 for output_path by stating the default naming convention (<revised>_COMPARE.docx), which implies output_path overrides it, and original/revised_path are implied as the two compared documents. However, the author parameter is never explained — its role in attributing tracked changes is left entirely to the schema's bare default value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('compare') and resource (two documents) and specifies the exact output: a NEW file with every difference as a tracked change plus a revision summary. This distinguishes it from near-siblings like com_merge_documents and com_combine_documents, which combine rather than diff documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The example use case ('two DTG versions of a draft') provides clear context for when this tool is appropriate, and the output behavior further clarifies intent. It stops short of 5 because it never names alternatives or states when NOT to use it relative to the merge/combine siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden and does well: it reveals the encryption is genuine AES applied by Word, explains the output_path default and copy behavior, and states the operational dependency ('Requires Word installed; opens an invisible instance'). It does not warn about overwriting the original when output_path is omitted or about password loss, but the key side effects are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each providing distinct value: the core capability, the output_path semantics, and the Word/runtime requirement. No repetition or filler, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and the tool has only three parameters, the description is nearly sufficient for correct invocation. It explains the optional path behavior, the required password, and the environment prerequisite. The only notable gap is making the file_path source role explicit, but this is inferable from 'same file' and the tool name.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It adds real semantics for output_path ('defaults to the same file; a different path saves a new encrypted copy') and for password ('requiring a password to open'), but file_path's role as the source document is only inferred rather than explicitly defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action: 'Save an ENCRYPTED copy requiring a password to open,' then clarifies it is real AES encryption and explicitly contrasts it with document protection, which is an editing restriction. This makes the tool's purpose and its distinction from protection-related siblings clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when this tool is appropriate: when password-protected encryption is needed, and it explicitly rules out the document-protection use case ('unlike document protection which is an editing restriction'). It does not name an alternative sibling or explicitly say 'use set_document_protection for editing restrictions,' so it falls short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It discloses merge-aware shrinking/removal behavior, auto-backup with backup=False semantics, atomic validated save, and refusal on Word-open documents. This gives the agent a strong safety and side-effect profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense, front-loaded sentences with no filler. Each sentence carries distinct information: deletion target/format, merge behavior, backup/save behavior, and a hard failure condition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers deletion semantics, backup, atomicity, and failure conditions, and an output schema exists, so return values need not be explained. The only minor gap is cryptic backup wording ('prev/anchor slots in .ks4w-backups'), which is not essential for invoking the tool correctly but could be clearer.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaningful semantics for the columns parameter (0-based list) and clarifies backup behavior, but schema description coverage is 0%. file_path and table_index are left entirely to the schema's bare names and type info, so the description only partially compensates for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Delete grid columns' with a 0-based list. It also adds key scope details (merge-aware, grid stays consistent) that distinguish it from siblings like delete_rows, insert_columns, and delete_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is implied by the name and first sentence, and the refusal to operate on documents open in Word is a useful constraint. However, the description does not explicitly state when to prefer this tool over alternatives or mention 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does exceptionally well: it discloses inclusive range semantics, vertical merge re-rooting, auto-backup behavior, atomic validated saves, and the refusal to operate on Word-open documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every clause earns its place. The description is information-dense with no filler, front-loading the core action and then adding the highest-impact caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers core semantics, side effects, backup behavior, and a key operational constraint. The presence of an output schema reduces the need to document return values, but minor gaps around null end semantics and table indexing remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 useful meaning for start/end ('inclusive') and backup ('skips rotation only'), but it does not explain the behavior when end is null/default, nor how table_index is indexed relative to list_tables or get_table.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and object: 'Delete rows start..end (inclusive)'. This clearly distinguishes it from siblings like delete_columns, delete_table, and insert_rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The intended use is clear from the name and phrasing, but the description does not explicitly explain when to choose this over alternatives like delete_columns or delete_table. It notes an exclusion (refuses documents open in Word) but gives no alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses that the tool counts citations per system across body, footnotes, and endnotes, and explains the split_brain flag and its meaning. This gives an agent a solid understanding of the tool's output behavior and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense: it lists the detected systems, the counting scope, the split_brain condition, and the recommended invocation timing. Every sentence contributes meaningful information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a preflight detection tool with an output schema, this description is complete: it explains what is detected, how results are structured (counts per location and flag), and when to invoke it. No critical information is missing for an agent to decide to use the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has one required parameter, file_path, with 0% schema description coverage, but the tool description never mentions the parameter or how it should be provided. The parameter name is likely intuitive, but the description provides no added semantic value for it.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific detection function, lists exactly which citation systems are recognized (Word native, Zotero, Mendeley, EndNote, plain text), and gives the technical markers used to identify each. This clearly distinguishes it from sibling tools like check_citation_parity or insert_citation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to run the tool: 'Run this BEFORE any citation work on an unfamiliar document.' This is a clear usage context, but it does not name alternative tools or state explicit exclusion conditions, so it falls just short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 explicitly states 'Read-only' and adds useful behavioral detail about grouping, 0-based nesting, and numbering styles. It does not cover error behavior or ordering, but the output schema mitigates that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the return shape, followed by the intended use case and a read-only safety note. Every sentence contributes meaningful information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only tool with one self-evident parameter and an output schema, the description is complete: it states exactly what is returned, how list paragraphs are grouped, what nesting/style details are included, and the typical verification use case. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, file_path, is not explained in the description, and the schema provides no description either (0% coverage). The parameter name is self-explanatory to some degree, but the description adds no semantic meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource—numbered and bulleted list paragraphs—and specifies the output details: grouping by numbering instance, nesting level, numbering style, and text. It distinguishes itself from sibling tools like get_outline and get_text by focusing specifically on list structure.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit use case: verifying list restarts and nesting after insert_document or add_list. It does not mention when not to use it or name alternative tools, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: it discloses merge-cell widening, auto-backup rotation details, atomic validated saves, and refusal when the document is open in Word. These are non-obvious side effects an agent needs to know.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence earns its place: purpose, merge behavior, backup behavior, and failure condition are densely packed. The purpose is front-loaded, and there is no filler or repetition of schema/default values.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter tool with no annotations and no schema descriptions, the description is unusually complete: it covers position semantics, backup behavior, merge interaction, save guarantees, and a key refusal condition. It only lacks explicit routing to sibling tools and expansion of count/width_pt semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds important meaning for `at` (before position, append when equal to column count) and `backup` (skip rotation only when false). However, with 0% schema coverage, `count`, `width_pt`, `file_path`, and `table_index` remain only minimally inferable from names/types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Insert grid columns') plus the precise insertion position semantics. The behavior is distinct from sibling tools like insert_rows and delete_columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies its use case—inserting table columns—but never explicitly contrasts it with alternatives like insert_rows or set_column_widths. It gives clear context but no when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses auto-backup behavior, the backup=False nuance, atomic validated saving, and refusal when the document is open in Word. This is strong for a mutation tool, though it does not explicitly state what happens to cell contents during the merge, and the 'skip rotation only' wording is somewhat ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: the core action comes first, followed by backup behavior and a safety constraint. Every clause contributes information, and there is no filler or redundant repetition of the tool name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no annotations and an output schema, the description covers the essential context: operation semantics, coordinate inclusivity, backup behavior, save safety, and a refusal condition. Minor gaps remain, such as table_index indexing convention and the precise meaning of 'rotation only', but nothing critical for invoking the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates meaningfully by explaining that coordinates are grid-based and inclusive, and by clarifying the backup parameter's effect. file_path and table_index are left to their self-explanatory names, but the most ambiguous parameters receive useful semantic grounding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Merge') and resource ('rectangle of cells') and adds an explicit semantic detail ('grid coordinates, inclusive'). This clearly differentiates it from sibling operations like unmerge_cells or set_cells without needing to inspect schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful operational context and a hard refusal condition (documents open in Word), but it does not explicitly explain when to prefer this tool over alternatives such as unmerge_cells or set_cells. The intended use is implied by the action and first clause, but there is no explicit routing or when-not-to-use guidance beyond the Word-open refusal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility and does substantial work: it discloses refusals for moves that would cut fields or section breaks, backup rotation semantics in .ks4w-backups, atomic validated save, and refusal for documents open in Word. These behaviors go beyond what the schema or annotations expose and materially affect whether an agent should call the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences pack the core action, matching semantics, safety refusals, backup behavior, and save behavior without redundancy. The primary operation is front-loaded, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex mutation with six parameters and no annotations, the description is unusually complete: it specifies what portion moves, how headings are matched, what operations are refused, and the backup/atomic-save guarantee. It is only slightly incomplete around destination-parameter combinations, such as what happens if at_end is false and no after/before heading is set, or if both are set.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description needed to compensate by explaining the six parameters. It covers heading_text ('exact heading text'), the destination concepts ('before/after ... or to the end'), and backup, but it never names or explicitly explains file_path, at_end, after_heading, or before_heading, nor the precedence or conflicts between destination parameters. This allows rough mapping but leaves parameter-combination semantics to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Move'), a precise resource ('a heading and its ENTIRE section'), and the supported destinations ('before/after another heading or to the end'). It also distinguishes its matching model from siblings by noting sections are addressed by exact heading text and only headings are matched.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is for whole-section moves and gives matching constraints, but it never explicitly says when to prefer this over related siblings such as insert_paragraphs, delete_paragraphs, change_heading_level, or split_table. The usage context is clear enough to infer, but no explicit when-to-use or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers concrete behavioral disclosures: auto-backup into prev/anchor slots in .ks4w-backups, the nuanced partial effect of backup=False ("skips rotation only"), atomic validated save, and a Word-lock refusal condition. It omits permission requirements and failure-error details, but three substantive runtime behaviors are disclosed beyond the name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences with zero filler: the primary action is front-loaded, followed by the backup side-effect nuance, the atomicity guarantee, and the refusal condition. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values are covered, and the description addresses the action, both operation modes, a side effect, save semantics, and a failure condition. The only notable gap for a mutation tool with zero annotations is missing permission/authorization context, which is minor given how much operational behavior is already disclosed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates on the two nuanced parameters: done=False maps to reopening (schema only says boolean, default true) and backup=False is clarified as skipping rotation only, not the backup itself. file_path and comment_id receive no elaboration, but their meaning is self-evident from names and their required status in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
"Mark a comment thread resolved, or reopen it with done=False" states a specific verb (resolve/reopen), a specific resource (comment thread), and an explicit dual-mode behavior. This clearly distinguishes it from siblings like delete_comment (removes the thread), reply_to_comment (adds content), and get_comments (reads).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The done=False clause implies the reopen use case, and "Refuses documents open in Word" states a constraint, but there is no explicit when-to-use versus alternative guidance. Nothing tells an agent to prefer this over delete_comment or reply_to_comment for related comment workflows; usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses substantial behavior: the result reports cells_written, track records tracked changes by author, backup rotation behavior in file mode, atomic validated saves, and live editing semantics for documents open in Word. It does not cover failure/error behavior or permissions, but the disclosed context is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded: core purpose and edit format come first, then usage guidance, then behavioral caveats. Every sentence earns its place, though the backup details are packed into a somewhat compressed clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 7 parameters, no annotations, and 0% schema coverage, the description covers the main workflow well—multi-cell edits, tracked changes, backups, and live mode—but omits details like index conventions and full semantics of several parameters. It is adequate for a competent agent but not fully complete for an unfamiliar caller.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explain the central `edits` parameter and mentions `track`, `author`, and `backup`, but it leaves `file_path`, `table_index`, and the `live` parameter's possible values implicit, and it does not state whether `row` and `cell` are zero- or one-based—an important gap for actually constructing a valid call.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Opens with a specific verb and resource: "Write many table cells in ONE call" and explicitly defines the core input shape `edits = [{row, cell, text}]`. It also differentiates this tool from its closest sibling, set_cells_block, by noting that the sibling writes a contiguous 2D block.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: "Use this for any multi-cell edit instead of per-cell calls" and names the alternative tool set_cells_block with the condition that selects it. It also adds a live-mode constraint about vertically merged tables, helping the agent decide when this path is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden, and it is unusually rich: it promises auto-backup into .ks4w-backups, explains backup=False semantics, describes an atomic validated save, and discloses refusal of Word-open documents. It also says every response includes the full section state, so an agent knows what to expect. No annotation contradiction exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences front-load the core action, then add read-mode usage, backup semantics, and the file-lock refusal. There is no filler and no redundant restatement of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema covers return value structure, and the description covers the operation, read mode, backup, and lock refusal. However, because there are no per-parameter descriptions and the parameters include an opaque margins object and a section index, the definition is not fully self-sufficient for a correct first invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description names page size, orientation, and margins, which loosely map to page_width_pt, page_height_pt, orientation, and margins_pt, but it never explains allowed orientation values, the expected keys or units of the margins_pt object, or section indexing. With schema description coverage at 0%, this gap is material and not fully compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 size, orientation, and margins for one section.' This clearly distinguishes it from document-wide setters such as set_document_properties and read-only section tools like list_sections. The 'one section' scope is explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states a concrete usage pattern: 'call with no change parameters to read the current values,' and flags a hard constraint ('Refuses documents open in Word'). It does not explicitly name sibling alternatives or say when not to use it, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden. It explicitly signals a read-only diagnostic operation ('Read back') and specifies exactly what state is inspected. It does not mention prerequisites or error conditions, but the non-mutating nature is sufficiently clear.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is dense but well-structured, front-loading the operation and then using a colon to enumerate the specific state components. Every phrase contributes meaning, with no filler or repetition of schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single obvious parameter, the presence of an output schema, and the read-back framing, the description covers what the tool reports and how it relates to setup_chapter_headers. Nothing an agent needs to select and invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions file_path, adding no guidance about path format, required document type, or file accessibility. The parameter name is self-explanatory enough to avoid a 1, but the description adds no semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Read back the chapter-header state') and enumerates three concrete outputs: sections carrying STYLEREF fields with field codes, heading levels per section, and gaps that setup_chapter_headers would fill. This clearly distinguishes it from generic header-reading tools and from the related setup tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The reference to 'the gaps setup_chapter_headers would fill' gives an implicit usage context: validate first, then fill gaps with setup_chapter_headers. It does not explicitly state when not to use this tool or name alternative header-inspection tools, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral disclosure. It explicitly reveals auto-backup behavior, the meaning of backup=False, atomic validated saving, and refusal of Word-open documents. This is strong, actionable transparency beyond what the schema alone provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense, with no filler. Each sentence contributes a distinct fact: transform values, targeting modes, backup behavior, and operational constraints. Key information is front-loaded with the purpose first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations and five parameters, the description covers most operational essentials: transforms, targeting, backup, save behavior, and a Word-open refusal. The main gap is the default behavior when neither indices nor find is provided, and how conflicts between the two targeting modes are resolved. The presence of an output schema mitigates the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It explains transform values, target selection via indices or find, and backup semantics. It does not fully clarify what happens if both indices and find are supplied, or if neither is supplied, but it otherwise gives meaningful meaning to the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation as changing text case, with explicit transform values (upper, lower, title, sentence). It does not explicitly distinguish itself from sibling tools like format_text or replace_paragraph_text, but the specific verb and transform set make the purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear targeting guidance: use paragraph indices or every case-insensitive occurrence of `find`. It also states a key operational constraint (refuses documents open in Word). It stops short of saying when to prefer an alternative sibling tool, but the scoping rules are clear enough for most calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It discloses the heuristic nature with a BETA warning, explains the output categories, warns that 'used_never_defined' is a heuristic candidate list, notes the scope ('Body-level paragraphs only'), and states 'Read-only.' This exceeds the typical transparency level.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but each sentence adds value: warning, purpose, pattern examples, output categories, scope, and read-only flag. It is front-loaded with the BETA warning. Slightly long, but structured and free of filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers the heuristic risk, the exact outputs, and the scope limitation. An output schema exists, so detailed return format is not required. Minimal omissions (e.g., whether it works on non-legal documents) are minor given the specificity already present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 'definition_patterns' in detail (regexes capturing group 1, defaults overridable). It does not explain 'file_path', but that parameter is self-evident from its name and common across tools. The meaning added is meaningful and reduces ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Audit') and a well-defined resource ('a legal document's defined terms'). It lists the specific categories it reports, making it unmistakably distinct from sibling audit tools like validate_document or diagnose_document. No tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when auditing defined terms, but does not explicitly contrast with alternatives or state when not to use it. It names no sibling tools or conditions for alternative selection, leaving the agent to infer that this is the right tool for defined-term audits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden. It explicitly states 'Read-only' and discloses important behavior like dropping resolved threads when include_resolved=False and reporting the excluded count. This goes beyond the schema and gives an agent confidence about side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: it front-loads the core deliverable, enumerates return fields, gives the use case, documents the key parameter, and ends with the safety-relevant 'Read-only' note. There is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple two-parameter schema and the existence of an output schema, this description is complete enough for selection and invocation. It covers what the call returns, how the optional parameter changes results, and the read-only guarantee.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds real meaning for include_resolved, explaining the dropout behavior and the excluded count reporting. However, file_path, the only required parameter, is not described at all, and schema description coverage is 0%, so the required parameter's meaning is left purely to inference from its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific deliverable: a full reviewer matrix of comment threads with author, replies, resolved flags, and locators. It distinguishes itself from the simpler get_comments sibling by emphasizing the aggregated summary and one-call design.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear target use case: processing committee feedback without reading comments piecemeal. It does not explicitly name alternatives or exclusion criteria, but the stated intent is strong enough for an agent to select this over more granular comment tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and delivers substantial behavioral detail: auto-backup with prev/anchor slots, backup=False behavior, atomic validated save, and refusal to operate on documents open in Word. This goes well beyond the schema and gives an agent important expectations before invoking.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense, purposeful sentences. It front-loads the core purpose, then workflow, then key behavioral and safety details, with no filler or repetition of the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 9 parameters with 0% schema coverage and no annotations, the description is not exhaustive, but it provides strong context: the get_styles shape link, backup behavior, and Word-open refusal. The output schema exists, so return-value handling does not need elaboration. A bit more parameter-level detail would make it fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate, but it only adds semantics for backup and general 'full formatting control.' It does not explain style_type, based_on, next_style, or the structure of character_formatting and paragraph_formatting, leaving most parameters semantically opaque.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses specific language: 'Create or replace a custom style (paragraph or character) with full formatting control.' This clearly identifies the operation, resource, and scope, and distinguishes it from style-application siblings like apply_style and apply_character_style by framing it as definition, not application.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear workflow guidance by pointing to get_styles as the read counterpart and explaining that cloning is 'one read + one define.' It does not explicitly mention apply_style or other alternatives, but the context for when to use define_style is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full weight, and it is unusually thorough: it discloses inclusive range semantics, the empty-paragraph fallback, tracked-deletion behavior, backup slots, atomic validated saves, and live editing of documents open in Word. Nothing contradicts the missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The core operation is front-loaded and every clause carries information, but the sentence is dense with caveats (backup slots, atomic save, live editing), making it efficient rather than crisp. It earns its length, though it could be broken into bullets for readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no annotations and an output schema, the description covers the important edge cases and side effects well. The main missing context is full clarification of the 'live' parameter and how file mode is selected, but overall an agent can call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 largely does: start/end inclusivity and default, track+author behavior, and backup=False semantics are all explained beyond the bare schema. file_path and the 'live' parameter are not given the same explicit treatment, leaving a small gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Delete body paragraphs start..end' – a specific verb, target resource, and exact range semantics. This distinguishes it from paragraph-adjacent siblings like replace_paragraph_text and from delete_source/delete_columns/delete_rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The deletion semantics and refusal conditions ('Refuses ranges that cut through a field or carry a section break') give clear context, but no alternative tools are named or recommended. When-to-use vs siblings is only implied by the phrase 'body paragraphs.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral burden. It discloses the read-only nature ('Read-only') and the comprehensive scope ('Every header and footer part across all sections'), which gives an agent a clear safety profile. It could add more about side effects or file requirements, but for a getter this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences: the first front-loads the core behavior and output, the second provides sibling routing, and the third adds the read-only trait. Every clause earns its place with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with an output schema, the description is largely sufficient: scope, alternatives, and read-only status are all covered. The only completeness gap is the undocumented file_path parameter, which is minor given its standard naming. Overall, an agent can select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions the file_path parameter or adds meaning beyond its name and type. The parameter is self-evident, but the description misses the opportunity to explain the expected path format or document context, so the agent gets no semantic help beyond the property name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('get') and a precise resource: every header and footer part across all sections, listing the exact data returned (text content, PAGE-field presence, part type). It also differentiates itself from sibling writers set_header/set_footer and setup_chapter_headers, so an agent can tell it apart without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes to alternatives: 'Use set_header/set_footer to write them and setup_chapter_headers for per-chapter running headers.' This gives clear when-not-to-use guidance and names the sibling tools for those cases, leaving nothing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It does so well by explicitly stating the operation is read-only and enumerating what information is returned. It does not mention error cases or authorization requirements, but for a simple getter this is a minor gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three concise sentences with no filler. It front-loads the purpose, then gives the output details, sibling routing, and read-only safety note in an efficient order. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description appropriately focuses on behavior and selection criteria. It covers the operation's purpose, returns, safety profile, and alternatives. A small gap remains regarding file_path semantics and failure conditions, but the description is otherwise complete for a simple getter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 undocumented file_path parameter, but it does not explain the parameter's format, meaning, or required document context. The parameter name is somewhat self-explanatory, but the description focuses entirely on return values rather than input semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific verb and resource: retrieving the current document protection state, and enumerates the exact attributes returned (mode, password set, formatting restrictions). It also distinguishes itself from the sibling set_document_protection and remove_document_protection by positioning itself as the read counterpart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly routes the agent to the correct sibling for write operations: 'Use set_document_protection to enable and remove_document_protection to disable.' This gives clear when-to-use versus when-not-to-use guidance beyond merely describing the tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral disclosure burden and does so well: it reveals auto-backup rotation behavior, atomic validated saving, refusal to operate on documents open in Word, and the fact that page numbers are generated when fields update. These are non-obvious and safety-relevant behaviors.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences with no filler. The core action is front-loaded, followed by backup/save behavior and the open-document guard; every clause adds necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the main operation, field-update behavior, backup and save semantics, and the open-document refusal. An output schema exists to convey return details. The main gap is the opaque after_index parameter and some other parameter semantics, but the tool is callable with reasonable confidence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does 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 eight parameters. It clarifies backup behavior ('backup=False skips rotation only') and indirectly relates field updates to update_on_open, but after_index, letter_headings, at_end, and columns receive no meaningful explanation. Too many parameters are left to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Insert the INDEX field compiling all XE entries with page numbers'. This distinguishes insert_index from sibling tools such as mark_index_entry and insert_toc by naming the exact Word field and its source data.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: after XE entries exist and when a compiled index with page numbers is needed. It does not explicitly name alternative tools or state when not to use it, so it falls short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral disclosure burden. It explicitly labels the operation as read-only, which is the most important behavioral trait for an agent deciding whether calling it is safe. It could add more context about file requirements or error conditions, but the read-only disclosure is meaningful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three focused sentences: first the output fields, then the mutation alternatives, then the read-only guarantee. Every sentence earns its place, and the key scoping information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with an output schema present, the description is mostly complete: it covers scope, output contents, related mutation tools, and read-only behavior. The only notable gap is the undocumented file_path parameter, but the one-parameter shape and 'in the document' phrasing make the gaps relatively minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage and the only parameter, file_path, is not explained anywhere in the description. The phrase 'in the document' weakly implies the parameter identifies the target document, but this is not explicit and does not compensate for the schema's lack of documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action as listing every endnote in the document and specifies the exact output fields: id, display position, and full text. This is a specific verb-plus-resource statement that distinguishes the tool from nearby siblings like list_footnotes and the mutation tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when not to use this tool: use add_endnote/edit_endnote/delete_endnote for modifications and validate_notes for integrity checks. This provides clear alternatives and conditions, so an agent knows this is the read-only listing operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and explicitly declares 'Read-only' and enumerates the output fields. It does not mention potential edge cases such as no images or file-not-found, but its non-destructive nature and return scope are clearly stated.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences contain no filler: the first packs the resource and all returned fields, the second handles routing to an alternative and the read-only nature. Information is front-loaded and every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list operation with an output schema, the description is nearly complete: it identifies scope, distinguishes from a sibling, and notes safety. The only gap is the undocumented file_path parameter, but the overall tool behavior and relationship to dependent tools are clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description never mentions file_path or how it should be specified. The sole parameter is a bare string in the schema, so the agent gets no guidance on path format or semantics from either source.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Every inline image' and enumerates exactly what is returned (index, display size, native pixels, DPI, alt text, media part path), making the tool's function and scope unambiguous. It explicitly names check_image_resolution as a distinct alternative, so an agent can tell the two apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the primary use (listing inline images) and gives a direct routing rule: for print-quality checks, use check_image_resolution instead. It also tells the agent that the returned index is meant to feed resize_image, replace_image, and set_image_alt_text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 discloses that the tool is read-only, which is the most important behavioral trait. It also clarifies that it lists entries already marked in the document rather than creating or compiling them.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. It front-loads what the tool lists, then gives clear pointers to related operations, and closes with a concise read-only note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter listing tool with an output schema present, the description covers the resource scope, output details, related tools, and mutability. Nothing essential is missing for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With schema description coverage at 0%, the description should compensate for parameter documentation, and it does not explicitly describe file_path. However, the single parameter's name is self-explanatory, and 'in the document' implies that file_path identifies the document. This is adequate but not thorough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific resource ('XE index entry') and details the kinds of entries included (main text, sub-entry, see/see-also references) plus the paragraph location. It also distinguishes itself from sibling tools mark_index_entry and insert_index by explicitly listing their purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description tells the agent when this tool is appropriate versus the related tools: use mark_index_entry to add entries and insert_index to generate the compiled index. It does not explicitly state 'use this to enumerate entries,' but the contrast is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It explicitly states 'Read-only' and explains that the listed sources feed insert_citation and insert_bibliography. It could add more about edge cases, such as behavior when no sources exist, but the output schema likely covers return structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences, each earning its place: content scope, usage context, and a safety/read-only note. The most distinguishing information is front-loaded, and there is no fluff or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is nearly complete for a simple list operation: it names the data returned, the workflow context, and the read-only nature. The only notable gap is the absence of file_path semantics, which is a minor omission given the single obvious parameter and the presence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not clarify the file_path parameter beyond its name. Although file_path is self-explanatory in context, the description does not compensate for the missing schema documentation, so the agent must infer the expected path format and meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies a specific resource (bibliography sources in the document's XML source store) and the action (listing them). It also distinguishes this tool from the native citation workflow and from external citation managers, making it easy to differentiate from siblings like insert_citation, insert_bibliography, and delete_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states this is for Word's native citation system and not Zotero/Mendeley/EndNote, which tells the agent when not to use it. It also instructs running detect_citation_system first on unfamiliar documents, giving a clear prerequisite and alternative path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of explaining behavior. It states exactly what is searched (body, tables, headers/footers, footnotes), what counts as a placeholder, and that output includes counts and locations. 'Find' implies a read-only operation, and the relationship to fill_template and mail_merge adds useful behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. It front-loads the action and scope, then adds an important relationship to sibling tools fill_template and mail_merge. Every sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter discovery tool with an output schema, the description is complete: it specifies what is found, where it is found, what the results contain, and how the names relate to downstream tools. It gives an agent everything needed to select and invoke this tool correctly in a template-processing workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With a single required file_path parameter and 0% schema description coverage, the description only indirectly clarifies that file_path refers to a template via the phrase 'in a template'. The parameter is self-descriptive and the context is sufficient, but the description adds no explicit guidance on path format, file type, or required template structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (find), a specific resource (template placeholders), and two concrete placeholder types ({{name}} and legacy MERGEFIELD). It clearly distinguishes this tool from broader document-info or text-search tools by narrowing scope to template placeholders with locations and counts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description communicates clear context: the results are the keys that fill_template and mail_merge expect, so an agent can infer this tool is for pre-flight discovery before rendering templates. It does not explicitly say when not to use it or compare it against alternatives like find_text or list_fields, but the intended usage is strongly implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It meaningfully states that cached text reflects the state at last field update, that refresh requires Word, and that the operation is read-only. It could add more about error cases or whether reading requires Word, but the core behavior is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded, stating the tool's core behavior first, then the cache caveat and refresh path, then the management alternatives, and finally the read-only nature. No sentence is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what is read, the cache staleness behavior, the refresh path, related management tools, and read-only status. The output schema covers return structure, so that is not a gap. The only notable omission is describing the file_path parameter semantics.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter, file_path, has no schema description (0% coverage) and the tool description does not mention it or clarify the expected path format. Since the description must compensate for the low schema coverage and does not, parameter semantics are under-specified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and a precise resource ('every TOC-family field... and its cached entries'), including details like main TOC, List of Tables, and List of Figures. It clearly distinguishes the tool from management siblings like insert_toc and delete_toc by the final 'Read-only' statement.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to refresh (with com_refresh_fields) and re-read, and tells the agent to use insert_toc, insert_caption_list, and delete_toc for managing TOCs. This provides clear routing between read and mutation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 explicitly says 'Read-only,' which is an important safety signal for an otherwise unannotated tool. It could add more about edge cases such as documents with no tracked changes, but the read-only flag covers the primary risk.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three short, purposeful sentences: purpose, alternative routing, and safety flag. Each sentence earns its place, and the most essential information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only tool with only one parameter and an output schema present, the description covers purpose, sibling differentiation, and behavioral safety. The main gap is the unexplained 'file_path' parameter semantics, which keeps it from being fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never explains what 'file_path' should refer to or what format is expected. The parameter name is somewhat self-descriptive, so this is not a total failure, but the description does not compensate for the schema's lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb, 'Summarize', names the resource ('tracked-change counts by author and type'), and explicitly differentiates from the sibling tool revision_analytics by pointing out that word-level and per-section analytics belong there. This gives an agent a clear, scoped understanding of the tool's role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the exact condition for selecting an alternative: 'For word-level analytics and per-section concentration use revision_analytics.' This explicitly tells the agent which tool to invoke based on the granularity of the requested analysis, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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, and it does so thoroughly. It explains trackedChanges semantics, password hashing compatibility, the distinction between protection and encryption, backup rotation behavior, atomic validated save, and the refusal to operate on documents currently open in Word.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose. Every sentence contributes distinct operational information, and the use of semicolons keeps related details together without unnecessary exposition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers most invocation-critical behavior, especially given the presence of an output schema for return values. However, restrict_formatting is a parameter with no documentation anywhere, and the description does not clarify whether it is required for certain protection modes or how it interacts with the edit setting. This is a meaningful gap for a 5-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and no enums, so the description must compensate. It adds useful meaning for edit (mode list and trackedChanges behavior), password (Word-compatible SHA-512, not encryption), and backup (rotation semantics). However, restrict_formatting is left entirely unexplained, despite being a schema property, and file_path semantics are only implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Restrict editing', a specific verb and resource, then enumerates the supported modes: readOnly, comments, trackedChanges, forms. It clearly distinguishes itself from the sibling encryption tool com_save_with_password, so an agent can separate protection from encryption without needing the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool and explicitly routes encryption use to com_save_with_password. It does not explicitly contrast with get_protection or remove_document_protection, but the purpose and scope are evident enough that an agent can infer the correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full behavioral disclosure burden. It goes beyond the schema by explaining auto-backup to .ks4w-backups slots, backup=False semantics, atomic validated save, and Word-open refusal. These are non-obvious traits an agent needs before invoking the tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences deliver the purpose, coordinate convention, backup behavior, atomic save guarantee, and refusal conditions with zero filler. The primary purpose is front-loaded, making the description efficient and easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The output schema is present, so explaining return values is unnecessary. The description covers the core operation, coordinate semantics, backup/atomicity, and key failure modes. However, the 0% schema description coverage leaves several boolean parameters under-specified, which keeps it just shy of fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% across 7 parameters. The description adds meaning only for column as a 0-based CELL index and partially for backup as skipping rotation only. Numeric, descending, has_header, table_index, and file_path remain undocumented beyond their names and defaults, so the description does not compensate for the schema gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Sort data rows by a column (CELL index, 0-based).' It clearly identifies what the tool does and distinguishes it from the many table mutation and insertion siblings. The cell-index detail adds precision that prevents confusion with column-name-based sorting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context for sorting table rows and explicitly names refusal conditions: vertical merges making rows interdependent and documents open in Word. It does not name an alternative sort tool, but no sibling appears to duplicate this operation, so the guidance is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so well: it discloses auto-backup behavior, the precise effect of backup=False, atomic validated saving, and the refusal condition for Word-open documents. These are meaningful operational details beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences carry purpose, mechanics, backup behavior, save guarantees, and a lock-related refusal condition without filler. Referencing add_footnote compresses a lot of shared mechanics into one phrase.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core action, anchor semantics, backup behavior, save validation, and the Word-open refusal, and an output schema exists so return values need not be described. The main remaining gap is the undocumented occurrence parameter, and the description relies on the agent knowing add_footnote's mechanics to be fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 anchor_text semantically and clarifies the backup parameter's special behavior, but it leaves note_text, occurrence, and file_path to schema names only. Occurrence is particularly under-specified since its integer semantics are not self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Add') and a precise resource ('endnote anchored after anchor_text'), and distinguishes itself from the sibling add_footnote by naming the endnote resource and the anchor mechanism. It is immediately clear what operation this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'same mechanics as add_footnote' provides a usable comparison for agents that know that sibling, and 'Refuses documents open in Word' gives a concrete precondition. It does not explicitly enumerate when to prefer this over edit_endnote or delete_endnote, but the purpose is clear enough that the main usage scenario is not ambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, and it delivers: it discloses mutation, automatic backup of prev/anchor slots, the effect of backup=False, atomic validated save, and refusal on Word-open documents. This is unusually transparent for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences contain no filler; the core operation, safety/backup behavior, and lock-out condition are each front-loaded and compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutating tool with no annotations, the description covers operation, backup, and failure-lock behavior; the output schema covers return shape. Some practical details—file_path meaning, exact occurrence matching, and behavior when anchor_text is absent—are left to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must add parameter meaning, and it does for anchor_text (occurrence-th match), url (external), occurrence (which match), and backup (skips rotation only). It leaves file_path implicit and does not specify the indexing base or matching semantics, so it is not perfect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: turn existing text into an external hyperlink, anchored to the occurrence-th match of anchor_text. This clearly differentiates it from nearby siblings like add_cross_reference, add_bookmark, or insert_field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It communicates the core scenario—existing text, external link, occurrence-based targeting—and gives one explicit when-not condition (documents open in Word). However, it does not name alternatives or provide a when-to-use vs. when-not-to-use map among the large sibling tool set.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavior disclosure. It covers glyph rendering, numbering.xml infrastructure, numbering restart per call, nesting behavior, backup rotation, atomic validated saves, and refusal to operate on Word-locked documents. This is unusually thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: purpose, item format, key behavior, backup semantics, and a critical safety refusal. It is front-loaded with the main purpose and avoids filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is strong on side effects, failure conditions, and list behavior, and an output schema exists to cover return values. However, the relationships and defaults among placement parameters (at_end, after_index, after_anchor) are not clarified, which is a meaningful gap for a tool with seven parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explain items as strings or {text, level} dicts, kind values, and backup behavior, but it leaves placement parameters at_end, after_index, and after_anchor largely undocumented. This is partial compensation, not complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause states a specific action ('Insert a bulleted or numbered list') and specifies the distinctive implementation detail of real bullet/number glyphs. This clearly separates add_list from read-only siblings like get_lists and from other insertion tools such as insert_paragraphs or add_heading.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use clear: this is the tool for inserting bulleted/numbered lists with nested levels and independent numbering. It does not explicitly name alternatives or state when not to use it, but the scope is obvious enough for an agent to select it correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so richly: auto-backup behavior, backup=False semantics, atomic validated save, and refusal to operate on documents open in Word are all disclosed. This goes far beyond a generic 'add watermark' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tightly packed sentences, front-loaded with the core purpose and followed by consequential operational details. Every sentence adds useful information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, placement, Word compatibility, backup behavior, save behavior, and an important failure condition. It does not explain how the tool interacts with an existing watermark, but the output schema and self-explanatory parameter names cover most remaining needs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 directly explains the `backup` parameter and partially clarifies `text` and placement. However, `color`, `opacity`, `diagonal`, and `file_path` are left to inference from names/defaults rather than described.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states the exact operation: 'Add a text watermark behind the text on every page,' with placement detail and Word compatibility. This clearly distinguishes it from the sibling `remove_watermark` tool by verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The purpose is clear enough that an agent knows when to call it, and the Word Remove Watermark compatibility note implies removal is handled by Word/another tool. However, it does not explicitly name alternative tools or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 adds meaningful context: output defaults beside the original, original attributions are preserved, and Word must be installed. It does not explicitly state whether input files are modified or what happens if output_path already exists, but the provided behavioral details are substantive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: purpose first, then usage guidance, alternative, output behavior, and prerequisite. Every sentence earns its place, and there is no redundant or vague phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity Word operation with no annotations, the description covers the main requirements: purpose, when to use, primary alternative, output location, and environment prerequisite. Since an output schema exists, return-value details do not need to be spelled out. The only notable gap is the lack of explicit per-parameter mapping for original_path and revised_path.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 output_path's default behavior ('Output defaults beside the original'), but original_path and revised_path are left to their self-descriptive names without explicit explanation of which document each must point to. This is adequate but not fully compensating for the missing schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb-resource pair: 'Combine two reviewers' tracked changes into one document' and explicitly preserves original attributions. It also distinguishes itself from com_compare_documents by naming the alternative, so an agent can tell this from the closest sibling without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is present: 'Use when two people edited copies of the same draft and you need a unified redline.' It also gives a clear exclusion: 'For diffing two versions to discover what changed, use com_compare_documents instead.' This leaves little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden and discloses meaningful traits: it produces ONE new file, implies non-destructive merging, operates via Word, preserves styles/footnotes/numbering, and inserts section breaks between parts. It does not mention overwrite behavior or whether source files are modified, but the core behavioral profile 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no filler. The core operation and fidelity details are front-loaded, and the alternative routing is compactly appended. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so explaining return values is unnecessary. The description covers operation, ordering, fidelity, section behavior, and key alternatives. The main gaps are not distinguishing from com_combine_documents and not specifying what happens if output_path already exists.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 effectively explains paths as whole documents in order, output_path as the new file, and section_break_between as section breaks between parts. All three parameters are inferable from the prose even though they are not explicitly named.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: concatenate whole documents in order into one new file, with fidelity guarantees covering styles, footnotes, and numbering. It also explicitly contrasts with insert_document and copy_table, helping an agent distinguish it from relevant siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit routing guidance: use insert_document for inserting a document into an existing file at a chosen position, and copy_table for a single table. However, it does not address the similarly named com_combine_documents sibling, leaving some ambiguity about when to choose merge over combine.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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, and it does so thoroughly: it explains DTG replacement rather than stacking, no overwrite behavior with collision suffixes, source document immutability, permanence, and exclusion from manage_backups. This is unusually complete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient, with the main purpose front-loaded. Every sentence adds useful information: naming, collision handling, permanence, relation to backups, and return value. No filler or redundant restatement.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, the description covers the essential behaviors: naming, permanence, no-overwrite guarantee, source immutability, and return path. The main gap is the undocumented dest_dir parameter, and the parameter mapping itself could be more explicit, but the tool is otherwise well specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 for label ('optional short label suffix') and implies file_path is the source document, but dest_dir is never described and its null/default behavior is left to inference. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource ('Save a DTG-stamped permanent copy of the document') and gives the exact filename pattern. It also distinguishes snapshots from the automatic prev/anchor backup slots, making it clear what this tool is and how it differs from sibling backup-related operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly situates snapshots against manage_backups and the rotating prev/anchor slots, explaining that snapshots are permanent and never auto-pruned. It does not explicitly phrase when to choose this over alternatives, but the contrast is strong enough for an agent to infer the appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to lean on, the description carries the full behavioral burden and does so thoroughly: it declares read-only semantics, explains the never-fail degradation contract and ok=false criterion, and discloses that results are stale while Word holds unsaved changes. This goes well beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but organized: purpose, failure behavior, sibling positioning, then the live-mode caveat. The long list of checks is informative rather than filler, though it could arguably be tightened without losing meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description does not need to explain return values. It covers scope, failure semantics, the stale-by-design limitation, preconditions (close the document), and alternatives, so an agent has enough context to decide when and how to call the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, file_path, has 0% schema description coverage and the description never explicitly explains what the value must be (existing file path, docx package, etc.). The tool name makes the intent inferable, but for a one-parameter tool with an empty schema description the description should have compensated.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Produce a one-call structural health report') and enumerates the exact checks, making the tool's scope unmistakable. It also positions itself as 'the deep companion to validate_document's quick check,' distinguishing it from the most similar sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when not to use the tool ('No live mode BY DESIGN'), tells the user to close the document first, and names concrete alternatives (com_close_open_document, com_validate_opens_clean, live get_document_info). The relationship to validate_document is also clearly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and explicitly declares 'Read-only,' which is the key safety-relevant behavior. It also discloses the scope ('Every tracked change') and the kind of data returned. It could add details like ordering or pagination, but for a read-only retrieval tool the core transparency is well covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, no filler. The first sentence states the resource and returned fields, the second covers filtering, and the third gives routing and safety. Information is front-loaded and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema reduces the need to describe return values. The description covers the main behavior, filtering, alternative tools, and read-only safety. It is slightly incomplete in not explicitly stating what document 'file_path' refers to, though this is fairly inferable from the tool name and context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 real meaning for the 'author' parameter ('Filter by author to see one reviewer's edits'), helping map it to a use case. However, it does not explicitly describe 'file_path,' leaving that important required parameter to inference from its name and context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool returns: every tracked change with type, author, date, affected text, and paragraph location. It implicitly names the operation (list/retrieve) and distinguishes itself from revision_summary/revision_analytics by pointing out those are aggregate views, and from accept_revisions/reject_revisions by noting those resolve changes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit routing guidance: 'Filter by author to see one reviewer's edits' gives a concrete use case, and 'Use accept_revisions/reject_revisions to resolve, or revision_summary/revision_analytics for aggregate views' states when alternatives should be chosen. The tool's own niche is clear by exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and does so well: auto-backup behavior, backup=False semantics, atomic validated save, and refusal of open documents are all disclosed beyond what the schema shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each earning its place: the primary action, the precondition, the backup/save behavior, and the refusal case. It is front-loaded with the core operation and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core call is complete: only file_path is required, defaults cover the rest, and output schema exists so return values do not need explanation. The main gap is non-default placement/title semantics, but the essential operational and safety context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only explicitly adds semantics for backup (backup=False skips rotation only). title, at_end, after_index, update_on_open, and file_path are left to naming conventions and defaults, so the description does not compensate for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact operation ('Insert the BIBLIOGRAPHY field') and the observable effect (Word generates a full styled reference list from the source store). This clearly differentiates it from insert_citation, set_bibliography_style, and similar siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit precondition with rationale: run detect_citation_system first on unfamiliar documents because mixed citation managers produce an unmaintainable bibliography. It also gives a clear when-not: the tool refuses documents open in Word.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full disclosure responsibility and does so well: it reveals auto-backup behavior, the effect of `backup=False` (skip rotation only), atomic validated save, and refusal on documents open in Word. These are non-obvious side effects and failure modes that protect the agent from surprise.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but free of filler, with the core insertion behavior first and supporting operational caveats following. Each sentence adds a distinct fact, and the unusual semantics (`at`, backup rotation, Word-open refusal) are preserved instead of buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with six parameters and no annotations, the description covers the critical edge cases and side effects, and an output schema exists to document return values. The main missing context is the meaning and validation of `count`, but the default and name make its intent inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the prose must compensate. It adds real meaning for `at`, `copy_format_from`, and `backup`, but leaves `count`, `file_path`, and `table_index` unexplained; `count` is the most significant gap because an agent cannot be certain whether it refers to the number of rows or another unit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific behavior—inserting rows before a given row—and explains the two key modifiers: `at` position semantics and `copy_format_from` behavior. This distinguishes it from row deletion (`delete_rows`) and column insertion (`insert_columns`), so an agent can select it correctly without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear situational context: rows go before the tracked row, appending when `at` equals row count, and copying format from a chosen source row. It does not explicitly state when to prefer a sibling like `insert_columns` or `set_cells`, but the row-specific wording and table-index requirement make the intended use evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are absent, so the description carries the behavioral disclosure burden. It clearly states the operation is read-only and describes the returned content in useful detail. It doesn't mention edge cases like missing files or ordering, but for a simple list operation this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then gives routing guidance and safety status. Every sentence earns its place with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only listing tool with an output schema, the description is complete. It states scope, output content, read-only behavior, and directs to sibling tools for modifications and validation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single parameter, file_path, has 0% schema description coverage, and the description never explains what file_path means or how it should be provided. The parameter name is somewhat self-explanatory, but the description does not compensate for the total lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every footnote in the document, specifying the exact returned fields: id, display position, and full text. This distinguishes it from related tools like list_endnotes by scope and resource type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names the modification tools (add_footnote/edit_footnote/delete_footnote) and the integrity-check tool (validate_notes), telling the agent when to use alternatives. This removes ambiguity about whether this tool can modify or validate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does it well: it explicitly labels the tool as read-only, discloses that broken field pairs are 'reported loudly', and explains that Mendeley/EndNote support is preservation-only with no insertion capability. This goes well beyond a basic summary of the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause adds value: scope, reported attributes, broken-pair behavior, preservation limitations, insertion alternative, and read-only status. It is front-loaded with the core action and includes no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only inventory tool with an output schema, the description covers scope, return intent, limitations, and error behavior. The only minor gap is the lack of explicit file_path semantics and absence of any direct comparison with integrity-specific sibling tools, but these are not critical for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the only parameter, file_path, is not explicitly described. However, the tool's purpose is tied to inventorying fields in a document, making it clear that file_path targets the document to inspect. The meaning is inferable, but a direct mention of the parameter would have made it fully unambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Inventory') and names the exact resource (Zotero, EndNote, and Mendeley fields) plus the scope (body, footnotes, endnotes). It also enumerates what is reported, so an agent can distinguish it from broad tools like list_fields or integrity-specific tools like check_reference_field_integrity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by stating what it inventories and notes that Zotero insertion exists via insert_zotero_citation, but it does not explicitly state when to prefer this tool over siblings like list_fields or check_reference_field_integrity. The preservation-only note gives some contextual guidance, but exclusions and alternatives are not fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it declares 'Read-only' and explains what the output reveals (what travels with each heading and body-item indices at section boundaries). This gives an agent safety-critical and behavioral context beyond a bare 'list' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three compact lines front-load the resource and counts, then give targeted use context, then state safety. Every clause earns its place; no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter read-only listing tool with an output schema present, this is complete: it states the resource, the useful counts, the dependent operations, and the read-only nature. The remaining file_path convention is standard across sibling tools and captured in the input schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description never mentions file_path or its meaning. The parameter name is somewhat self-explanatory, but the description does not compensate for the schema's lack of documentation, so a low score is warranted.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete resource ('Headings with each section's body-element count, paragraph count, and table count') and immediately distinguishes the tool from siblings by labeling it a planning aid for move_section and insert_document/copy_table. An agent can tell it apart from list_sections or get_outline without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly identifies when to use this tool: as a planning aid before move_section and for insert_document/copy_table to see body-item indices at section boundaries. It does not, however, state when not to use it or compare it to similar listing tools like list_sections or get_outline.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral disclosure burden. It clearly states the tool is read-only and lists exactly what information is returned. It does not mention file errors or ordering, but for a simple listing tool, the explicit 'Read-only' and scope are strong behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences deliver the return fields, route to the correct mutation tools, and state read-only behavior. There is no redundancy or filler; the most important information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is a simple read-only listing operation with one obvious file_path parameter and an output schema available. The description covers what is returned, read-only semantics, and alternative tools for modifications, which is complete enough for an agent to select and call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description needed to compensate by explaining the file_path parameter. It does not mention file_path at all. The parameter is simple and self-explanatory, but the description adds no semantic value beyond the schema's bare type declaration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the resource ('every section') and enumerates the exact properties returned: page width/height, orientation, margins, and header/footer references. It also distinguishes itself by naming set_section_properties and add_section_break as the tools for mutations, so an agent can tell it apart from those siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when not to use this tool: use set_section_properties for changing page geometry and add_section_break for creating new sections. The 'Read-only' statement further reinforces that this tool is for observation, not modification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing side effects and safety. It explicitly states the tool is 'Read-only', does not select anything, and does not move the cursor, which are the most important behavioral traits for a navigation command. It also notes that find targets the first match. It doesn't discuss not-found behavior or conflicts between the two target parameters, but the provided behavior is still substantially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences of concentrated, relevant information. It front-loads the core action and side-effect-free nature, then adds targeting options and the prerequisite. Every clause adds value; 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.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description covers the main purpose, targeting methods, use case, prerequisite, and read-only nature. An output schema exists, so the absence of return-value detail is not a gap. It could be more explicit about what happens when both find and paragraph_index are supplied or when no target is found, but the core information needed to invoke the tool correctly is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate for all three parameters. It does: 'find text (first match)' maps to the find parameter, 'body paragraph_index' maps to paragraph_index, and 'document must be open in Word' clarifies the file_path target. This is strong compensation, though it leaves some ambiguity about parameter precedence and the meaning of 'body paragraph_index'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Scroll the user's Word window'), the target resource (a Word document), and the key behavioral nuance (no selection, no cursor movement). It also distinguishes itself from related tools like live_insert_at_cursor and find_text by emphasizing it only navigates the view. This is more than enough for an agent to understand the tool's unique purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a strong usage context: 'useful after a live edit to show the user what changed' and a clear prerequisite ('document must be open in Word'). It does not explicitly mention alternatives or when not to use it, but the intended scenario is clear enough for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden. It clearly states non-modification, scope options, matching engine parity, and the exact output contents (counts, contexts, total, refusals). It does not mention failure modes or permission requirements, but what is disclosed is substantial and accurate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Despite being dense, the description is efficiently structured: the key fact is front-loaded, scoping details are compactly listed, and each sentence adds value. Nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given complexity and lack of annotations, the description covers purpose, safety, scope, matching behavior, and next-step guidance. It might have briefly explained the replacements array structure, but the presence of an output schema and the clear sibling reference make this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 context by naming the replacement item fields ({find, replace, regex?}), scope values, and the matching engine, but it never directly documents file_path or the replacements array structure. It relies heavily on the sibling search_and_replace for full parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Dry-run search_and_replace; the file is NEVER modified,' giving a specific verb, resource, and the key distinguishing behavior. It makes clear this is a preview variant of search_and_replace, not the mutation itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells the agent when to use this tool ('Review, then run search_and_replace') and even prescribes how to set max_replacements to the previewed total. This is direct, actionable guidance that routes the agent to the correct sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It discloses auto-backup behavior, backup slot locations, an atomic validated save, and the Word-open refusal. The phrase 'skips rotation only' is ambiguous, but the overall side-effect and safety picture is unusually clear for a short description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences deliver the primary function, prerequisites, side effects, and a failure condition without waste. Every clause adds useful operational information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool modifies an image in a document, the description covers what the tool does, how to identify the image, backup behavior, save behavior, and a hard failure condition. The 'prev/anchor slots' and 'skips rotation only' phrasing is slightly jargony, and file_path semantics are only implied, but an agent has enough to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 all four parameters. It clarifies width_pt as the target width, image_index as coming from list_images, and backup's effect on backup rotation. file_path is not explicitly named but is implied by 'documents open in Word.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Resize an inline image to width_pt, aspect ratio kept.' It also identifies how the target image is selected ('image_index from list_images'), which clearly distinguishes this from related image tools like replace_image or set_image_alt_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage context by directing the agent to obtain image_index from list_images and by noting that documents open in Word are refused. It does not name alternative tools or explicitly say when to use an alternative, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full disclosure burden and handles it well. It discloses one-shot semantics, Word clearing the flag, backup behavior including rotation skip when backup=False, atomic validated save, and refusal when the document is open in Word.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler. The core action is front-loaded, followed by backup behavior and the refusal guard. Every clause adds useful information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no annotations, this is nearly complete: flag lifecycle, backup side effects, persistence model, and a key error condition are all present. A small gap remains in documenting file_path expectations, but the output schema relieves the need to describe return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 gives strong semantics for backup ('backup=False skips rotation only') and implies on/off behavior through 'Toggle'. However, the required file_path parameter is only indirectly covered by 'documents open in Word', with no path format or location detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact operation: toggling 'update all fields on next open', with the one-shot qualifier. This clearly identifies the target resource and distinguishes it from nearby tools like com_refresh_fields or insert_field.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear usage context: the flag affects only the next open and Word clears it after updating. It also states an explicit exclusion by refusing documents open in Word. It does not name alternatives, but no sibling shares this exact one-shot flag purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses side effects and constraints: literal data caches and embedded workbook, size and position defaults, color defaults, refusals for unsupported chart types/data shapes, backup rotation behavior, atomic save, and refusal to operate on documents open in Word. This is unusually thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The definition is long but front-loads the core purpose and packs defaults and constraints into dense sentences with no filler. A little restructuring into explicit parameter bullets would improve scannability, but every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 13-parameter tool with no annotations, the description covers the key decision points: chart type support, data schemas, placement, sizing, colors, backup, and open-document refusal. The output schema presumably handles return values. The only notable gap is the file_path parameter's role as the target document versus data file paths.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema descriptions are 0% covered, and the description compensates by defining chart_type values, three data shapes, width/height override semantics, position mutual-exclusion, color count, and backup flag behavior. It does not define title, legend, alignment, or explicitly clarify that the required file_path is the target document, so a couple of parameters still rely on their names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: inserting a native, theme-following Word chart built from data, and explicitly contrasts it with image rendering. The chart type list and data format details make the operation unmistakable and distinguish it from image or table tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context for when insertion is appropriate (native chart from data, not an image) and lists explicit refusals, but it never names sibling tools like update_chart_data or list_charts as alternatives for existing charts. That keeps it at 'clear context' rather than explicit alternative routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does so admirably. It reveals auto-backup behavior with specific slot locations, explains that backup=False only skips rotation, mentions atomic validated saves, and warns that documents open in Word will be refused. This is far beyond what the schema conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly compact and front-loaded: the core action appears first, followed by necessary behavior and caveats. Every clause earns its place, and there is no filler or repeated schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and no annotations are present, the description covers the essential invocation context well: what to insert, where to insert it, how indexing works, backup behavior, save semantics, and a critical refusal condition. An agent has enough information to correctly call this tool and anticipate side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions, so the description must compensate. It adds essential meaning by explaining that after_index is 0-based and applies to body paragraphs, and it clarifies the non-obvious backup=false nuance. file_path remains only implicitly understood from its name, but the key parameters receive meaningful elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Insert a page break'), a specific target ('after body paragraph after_index'), and the indexing scheme ('0-based'). This clearly differentiates it from related tools like add_section_break or insert_paragraphs without needing to open the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: whenever a page break is needed after a body paragraph, identified by a 0-based index. However, it does not explicitly state when to choose this over alternatives such as add_section_break, nor does it provide any 'use instead' guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses read-only semantics, the precise list of checks, a subtle contrast-detection rule ('skipped, not guessed when either side is absent'), and the output shape (location, fix hint, per-category counts, pass flag).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the key read-only and audit intent, then efficiently packs the full scope of checks and result details into a compact paragraph. Every sentence earns its place, including the final pointer to fix_accessibility.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema, the description is complete. It covers what is audited, how ambiguous cases are handled, what each finding contains, what the summary reports, and which sibling handles repairs. The existence of an output schema removes the need to describe the return structure in prose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has only one parameter, file_path, with 0% schema description coverage. The tool description does not add any detail about accepted path formats, file types, or meaning. The parameter name is self-explanatory enough for basic invocation, but the description provides no additional semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Audit') and resource ('accessibility'), then enumerates the exact checks performed: heading hierarchy, image alt text, table header rows, contrast, document title, and generic hyperlink text. It also distinguishes itself from the sibling 'fix_accessibility' by explicitly marking this as read-only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies this is the read-only auditing step and points to fix_accessibility for repairs ('fix_accessibility repairs opted-in categories'), giving the agent a natural when-to-use context. It does not, however, explicitly discuss when not to use it or contrast it with validate_document or other validation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations supplied, the description carries the full burden. It states the tool is read-only, explains how color hex values are compared, and discloses that theme-indirected colors are classified as 'unverified'—a useful edge-case disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and information-dense; the example JSON conveys structure more efficiently than prose. The read-only note is at the end rather than front-loaded, but every sentence adds necessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return-value details need not be explained. The description covers the main rule, key edge cases, and safety behavior. It relies on check_template_compliance for the remainder of the ruleset, which is reasonable because that tool is available in the sibling list.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description compensates by providing an example rules JSON object and explaining the colors sub-rule in detail. It references the shared ruleset schema for fonts rather than re-documenting everything, which is acceptable given the sibling reference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific function ('brand-guide compliance') and clarifies that it shares its engine with check_template_compliance while adding a colors rule. This clearly distinguishes it from the sibling and avoids tautology.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly relates this tool to check_template_compliance, giving the agent a basis for deciding which compliance check applies. It stops short of stating exhaustive when-not conditions, but the contextual signal is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the behavioral burden. It discloses auto-backup behavior, the backup=False exception, atomic validated saving, and refusal for Word-open documents. This goes well beyond a bare 'update' statement, though it does not detail error responses or validation specifics.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the primary action, and each sentence provides essential information. There is no filler or repetition of schema details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with an output schema, the description covers the key behavioral context: addressing, backup, atomic save, and a concrete refusal condition. An agent has enough information to call the tool correctly in most scenarios.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 and constraint of note_id vs position ('exactly one'), clarifies that position is 1-based, and interprets backup=False as skipping rotation. It does not explicitly explain file_path, but the core ambiguous parameters are addressed.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Rewrite') and resource ('a footnote's text'), and clarifies the addressing modes ('note_id or 1-based display position'). This clearly distinguishes the tool from siblings like edit_endnote or delete_footnote.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context on how to target a footnote and explicitly warns that Word-open documents are refused. It does not explicitly name alternatives such as edit_endnote, but the usage context is strong enough for an agent to decide when to invoke it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so very well. It discloses that the operation is read-only, that collisions with existing files cause refusal before any writes, how naming works, and what metadata each result reports. This is unusually transparent behavior disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences, each earning its place: extraction scope, naming scheme, special media handling, reported metadata, collision safety, and read-only status. The core purpose is front-loaded and the rest is organized detail with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, the description is complete: it covers what gets extracted, how outputs are named, how unusual media sources are handled, what each result reports, collision behavior, and safety. The presence of an output schema means return fields need not be spelled out further.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 output_dir's role, prefix semantics ('prefix replaces image'), and the naming convention tied to list_images index. file_path is only implicitly the document path, but the overall meaning is largely recoverable from the description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: 'Extract every image in the document to files in output_dir.' It clearly distinguishes itself from siblings like list_images by focusing on extraction to files rather than listing or modifying images.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool: when you need image files extracted from a document, named and saved to a directory. However, it does not explicitly contrast itself with alternatives such as list_images, so an agent must infer the selection criteria from the verb and resource.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It declares 'Read-only,' explains that inherited values are not synthesized and must be followed via based_on, and documents that exact/atLeast line spacing and theme font/color references are omitted. These are concrete behavioral constraints beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: scope, returned fields, shape compatibility, cloning workflow, inherited-value behavior, omission caveat, and read-only status. It is front-loaded with the core purpose and uses subsequent sentences for essential caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a one-parameter schema and an output schema, the description covers everything an agent needs to invoke correctly: what is listed, what is omitted, what is not synthesized, and the safety profile. It is complete for a read-only list tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter, file_path, with no description and 0% schema coverage. The parameter name is self-explanatory, but the description adds no guidance about path semantics or expected document context. It does not compensate for the low schema coverage, though the simplicity of the parameter limits the practical impact.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with a specific verb and resource ('List the styles defined in the document') and enumerates the exact fields returned (id, name, type, based_on, formatting). It clearly distinguishes this read tool from sibling style-writing tools like define_style and apply_style by framing the output in terms of what define_style accepts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it is for reading style definitions, and for template cloning it explicitly notes 'one read + one define.' It does not explicitly name alternatives or say when not to use it, but the define_style relationship and inheritance caveat give an agent enough guidance to choose it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and explicitly states 'Read-only,' which is important behavioral context. It also discloses scope limitations: body-level tables only and the meaning of table_index relative to list_tables order. It does not cover error behavior for invalid indices, but the read-only disclosure and scope constraints are substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded: core behavior first, then indexing semantics, then routing to sibling tools, then read-only confirmation. Every sentence serves a distinct purpose with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a two-parameter schema and an output schema already present, the description covers everything needed to invoke correctly: what is read, how to identify the table, the body-level limitation, the nested-table alternative, and the safety profile. No critical operational detail is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 valuable semantics for table_index: 0-based and in list_tables order. However, file_path is not elaborated beyond its name, so one of the two parameters still relies on inference rather than explicit documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource pairing: 'Read one body-level table in full,' and enumerates exactly what is included. It is clearly distinguished from get_nested_table by the body-level qualifier, so an agent can pick it without reading sibling schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states the precise use case: reading complete body-level tables, keyed to list_tables order. It explicitly names get_nested_table as the alternative for tables nested in a cell and names set_cells/set_cells_block as the write counterparts, leaving no ambiguity about when to use this tool vs alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well: it discloses placeholder rendering until field update, prerendered cite shaping, auto-backup rotation semantics, atomic validated save, and refusal of documents open in Word. This is substantial behavioral context beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: core action, parameter effects, usage warning, backup behavior, and failure precondition. It is front-loaded with the central operation and keeps supporting detail compact.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers prerequisites, rendering behavior, backup, save semantics, and a key failure mode. An output schema exists, so return-value detail is not required. It could be slightly more explicit about what happens when no anchor match exists, but overall it is complete enough for safe invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 tag ('stored source'), occurrence ('occurrence-th anchor_text match'), anchor_text, backup ('backup=False skips rotation only'), and mentions pages/prefix/suffix/suppress flags as shaping the rendered cite. It does not fully define exact formatting of pages or prefix/suffix, but it adds real meaning the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Insert a CITATION field for a stored source' and explains the tag comes from add_source/list_sources. It also distinguishes this from Zotero/Mendeley/EndNote citation handling by warning about mixing citation systems, which separates it from insert_zotero_citation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs to 'Run detect_citation_system first on unfamiliar documents' and explains why mixing systems is problematic. It does not explicitly name alternatives like insert_zotero_citation, so the routing is clear but not fully exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral disclosure. It explicitly states 'Read-only against the document,' details the exact per-chart fields including supported_for_update with refusal reasons, and explains chartex naming. This goes well beyond the minimum.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, then packs every relevant detail into a single, well-structured sentence block. No filler or repetition; the length is justified by the richness of the output.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers scope, ordering, output fields, downstream usage, refusal reasons, and safety. An output schema exists to formalize return structure, so nothing essential is missing for an agent to invoke this correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no description for file_path (0% coverage), and the tool description never mentions it. Its role is inferable from the tool name and 'document' references, but the description does not explicitly state that file_path identifies the target document. Minimal viable, but a clear parameter definition would be better.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb and resource: 'Enumerate every chart in the document body, in document order.' It clearly distinguishes this from siblings like list_tables and add_chart, and the output fields are precisely scoped to chart inspection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear usage context: the returned index is explicitly linked to update_chart_data, and the read-only nature implies safe inspection. It does not list alternatives or exclusion conditions, but for a listing tool this is sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It states 'Read-only,' explains that equations exist outside the plain-text layer, and clarifies that the index is an opaque handle for later deletion. This is strong disclosure for a listing tool, though it does not mention ordering, pagination, or edge-case behavior such as documents with no equations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences with no wasted words. It front-loads the action and scope, adds a crucial cross-tool note, and ends with the safety hint. Every sentence carries information needed for correct selection and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter list tool with an output schema available, the description is complete: it documents scope, expected return fields, relationship to other tools, and read-only behavior. Nothing an agent needs to decide whether to call this tool or to interpret the result is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter, file_path, has zero schema description coverage. The description refers to 'the document' but does not explicitly define file_path's format, requirements, or how it is used. While file_path is self-explanatory, the description does not add meaningful parameter-level semantics beyond what the parameter name already implies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'List every equation in the document' and enumerates the exact coverage (body, tables, footnotes, endnotes) and output fields (index, display vs inline, location, plain-text approximation). It also distinguishes itself from get_text and find_text by explaining that equations are not in the plain-text layer, so the purpose is unambiguous and differentiated from siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'THIS is how equation content is read' and names get_text and find_text as alternatives that cannot see equations. It also reveals that the returned index is the handle delete_equation takes, giving the agent clear guidance on when to call this tool and how its output feeds into another operation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses destructive permanence, backup/undo behavior, scope handling, always-scrubbed areas, non-examined content like images and charts, verified_clean re-scanning, atomic error handling, and refusal of open documents. This is exemplary behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Despite the length, every sentence carries a distinct operational fact relevant to safe invocation: what is redacted, what is skipped, how backups work, failure guarantees, and irreversibility. The main action is front-loaded, and there is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, the description is remarkably complete: it covers scope, limitations, backup behavior, failure atomicity, verification, and open-document refusal. An output schema exists, so the description does not need to explain return shapes, and the mention of per-class counts and verified_clean fills the key reporting context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does 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 explain targets loosely ('[{find, regex?}]'), scope options, and backup behavior, but it does not document file_path or replacement semantics in the description, and the targets structure remains ambiguous about whether `regex?` is a boolean or a regex string. Partial compensation only.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Permanently REMOVE matched text' and explicitly contrasts true redaction with highlighting ('not highlighted'), making the operation and its intent unmistakable. It also distinguishes this tool from search/replace-style siblings by emphasizing permanent removal and post-redaction verification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly conveys when to use this tool: when permanent redaction is required, not reversible highlighting or replacement. It also warns that the operation is irreversible and refuses documents open in Word. It does not explicitly name alternative sibling tools, but the context is sufficiently clear for an agent to select it appropriately.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden and does it well. It discloses live-editing behavior, keys that are refused while live, the auto-backup mechanism in `.ks4w-backups`, `backup=False` semantics, and atomic validated saving. It also explains that `outline_level: null` removes the override without touching style or visual formatting.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but front-loaded, beginning with the core action and target. The outline_level explanation and backup sentence are packed with important context, though the backup sentence is somewhat compressed and could be structured more cleanly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with a nested formatting object and no annotation safety net, the description covers the key inputs, operation, live limitations, backup behavior, and a differentiating use case. It stops short of fully specifying allowed value sets for all formatting keys, but an output schema exists to absorb return-value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 useful semantics: indices are 0-based, it lists the meaningful formatting keys, and it explains the outline_level range, null behavior, and backup flag. It does not define accepted values for keys like alignment or line_spacing, or clarify the `live` parameter's value semantics beyond 'auto'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description starts with a specific verb and resource: 'Set paragraph formatting on a batch of paragraphs' using '0-based indices.' It also distinguishes itself from `apply_style` by explaining when outline_level should be used without changing style/visual formatting, and names `get_paragraph_format` as the matching reader.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit usage scenario for `outline_level`: assigning template headings a place in Word's navigation pane and TOC harvesting where `apply_style` would change their look. It also notes live-editing restrictions. However, it does not broadly contrast with other paragraph-related tools such as `format_text` or `replace_paragraph_text`.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden. It explicitly states 'Read-only.' and describes the return object, adding concrete behavioral context beyond the tool name. It does not cover error behavior or file lock requirements, but for a read-only package-level check this is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tightly packed sentences. The primary purpose and scope are front-loaded, the return shape is given inline, and sibling routing comes at the end. Every clause earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
A simple one-parameter read-only tool with an output schema; the description covers its purpose, scope, return values, and alternatives. Nothing an agent needs to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. The single parameter file_path is not explicitly described, but the phrase 'the package opens' and the overall context make it clear the argument is the document file to validate. It adds minimal detail beyond the schema, but the obviousness of a single path parameter keeps it at a viable level.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb ('Run') and resource ('quick structural check'), then enumerates the exact checks performed: package opens, footnote/endnote consistency, and field marker balance. It also names sibling tools (diagnose_document, com_validate_opens_clean) and clarifies what this tool is not, making differentiation instant.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: it is a quick structural check, while diagnose_document is for deep multi-check health reports and com_validate_opens_clean is for Word's own verdict. This tells an agent exactly when to select this tool versus the two most similar siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
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 thoroughly defines what counts as 'unfilled' and explains the default behavior when `required` is omitted. The word 'Report' implies a read-only operation, though it does not explicitly state that no document modification occurs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with no wasted words. The core action and scope are front-loaded, followed by specific detection criteria and the `required` parameter's default behavior. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and only two parameters, this description is complete. It defines unfilled fields precisely, explains the optional parameter's semantics, and clearly states the default behavior. Nothing essential is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 explain the `required` parameter in detail: it lists field names for stricter checking, and its absence means every field is checked. `file_path` is not described but is self-evident from the tool's purpose and the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Report unfilled form fields' with concrete detection criteria (empty text, placeholder text, unchecked checkboxes, missing fields). This clearly distinguishes it from siblings like list_form_fields, which would list all fields, and fill_form_fields, which would modify them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: whenever completeness of a form needs to be reported. It does not explicitly name alternatives or state exclusions, but the operation is well-scoped and easily differentiated from validation tools like validate_document or prepare_for_submission.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the mechanism ('fresh attach'), the three concrete effects, the safety profile, and that it reports what was fixed. It could add what side effects a fresh attach might have on unsaved document state, but it is materially transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with 'Recovery tool,' then the condition, the fixes, and the report behavior. Every word earns its place and nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter repair tool with an output schema, the description covers the purpose, when to run it, what it fixes, safety, and reporting. There is no missing information an agent needs to decide to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description does not need to document any. Baseline 4 applies because there is no parameter surface for it to clarify or compensate for.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific recovery verb and names the exact resource and failure modes: a crashed live edit leaving Word frozen, alerts suppressed, or an undo record open. It clearly distinguishes this as a repair tool rather than a general document or live-edit tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the triggering condition ('if a crashed live edit left...') and explicitly says 'Safe to run anytime.' It does not name alternatives or exclusions, but the recovery condition and broad safety guidance give clear usage context for a 0-parameter tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers strong behavioral detail: per-file atomicity, validated saves, failure handling, stop_on_error semantics, preservation of already-saved files, and refusal of files open in Word. This goes well beyond what the schema or parameter names alone convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: purpose and example first, then the operations contract, allowed tools, and per-file behavior. Every sentence adds operational value, and there is no filler or repetition of schema content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex batch tool with no annotations, the description covers the critical invocation details: how to structure operations, which tools are allowed, failure semantics, and file-open refusal. It falls slightly short on fully explaining backup behavior and the phrase 'prev/anchor slot rotation,' which may be domain-specific jargon that an agent would not understand without further context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 operations array format ('[{'tool': name, 'params': {...}}]'), the file_path exclusion, and the allowed-tool whitelist, and it also gives stop_on_error behavior. However, the backup parameter is never described, which is a notable gap given the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Apply the same operations to MANY documents in one call,' with a concrete example (updating a footer across 50 templates). This clearly distinguishes it from the long list of sibling tools that act on single documents or single operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes the intended use obvious: batch repeated operations across many documents, and it lists exactly which tools are allowed inside the batch. It also gives an important exclusion ('Refuses files open in Word') but does not explicitly state when NOT to use it, such as for one-off single-document edits.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full behavioral disclosure burden and does so well: it details the parsing approach for PNG/JPEG/GIF, the comparison logic, the min_dpi flagging behavior, format-specific outputs for EMF/WMF and other formats, and explicitly states 'Read-only'. There is no hidden mutation or undefined format handling.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but carefully structured: a one-line summary is followed by the calculation method, format-specific behavior, domain context, and a read-only safety note. Every sentence contributes operational or decision-relevant information with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the calculation method, threshold semantics, format edge cases, domain benchmark, and read-only nature; the existing output schema accounts for the return shape. The only minor gap is that it never explicitly states that file_path is the path to the document whose embedded images are being inspected.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description explains min_dpi as the threshold below which images get flagged and relates it to the 300 DPI publishing standard, adding value beyond the bare integer schema. file_path is not explicitly described as the path to the containing document, but the tool's purpose and reference to 'part bytes' make that role inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise statement of what the tool computes: effective print resolution (horizontal and vertical DPI) for every image in the document, based on native pixel size versus displayed size. This clearly differentiates it from siblings like list_images, resize_image, replace_image, and extract_images, none of which assess print resolution.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when the tool is relevant by mentioning that publishers typically require 300 DPI for print figures, and it explains how different image formats are classified. It does not name an alternative tool to use instead in specific situations, but no sibling has overlapping resolution-checking functionality.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations to lean on, the description carries the full burden and does so well. It discloses auto-backup slot behavior, the exact effect of backup=False, atomic validated saving, and refusal when the document is open in Word.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each contributing essential information with no fluff. The action and addressing modes are front-loaded, followed by side effects and constraints.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers what the tool does, how endnotes are targeted, backup behavior, save guarantees, and a key safety condition. Minor gaps remain around what happens if both note_id and position are supplied, but the output schema handles return expectations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates meaningfully: it explains note_id vs. position addressing, 1-based positions, and the backup flag's rotation behavior. file_path is not described, but it is self-explanatory from the tool name and document context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object — 'Rewrite an endnote's text' — and clearly states two addressing modes. It is distinct from sibling tools like edit_footnote and add_endnote because it is explicitly scoped to endnotes and existing text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context of use is clear: this is for rewriting an existing endnote's text. It does not explicitly name alternatives or exclusions, but the domain-specific wording makes the intended use obvious enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers: it explains effective-style reporting, live vs file style naming differences, textbox entry behavior (source 'textbox', box_index used by set_textbox_text, body indices untouched), and equation invisibility. This is substantial behavioral insight beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence carries necessary information: return shape, slicing semantics, textboxes, live-mode behavior, and the equation exclusion. It is dense but efficient, with no filler or tautology. The most important information appears first.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists, return value details need not be repeated. The description covers non-obvious behaviors thoroughly. Minor gaps remain, such as how 'contains' matching works (case-sensitivity, substring) and exact behavior of the 'live' parameter, but these are edge cases rather than central calling requirements.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters itself. It does explain start/end slicing (0-based, exclusive), contains filtering, include_textboxes semantics, and live vs file behavior well. However, the 'live' parameter's accepted values and interaction with 'auto' are not fully specified, and file_path is left to obvious inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb+resource: 'Read body paragraphs'. It also explains the return shape and explicitly notes that equations are not included, pointing to list_equations. This clearly distinguishes it from siblings like get_document_info or list_equations even without naming them all.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: file-mode vs live mode, and the file-mode-only condition for include_textboxes. It also explicitly routes equation needs to list_equations. However, it does not state when to prefer alternatives like get_outline or find_text, so it stops short of full when/when-not coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It explicitly declares the operation read-only, discloses the full scope of what is read, lists the reported fields, and notes the 'where determinable' limitation on anchoring paragraph indices. This is strong behavioral disclosure beyond any structured metadata.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four focused sentences cover scope, output fields, alternative routing, and read-only status. Every sentence earns its place; there is no filler, and the most important usage distinction is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has one parameter and an output schema, the description is complete: it explains what is read, where it is read from, what each result contains, why this tool is preferable for this use case, and that it is read-only. The only slight gap is file_path documentation, but that is minor against the overall completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain the file_path parameter at all. While file_path is a common and somewhat self-explanatory parameter, the description adds no meaning beyond the schema and does not compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: reading text from every text box / shape text frame across body, headers, and footers, covering both modern and legacy VML. It clearly differentiates itself from get_text by explaining exactly why get_text is unsuitable for box content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly tells agents to use this tool instead of get_text for box content, explains the failure mode of the generic tool, and names set_textbox_text as the complementary write tool that shares the box_index address. This gives clear when-to-use and when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers substantial behavioral detail: in-place overwriting, exact row/grid-column matching with refusal and shape reporting, merged-cell anchor handling, rejection of merge-covered values, backup rotation behavior, atomic validated save, and refusal for documents open in Word. This goes well beyond what the schema alone conveys.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but not bloated; every clause adds operational value. It front-loads the purpose and then packs the mode, constraint, merge, and backup behaviors into compact sentences. A slight structural split between 'creating' and 'overwriting' could improve scannability, but there is no wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex tool with seven parameters, no annotations, and zero schema descriptions, this description is highly complete: it covers supported data sources, insertion/overwrite behavior, validation rules, merged-cell semantics, backup behavior, atomicity, and error conditions. Because an output schema exists, return-value documentation is unnecessary.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 all seven parameters. It explains the data input formats, the role of table_index, the meaning of at_end/after_anchor for insertion position, has_header for the header row, and backup=False for skipping rotation. The main ambiguity is that file_path itself is not explicitly described as the target document path, though it is strongly implied.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Fill a table from data', then enumerates the supported input forms and the two core modes (create new table vs overwrite existing). It clearly distinguishes this tool from creation-only or cell-setting siblings such as create_table, set_cells, and export_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly frames when to use which mode: without table_index a new table is created; with table_index the existing table is overwritten. It also notes the Word-open refusal condition. However, it does not directly name alternatives or state when not to use this tool versus related table manipulation tools, leaving some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well. It discloses the SDT-wrapped field structure, page-number update timing, auto-backup slot behavior, backup=False nuance, atomic validated save, and refusal of documents open in Word.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core purpose, then packs essential operational details into a few dense sentences. No redundant phrases; every clause contributes behavior or parameter context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no annotations, the description covers safety (atomic save, backup, open-document refusal), refresh behavior, and the key levels parameter. Placement semantics (at_start, after_index) are only implied, and existing-TOC behavior is not addressed, but an output schema exists and most critical context is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates for the most important parameters: levels ('1-3' picks heading depth), update_on_open (automatic on next open), and backup (backup=False skips rotation only). It does not explain title, at_start, or after_index, but their names and schema defaults make them reasonably inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Insert a Table of Contents' — a specific verb and resource — and adds 'SDT-wrapped TOC field' for technical precision. This clearly differentiates it from siblings like read_toc, delete_toc, and insert_caption_list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives actionable context: page numbers require a field update, either via update_on_open or 'immediately via com_refresh_fields', and it warns that the tool 'refuses documents open in Word', an important exclusion. It does not explicitly contrast with read_toc/delete_toc, but the main usage conditions are clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does this well by disclosing that the cursor is read once, never moved, and the user's selection is untouched, plus the newline behavior and unsupported document areas. This gives the agent a clear model of side effects and limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the main action, followed by scope, behavioral guarantees, alternative routing, and prerequisite. Every sentence contributes necessary information without padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, return-value detail is unnecessary. The description covers what the tool does, where it operates, what it does to the cursor/selection, the main alternative, and the key prerequisite. The only meaningful gap is the missing semantic explanation of file_path as the identifier for the open document.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema descriptions are at 0% coverage, so the description must compensate. It explains the newline parameter ('ends the insertion with a paragraph break') and implicitly defines text as the inserted content, but it does not explain file_path beyond requiring the document to be open in Word. There is also no clarification of whether text may contain multiple paragraph breaks or how path resolution works.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Insert text at the user's cursor position in the open document.' It also draws a clear boundary by saying headers/footers/footnotes are not supported, which separates it from other insertion tools. The naming of insert_paragraphs as the alternative further disambiguates its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool versus an alternative: 'Use insert_paragraphs for index-addressed insertion instead.' It also gives the prerequisite that the document must be open in Word, which is actionable guidance for invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does substantial work: auto-backup behavior, backup=False semantics, atomic validated save, and refusal to modify Word-locked documents. The backup slot path and 'rotation only' detail add real behavioral context, though 'prev/anchor slots' is somewhat opaque.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler. The primary operation and alternative are front-loaded, followed by backup and safety behavior. Every sentence contributes information an agent needs.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists and no annotations are present, the description covers the key operational traits: block semantics, backup behavior, atomicity, and document lock refusal. It is complete enough for an agent to select and invoke the tool safely, though some details like coordinate bounds are left unspecified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 origin_row/origin_cell as the starting coordinates, data as a 2D block of values, and backup's behavioral meaning. file_path and table_index are not elaborated but are sufficiently self-descriptive from their names and schema structure.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Write a 2D block of values starting at (origin_row, origin_cell)'. It clearly distinguishes itself from set_cells by describing the block write vs scattered single-cell edit use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly routes the agent: 'for scattered single-cell edits use set_cells'. This is a direct when-to-use vs alternative instruction, and the Word lock refusal adds another usage boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full disclosure burden. It exceeds that burden by revealing several important behaviors: creation of note infrastructure, auto-backup behavior in .ks4w-backups with backup=False semantics, atomic validated save, and refusal on Word-open documents.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the primary action. Every clause earns its place: positioning, infrastructure creation, backup behavior, save semantics, and the Word-open refusal. There is no filler or repeated schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the absence of annotations, the description covers prerequisites, side effects, error conditions, and data-integrity behavior. An output schema exists, so return values need not be described. Nothing essential for correct invocation and expectation-setting is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 so well for tricky parameters: 'occurrence-th match' explains occurrence, 'anchor_text' is described as the search/match target, and backup=False is clarified as skipping rotation. However, file_path and note_text are left to naming/semantic inference rather than explicit explanation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Add a footnote anchored after the occurrence-th match of anchor_text.' This clearly distinguishes it from related tools like add_endnote, edit_footnote, and delete_footnote by describing the exact operation and positioning behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool: adding new footnotes, anchoring by occurrence, and auto-creating required infrastructure. It also explicitly notes a refusal condition ('Refuses documents open in Word'). However, it does not explicitly name alternatives for endnotes or for editing/deleting existing footnotes, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden. It discloses auto-backup behavior with prev/anchor slots in .ks4w-backups, clarifies that backup=False skips rotation only, mentions atomic validated save, and states that documents open in Word are refused. These are exactly the side-effect and safety details 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact: three sentences front-load the action, then the alternative, then the key side effects. Every clause carries distinct useful information, with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and 5 parameters with zero schema descriptions, the description covers the core operation, matching semantics, a relevant alternative, backup behavior, save behavior, and a critical lock condition. An output schema exists, so return-value documentation is not required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It clarifies 'find' as the searched text, 'style' as a named character style, and 'occurrence' as the match number; backup semantics are also explained. 'file_path' is not explicitly described, though its name makes it self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Apply'), a specific resource ('named character style'), and a precise target ('text range (occurrence-th match of find)'). It also differentiates itself from format_text by noting that direct formatting without a style should use that sibling tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a clear alternative: use format_text for direct formatting without a style. It does not explicitly contrast with apply_style or list exhaustive exclusions, but the character-style scope and mention of the alternative are enough to guide basic selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so richly: it mentions auto-backup behavior, the meaning of backup=False, atomic validated save, refusal to touch documents open in Word, preservation of unmatched styles, and that content is untouched. This is substantially more transparent than typical tool descriptions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded: core purpose first, then import-styles framing, then backup and safety behavior. Every sentence adds useful information, and no filler is present.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 4-parameter tool with no annotations and no parameter descriptions in the schema, this description covers purpose, parameter semantics, backup behavior, content safety, success guarantees, and an important failure condition (refuses documents open in Word). An output schema exists, so return-value details are not needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 maps 'reference document' to reference_path, 'this document' to file_path, 'optionally page geometry' to include_page_geometry, and 'backup=False skips rotation only' to backup. It does not enumerate each parameter by name, but the mapping is sufficiently clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Restyle this document to match a reference document,' then lists concrete aspects (styles, theme, fonts, layout, optionally page geometry). It clearly distinguishes itself from sibling tools like apply_style and fill_template by framing it as template-based restyling and style import.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use it: when restyling a document to match a reference or importing style definitions from another document. It does not explicitly name alternatives or state when not to use it, but the purpose is specific enough that an agent can infer the appropriate use case.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it clearly discloses the operation is 'Read-only'. It also explains the ok flag behavior ('goes False on any broken or stray field marker') and the preservation-only behavior for EndNote and Mendeley, which goes beyond the schema and output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description front-loads the main action and output, then adds behavioral notes and a read-only declaration in a compact three-sentence structure. 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read-only integrity check with an output schema, the description supplies the needed context: when to run it, what managers are relevant, what the ok flag means, and preservation-only behavior. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has a single 'file_path' parameter with 0% description coverage. The description compensates by referring to 'a document containing Zotero, EndNote, or Mendeley citations', so the parameter's role is inferable. A score above 4 would require explicit path-format or edge-case info, which is not present.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Check') and resource ('reference-manager citations after an edit'), and further clarifies the exact output: 'counts by manager and kind plus an ok flag'. It names Zotero, EndNote, and Mendeley, which helps distinguish it from generic validation or citation-parity tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage timing ('Run it after editing a document containing Zotero, EndNote, or Mendeley citations') and adds preservation-only nuance for EndNote and Mendeley. It does not enumerate when not to use it or name sibling alternatives, but the provided context is clear enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well. It discloses the invisible Word instance, full-fidelity output behavior, the default pdf_path behavior, that the source .docx is never modified, and the Word installation requirement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the core action, and every sentence adds value: mechanism, fidelity details, default path, side-effect guarantee, and prerequisite. 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.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter export tool with an output schema, the description covers the essential call requirements: input path, optional output path behavior, source-modification guarantee, and external dependency. The output schema can handle return-value details, so nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 explicitly explains pdf_path's default and relationship to the source filename, and the phrase 'source .docx' effectively identifies file_path as the input document. It does not spell out every path-format detail, but the two parameters are meaningfully clarified.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Export the document to PDF'), states the mechanism ('invisible Word instance'), and clarifies fidelity behavior with concrete elements like fields, footnotes, TOC, headers/footers, and images. This distinguishes it clearly from sibling operations such as com_import_pdf or export_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear operational context: exporting via Word, default output naming, and the prerequisite that Word must be installed. It does not explicitly name alternatives or say when not to use this tool, but the context is strong enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses the invisible Word instance, default output location, refusal to overwrite existing files, package-level validation, OCR limitations, and the explicit warning on near-zero word count.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient and front-loaded with the core action, then expands to output behavior, validation, and caveats. Every clause provides necessary information without repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a conversion tool with no annotations, the description covers the operation, output handling, failure safety, validation, and realistic limitations. It gives an agent enough to select and invoke the tool correctly without needing to inspect internals.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, so the description must compensate. It explains the output_path default behavior and existing-file refusal, and it makes clear the required pdf_path is the source PDF. It could tie the semantics to parameter names more explicitly, but it adds meaning well beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific action ('Convert a PDF to .docx') with the mechanism ('Word's built-in PDF reflow') and the resource involved. It clearly distinguishes this from the sibling com_export_pdf by stating the directionality (PDF to .docx, not .docx to PDF).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when conversion is appropriate by distinguishing text-based PDFs from complex layouts and scanned image PDFs. It does not explicitly name an alternative tool for unsupported inputs, so it stops short of full when-not guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden. It explicitly states 'Read-only on every file,' which is the key side-effect disclosure, and also discloses matching semantics, keying behavior, provenance, and collision handling beyond what the input schema shows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is four tight sentences, front-loaded with the core purpose, then adding distinct facts: keying, provenance, collision detection, matching precondition, and read-only behavior. Every sentence earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-parameter tool with an output schema, the description covers the operation's purpose, matching semantics, preconditions, and safety profile. The presence of an output schema relieves the description of explaining return structure. Nothing an agent needs to select and invoke this tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 that file_paths refers to multiple documents/copies to merge, that they should share draft text, and that merging matches anchored spans verbatim. It does not specify path format, but the single self-descriptive parameter and the strong contextual description make this sufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: merge the reviewer matrix across several documents. It also explains the data model (keyed by author and anchored text, per-file provenance, collision detection), which clearly differentiates it from sibling tools like comment_report and com_merge_documents.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a concrete usage context (e.g. three committee members' copies of the same draft) and a prerequisite (copies should share draft text, anchored spans match verbatim). It does not explicitly name alternatives or state when not to use this tool, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the no-op condition ('Does nothing if Word is not running or the file is not open') and the prerequisite ('Requires Word installed'), which are critical behavioral traits. It doesn't detail edge cases like authentication or overwrite prompts, but the core behavior is transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each earning its place: purpose first, usage second, no-op and prerequisite last. No fluff, no repetition, front-loaded with the primary action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter tool with an output schema present, the description is complete: it explains what the tool does, when to use it, when it is a no-op, and what it requires. An agent has everything needed to decide to call it and to interpret a silent failure.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It does so by framing file_path as the document Word has open, and the no-op clause adds that the file must be open. Though it doesn't explicitly say 'file_path is the path to an open document,' the meaning is strongly implied and operationally useful.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('SAVE') and resource (a document Word has open), with a clear purpose: flushing edits to disk so file-based tools can read the current state. The description distinguishes this from siblings like com_close_open_document by emphasizing persistence to disk.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'Use before diagnose_document or any file-mode tool that needs the latest edits flushed to disk.' This is a concrete, actionable routing rule that names a sibling and a category of alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and satisfies it thoroughly. It explains style matching, numbering, image/hyperlink re-registration, footnote/endnote IDs, bookmark remapping, OLE/ActiveX refusal with no partial application, source-file immutability, auto-backup behavior, atomic validated save, and refusal on documents open in Word. This is exemplary disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence contributes substantive detail, and the primary action is front-loaded. The description is long, but the complexity of the tool justifies most of the length. It is dense and uses many parentheticals, which slightly impairs quick scanning, but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, 7 parameters, no annotations, and an output schema that covers return values, the description is highly complete. It explains parameter semantics, failure modes (OLE refuses whole copy), safety guarantees (source never modified), backup behavior, and operational constraints (refuses open Word documents). Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters, and it does. table_index is defined with source-scoped 0-based indexing, after_index is contrasted with paragraph-only index used by other tools, after_anchor requires full plain text and rejects recurring matches, at_end is described, and backup semantics are clarified. Even source_path/target_path are inferable from the first sentence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Transplant ONE table from source_path into target_path.' It further disambiguates itself as the 'single-element sibling of insert_document,' distinguishing it from copy_document and other table-related tools. This clearly identifies the tool's unique scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: copying one table between documents while reusing insert_document's resource reconciliation. It names insert_document as a sibling and gives precise target-position semantics. It does not explicitly list exclusions or direct comparisons with copy_document or split_table, so it falls just short of full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and uses it well: it discloses refusal to overwrite, automatic parent-directory creation, and the blank nature of the file. It does not mention whether the file becomes active in an open Word session, but the most important safety and side-effect behaviors are covered.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight, front-loaded sentences with no filler. The core action leads, followed by overwrite refusal and the alternative, then the downstream workflow. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity, two-parameter tool with an output schema, the description fully covers purpose, exclusions, side effects, and next steps. It names the relevant sibling for overwriting and the population tools, giving an agent enough to invoke and continue correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 title as an optional core property and implies file_path is the destination .docx path through the tool's stated purpose. Some detail is left implicit, but the two parameters are simple and adequately contextualized.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Specific verb and resource: creates a new blank .docx file, optionally setting the title core property. It distinguishes itself from copy_document by explicitly stating it refuses to overwrite, and from population tools by describing them as follow-up actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear when-to-use guidance: for creating new blank files, not overwriting. It explicitly names copy_document with overwrite=True as the alternative, and directs the agent to use insert_paragraphs, create_table, define_style, etc. afterward, providing both exclusion and workflow context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: it discloses drift verification, all-or-nothing restoration, mismatch listing, that the mapping file is intentionally left on disk, backup behavior including backup=False semantics, atomic validated save, and refusal for Word-open documents. This is exceptionally transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences convey the core action, the safety mechanism, the post-restore file state, backup behavior, save guarantees, and a hard refusal condition. There is no filler; every clause adds operational value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the operation's risk profile—restoring anonymization changes—the description covers failure modes, side effects, persistence of the mapping file, backup rotation, atomicity, and an open-document constraint. Output schema exists to cover return values, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 mapping_path ('default <name>.anonymization.json beside the document') and backup ('backup=False skips rotation only'). file_path is not explicitly elaborated, but the document-centric context and 'beside the document' phrasing make its role sufficiently clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Reverse anonymize_for_review using its mapping file', naming the exact verb, resource, and the sibling operation it undoes. It clearly distinguishes this tool from every other document tool in the sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description positions the tool as the direct inverse of anonymize_for_review and gives the default mapping file location, making the intended context clear. It does not explicitly list 'do not use when X applies', but the paired-operation framing plus the refusal conditions ('Refuses documents open in Word') provide strong usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full behavioral burden, and it delivers: it explains paragraph removal for display equations, inline equation handling, backup slot rotation behavior, atomic validated save, and refusal to operate on Word-open documents. This is far beyond what the schema alone reveals.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficiently organized: primary action first, then display/inline nuance, then backup and safety behavior. Every sentence contributes distinct operational knowledge, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, the description covers the main deletion semantics, backup behavior, edge cases for paragraph removal, and safety constraints. An output schema exists, so return-value documentation is not required from the description. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 gives real meaning to 'index' as a list_equations index and to 'backup' via the auto-backup explanation and 'backup=False skips rotation only.' file_path is not explicitly described, but its role is inferable from the operation. Overall, substantial semantic value is added over the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Delete an equation by its list_equations index.' It distinguishes display vs inline equation deletion and clearly identifies the selection mechanism, making its purpose unambiguous and distinct from equation-documenting siblings like list_equations and add_equation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use it: to delete an equation identified by the index returned from list_equations. It also gives a clear exclusion condition: 'Refuses documents open in Word.' However, it does not explicitly name alternatives or state 'when not to use,' so it falls just short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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, and it does so thoroughly. It reveals the destruction-blocking behavior, the force override, backup rotation semantics, atomic validated saving, and refusal when the document is open in Word. This is exemplary for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, information-dense, and every clause contributes actionable information. The main action is stated first, followed by safety and backup nuances. No filler or redundant restatement exists.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with no annotations, this description covers the key decisions an agent needs: when deletion will be refused, how to override, backup behavior, save atomicity, and the Word-lock constraint. An output schema is present, so the absence of return-format details is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 schema's silence. It meaningfully explains tag and force, and clarifies backup=False behavior. However, file_path is a required parameter with no description in either the schema or the tool description, leaving its exact role and format to inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Delete a bibliography source by tag.' This clearly identifies what the tool does and distinguishes it from sibling tools like add_source, list_sources, and insert_bibliography. The reference to tag-based lookup adds specificity without ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description conveys clear usage context: deleting a source by tag, with behavior conditioned on whether the source is cited and whether force=True is set. It also warns about documents open in Word. However, it does not explicitly name alternative tools or state when to prefer this over related bibliography operations, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description shoulders the behavioral disclosure burden. It discloses auto-backup behavior, the nuance of backup=False, atomic validated save, and refusal on documents open in Word — substantial and useful behavioral detail 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and front-loaded with the core action, then packs the key behavioral caveats into a short reminder. No filler or repeated schema information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a destructive tool with three parameters and no annotations, it covers the mutation, backup behavior, atomicity, and a key operational failure condition. An output schema exists, so return-value details are not required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 table_index's source and backup's effect, but leaves file_path implicit and the backup rotation semantics somewhat terse.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete'), the target ('a whole table'), and the parameter source ('table_index from list_tables'). This differentiates it from sibling row/column operations like delete_rows and delete_columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives clear context by specifying the table_index comes from list_tables and emphasizes 'whole table', implying row/column/partial deletion belongs elsewhere. However, it does not explicitly name an alternative or state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 discloses auto-backup behavior with .ks4w-backups prev/anchor slots, the nuance that backup=False only skips rotation, atomic validated saves, and refusal when documents are open in Word. This is exemplary transparency for a destructive mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three dense sentences with no filler. The primary purpose is front-loaded, followed by safety and backup behavior. Every clause earns its place, packing significant semantic and behavioral information compactly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the operation's core mechanics (indexing via read_toc), side effects (backup, atomic save), parameter nuances, and a key refusal condition (open in Word). Since an output schema exists, return-value documentation is not needed. This is complete for an agent to call the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 'which' parameter as an index into read_toc's tocs list and clarifies the 'backup' parameter's behavior with 'backup=False skips rotation only'. The 'file_path' parameter is self-evident from context and the schema's required field.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Delete one TOC-family field by index'. This clearly distinguishes it from sibling delete tools like delete_source, delete_table, and delete_columns. The reference to 'read_toc's tocs list order' further anchors what is deleted and how the target is identified.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies a prerequisite: the caller should obtain the index from read_toc's tocs list before invoking delete_toc. This gives clear contextual guidance for using the tool. It does not explicitly name when-not-to-use or alternative tools, but the read_toc dependency is a meaningful usage signal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden; it discloses auto-backup behavior, backup=False semantics, atomic validated saves, file vs live Word editing, and locale/language mapping nuances. These are meaningful behavioral traits beyond what schema alone provides.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Dense but every clause earns its place: formatting keys, targeting logic, sibling routing, backup behavior, and live-editing caveat are all packed into a compact definition. The most important action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter mutation tool with no annotations, this description provides target resolution, formatting semantics, backup/live behavior, and an alternative tool pointer. An agent has enough context to select and invoke it correctly, especially with an output schema present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 formatting object's keys in detail, defines the three targeting modes, clarifies occurrence's role, and explains backup=False's meaning. The 'live' parameter is only indirectly touched and file_path is assumed self-evident, but coverage is strong overall.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action and resource: 'Apply character formatting to a text range', then enumerates the exact formatting keys it accepts. It also explicitly routes named character styles to apply_character_style, distinguishing it from the closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear selection criteria for targeting text (paragraph_index + find, find alone, whole paragraph) and an explicit alternative for named styles. It does not exhaustively contrast with paragraph-level formatting siblings, but the character-vs-style distinction is clearly conveyed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it explicitly states 'Read-only' and discloses the returned content types. It also explains the nested_index semantics clearly. It does not describe failure behavior for invalid host addresses, but the read-only guarantee is a strong 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two well-structured sentences: the first defines what is returned and how the tool is addressed, and the second points to the write sibling. Every sentence earns its place, and the most important scoping information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists and the tool is a read-only accessor, the description covers invocation context, indexing semantics, and the relevant sibling for writes. Nothing essential is missing for an agent to select and call this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 table_index, row, cell, and nested_index, including the meaning of 0 vs higher nested_index values. file_path is not described, though its meaning is reasonably inferable from the name and tool context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States the exact verb and resource: read a table nested inside a cell of a body-level table, returning rows, cells, text, and merge info. It also differentiates itself from get_table by explaining the addressing model, so an agent can distinguish it from the closest sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (for nested tables addressed by host table/row/cell/nested_index) and points to set_nested_cells as the write counterpart. It also implicitly distinguishes itself from get_table, which is for body-level tables rather than nested ones.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full disclosure burden and does so thoroughly: it declares read-only behavior, Word's resolution order, per-property source reporting ('explicit' | 'paragraph_style' | 'document_defaults' | 'word_default'), line_spacing rule encoding, and the has_numbering caveat for unresolved numbering indents. This is far beyond basic expectations for a read tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but densely packed, opening with the core purpose before explaining resolution behavior. Every sentence earns its place: property list, resolution order, source reporting, line_spacing special cases, the numbering caveat, and the write-tool counterpart all serve the agent's decision-making and invocation.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so the description appropriately focuses on non-obvious semantics rather than return shapes. It covers range semantics, inheritance resolution, source attribution, line-spacing units, and the numbering limitation, making the tool fully usable without external clarification.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description adds important parameter meaning: start..end is inclusive and end defaults to start. It does not individually explain file_path, but the schema already specifies its type and required status, and the omission is minor against the useful range semantics it does provide.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'Read' and resource 'EFFECTIVE paragraph formatting' with a precise paragraph range and an enumerated list of formatting properties. It distinguishes itself from set_paragraph_format as the read counterpart and from raw style tools by emphasizing resolution through the style basedOn chain and document defaults.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly frames when to use it via 'EFFECTIVE' formatting, distinguishing resolved values from raw style definitions, and points to set_paragraph_format as the write counterpart. It does not explicitly state 'use get_styles for raw styles instead' or list exclusions, but the intended selection context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries full responsibility for behavioral disclosure. It reveals key side effects: track changes recording, file-mode-only format cloning, auto-backup behavior, atomic validated saves, and live editing of Word-open documents. This goes well beyond a simple mutation statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and front-loaded, leading with the core operation and position modes. It is long, but nearly every clause adds necessary detail for a 12-parameter tool; a bit of restructuring into clearer lists would improve scannability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex insertion tool with no annotations and no schema parameter descriptions, the description is remarkably complete. It covers edge cases, parameter interactions, file-mode constraints, and persistence/backup behavior. The presence of an output schema means return-value details are not required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 thoroughly. It explains position parameters, the meaning of inherit_format vs copy_format_from and their mutual exclusivity, track/author behavior, backup rotation semantics, and per-item style precedence.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies a clear action and resource: inserting paragraphs at one of four explicit positions. The mention of position modes and anchor/index semantics distinguishes it from many sibling insert tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides strong within-tool guidance: anchors must be unique, index addressing is preferred for structural work due to recurring heading text, and fresh documents have an implicit empty paragraph at index 0. It does not name alternative sibling tools explicitly, so it stops short of full cross-tool routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well: it declares read-only status, heuristic parsing, per-entry parse_confidence (full/partial/failed), verbatim retention of failed entries ('will never be converted'), detection of Word-native vs third-party citation fields, and refusal behavior around text conversion. This goes well beyond a basic summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose and then layers in essential behavioral detail. Every clause earns its place: confidence levels, failed-entry handling, citation positions, field detection, and style_hint usage are all informative without being padded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only analysis tool, this description is complete: it explains what is parsed, what metadata is produced, how failures are handled, how style_hint affects behavior, and the no-mutation guarantee. The presence of an output schema means detailed return structure does not need to be repeated in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 meaningfully explain style_hint with concrete examples ('apa7', 'ieee', 'turabian') and its effect on parsing. file_path is not explicitly described, but its role as the manuscript path is strongly implied by the first sentence; still, a one-sentence clarification would make parameter semantics complete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Parse') and resource ('the manuscript's reference list ... and in-text citations') and states the output is 'a structured model.' It also positions itself as 'Read-only stage 1 of publication-style conversion,' which distinguishes it from the many conversion and citation-sibling tools by framing what it does and what it is a prerequisite for.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: this is the read-only first stage of publication-style conversion, and style_hint should be supplied when the source style is known to tighten parsing. It does not explicitly name sibling alternatives or state when-not-to-use it, so it stops short of a full 5, but an agent can infer the intended workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it delivers: it discloses auto-backup behavior, backup slot locations, the effect of backup=False, atomic validated saving, and refusal of documents open in Word. This is precisely the kind of side-effect and limitation information an agent needs for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences, front-loaded with the core purpose, followed by critical behavioral constraints and parameter nuance. No filler or repetition; every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutating tool with an output schema present, the description covers the action, the inverse relationship, backup behavior, save semantics, and a key environmental refusal condition. Nothing essential is missing for an agent to select and invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 the backup parameter by explaining rotation behavior and the .ks4w-backups slot mechanism. The required file_path parameter is not described explicitly, but its purpose is clear from the tool name and action; the backup semantics are the part that needed elaboration.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific action ('Lift the editing restriction') on a specific resource, and explicitly names the sibling tool that created the restriction. This distinguishes it unambiguously from set_document_protection and get_protection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use it—when an editing restriction set by set_document_protection needs to be removed. It references the relevant sibling, but stops short of explicit when-not-to-use or alternative routing beyond that implied inverse relationship.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the disclosure burden and does so well: auto-backup slots, backup=False's exact effect, atomic validated save, and refusal for Word-open documents. This goes beyond what the input schema or parameter names reveal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three short clauses pack purpose, backup behavior, and a hard failure condition with no filler. The purpose is front-loaded, so an agent scanning the first words immediately understands the action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers action, required input provenance, backup side effects, failure condition, and atomicity. Since an output schema exists, return-value documentation is not required, and no critical information is missing for selecting and invoking this tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates for the nontrivial parameters: comment_id must come from get_comments and backup=False only skips rotation, not backup itself. Remaining parameters like text, author, and file_path are reasonably self-explanatory from their names and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description opens with a specific verb+object ('Add a threaded reply') and scopes it to an existing comment, with comment_id provenance pointing to get_comments. This clearly distinguishes it from sibling comment tools like add_comment, resolve_comment, and delete_comment.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
States the prerequisite comment_id source and gives operational conditions: backup semantics and refusal when Word has the document open. It does not explicitly name the alternative use case for add_comment, so full when/when-not guidance is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations present, the description carries the full burden and does so thoroughly: it discloses the max_replacements abort-all behavior, tracked-change recording, live one-Ctrl+Z-step behavior, unsaved state, automatic backup rotation, atomic validated saving, and handling of Word's 255-char fragmented-run limitations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense and information-rich, with the core purpose front-loaded. Every sentence adds value, but the wall of text could be slightly better structured for scannability; it is nonetheless efficient for a tool with this complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, zero annotations, and output schema being present, the description covers the critical operational context: safety across fragmented runs, scope, dry-run via preview_replace, live editing side effects, backup rotation, and document state. Nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 replacements structure, scope values, max_replacements semantics, track/author, backup=False behavior, and live mode behavior, giving agents enough to call the tool successfully without extra inference.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific action and resource: 'Batch find/replace, safe across Word's fragmented runs.' It also explicitly names and differentiates sibling tools (replace_formatted, replace_paragraph_text, preview_replace), so an agent can immediately understand what this tool uniquely does.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It names alternatives and their scopes, which helps an agent choose between tools, but it does not provide fully explicit when/when-not rules such as 'use this for broad replacements across scopes, or use replace_formatted for formatting-specific text.' Still, the sibling contrasts and preview_replace pointer give clear practical guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses read-only behavior ('database is never modified'), point-in-time snapshot semantics, exclusions (attachments, notes, trashed items), and search matching restrictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Each sentence adds a distinct, decision-relevant fact: scope, matching rules, return fields, exclusions, database default, and snapshot caveat. There is no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, query semantics, output fields, exclusions, configuration, and data freshness limits. With an output schema present and only three parameters, nothing essential to invoke the tool correctly is missing; the limit behavior is the only minor omission and is reasonably inferable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining query matching semantics across title, creator, year, and publication, and by documenting db_path's default and nonstandard-data-directory usage. The limit parameter is not explicitly explained, though its name and default make its cap behavior inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Search the user's LOCAL Zotero library,' and immediately clarifies the read-only nature. It also names the consumer relationship to insert_zotero_citation, which distinguishes this tool's role among the large sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: this tool finds Zotero items and returns item keys that insert_zotero_citation consumes, so an agent knows when to use it. It does not explicitly list when-not-to-use or contrast with sibling search tools, but no direct alternative is present among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden, and it delivers: it discloses auto-backup behavior with slot rotation, the effect of backup=False, atomic validated saving, and refusal when the document is open in Word. This goes well beyond what the schema could express.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Three dense sentences with no filler: purpose comes first, followed by backup/save behavior and a hard failure condition. Every clause carries meaningful operational information, and the structure is front-loaded for quick agent parsing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters, no annotations, and an output schema that can cover return details, the description provides purpose, change semantics, backup behavior, save validation, and an important refusal case. An agent has enough context to invoke the tool correctly without needing to infer hidden side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the prose must compensate. It names all settable metadata fields and explains the backup flag's nuance ('backup=False skips rotation only') plus the incremental update semantics. It does not spell out every detail like null handling or file_path, but the parameter names are otherwise transparent.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Set core document metadata' and lists the exact fields (title, author, subject, keywords, category, comments). The File > Info context anchors it clearly, and it is easy to distinguish from the read-only sibling get_document_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'only the parameters given change' clearly communicates the incremental update behavior, which is essential for correct usage. It does not explicitly name alternatives or state when not to use this tool, but the scope is clear enough for an agent to select it over related metadata-reading tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses that existing header content is replaced and reported, watermarks are preserved, exact field codes are written, backups are rotated in .ks4w-backups, saves are atomic and validated, and the tool refuses documents open in Word.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well structured: core mechanism first, then option semantics, then side effects and safety behavior. Every sentence adds distinct value, and there is no filler or unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter document mutation with no annotations and an output schema, the description covers the mechanism, replacement behavior, reporting, backup rotation, atomic validated save, and open-file refusal. The only minor omission is alignment semantics, which is outweighed by the breadth and depth of the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description compensates by explaining level, include_number, scope ('auto' vs explicit section indices), first_page_blank, and backup semantics. Alignment is not explained, but most parameters receive meaningful operational detail beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific operation ('Put the current chapter title in the running header') and the exact mechanism (STYLEREF referencing the Heading style of level). It is clearly distinguishable from generic header tools like set_header and from validation tools like validate_chapter_headers.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use the tool: any time chapter titles should appear in running headers, using the standard STYLEREF mechanism and avoiding per-chapter section breaks. It does not explicitly name sibling alternatives or state when not to use it, so exclusion guidance is missing but implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so thoroughly. It discloses the exact splitting rule, front-matter naming, preservation of styles/numbering/settings/fonts/themes, stripping of other sections' note definitions and image parts, round-trip validation, filename format behavior, source safety, and refusal to overwrite existing outputs.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence contributes a distinct fact: purpose, splitting rule, special front-matter case, preservation and stripping behavior, validation, filename examples, and safety guarantees. It is front-loaded with the primary purpose and contains no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex document-splitting tool with no annotations and 0% schema coverage, the description is complete. It covers the operation, splitting boundary rule, output naming, style fidelity, content stripping, validation, and both source and destination safety. An agent has enough information to invoke it correctly, and an output schema is present for return-value details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 `level` semantics ('Sections start at each heading of `level` (or higher)') and `filename_from` with concrete examples ('heading' gives 01_Heading Text.docx, 'index' gives 01.docx). `file_path` and `output_dir` are not explicitly defined, but their meanings are clear from context and the safety statement about refusing existing output files.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource: 'Split a document into one standalone .docx per heading section.' It immediately distinguishes this from other tools by calling itself 'the inverse of com_merge_documents' and by focusing on heading-based section splitting rather than table splitting or other partition operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: use this to split documents by heading sections, and it explicitly names the sibling tool com_merge_documents as the inverse, plus notes that no Word is needed. It does not explicitly state when not to use it or name alternatives besides the merge counterpart, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so well. It explicitly declares "Read-only," states that unknown zone names are rejected, reports the total/included/excluded invariant, and notes that detected zone locations are returned for review.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense, with the core purpose front-loaded in the first sentence. Every subsequent sentence adds useful detail: allowed exclusions, return shape, invariant, tokenization parity, and read-only status.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only counting tool, the description covers the essential operational knowledge: what can be excluded, how totals relate, how tokenization behaves, and what is returned. The presence of an output schema further covers return structure, so little is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by enumerating the allowed exclude values and their rejection behavior. The `file_path` parameter is only indirectly referenced via "word_count's file mode," but its meaning is self-evident from the required parameter name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource phrase, "Count words minus named zones," and lists the exact zones that can be excluded. This clearly distinguishes the tool from the sibling `word_count` and explains the journal-specific purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The context is clear: this is the tool to use when a journal-style count excluding references, captions, footnotes, and other named zones is needed. It also references `word_count`'s file mode for tokenization parity, but it does not explicitly state when to prefer the plain `word_count` alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it excels: it discloses that the document is NOT modified on unconvertible LaTeX, that equations are invisible to text-finding tools, that backup behavior is automatic unless backup=False, and that Word-open documents are refused. It also details specific side effects such as align* being rewritten to aligned. This is unusually transparent and covers failure, safety, and persistence behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but every sentence carries operational weight: native math vs image, display/inline modes, supported TeX repertoire, error/safety guarantees, interaction with text tools, backup behavior, and open-document refusal. There is no filler or repeated verbosity; content is dense and front-loaded with the core purpose before expanding into modes and caveats. For a 9-parameter tool, this length is warranted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and zero annotations, the description is remarkably complete: it covers input format, positioning rules, occurrence semantics, supported math constructs, failure behavior, read-back strategy, backup behavior, and a refused precondition. The output schema exists, so return-value documentation is not required from the description. An agent has everything needed to invoke this tool correctly and predict side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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. It explains the semantic roles of display, after_index, after_anchor, at_end, anchor_text, occurrence, backup, and latex content, including the 'exactly one of' positioning constraint and the occurrence-based match behavior. Only file_path is left to obvious inference, which is acceptable. This fully 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.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Insert a LaTeX equation as NATIVE Word math,' and immediately clarifies it is 'not an image' and is editable in Word's equation editor. It further distinguishes itself by explaining that equations are invisible to get_text/find_text and should be read with list_equations. An agent can confidently tell this apart from sibling insertion tools such as add_image or insert_paragraphs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for when to use this tool: when native, editable LaTeX math is needed, with explicit display and positioning semantics. It also gives a complementary alternative for reading equations ('read them with list_equations') and notes a hard constraint ('Refuses documents open in Word'). However, it stops short of explicitly stating when not to use this tool in favor of alternatives like add_image or insert_paragraphs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and discharges it exceptionally. It discloses exact masking transforms with an example, the reference-entry rewrite format, that prose is FLAGGED and never auto-edited, the side-effect mapping file (default name, never overwritten, must stay private), backup slot behavior, atomic validated save, and the Word-open refusal. This goes far beyond what any annotation schema would convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every clause earns its place: the BETA warning is front-loaded, the core purpose and reversibility come second, then specific transforms, the safety boundary, side effects, backup behavior, and refusals. The length is proportionate to the tool's complexity and contains zero filler or restatement of the name.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter mutation tool with no annotations, the description covers preconditions (Word-open refusal), side effects (mapping file, backups), safety (heuristic warning, never auto-editing prose, private mapping), and behavior in full. An output schema exists, so return-value explanation is not required; the reference to 'flagged-items list in the result' suffices to direct the agent to the key output.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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. author_names is explained ('Masks self-citations by the named authors'), backup is explained ('backup=False skips rotation only'), replacement is illustrated by the 'Hurd (1999)' -> 'Author (1999)' example, and mapping_path is explained with its default filename and never-overwrite guarantee. Only file_path is left to inference, and it is self-evident.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource — 'Anonymize a manuscript for double-blind peer review, reversibly' — with a clear distinguishing property (reversibility) that separates it from irreversible siblings like redact_text, and names its reverse counterpart deanonymize_document. The scope (self-citations, reference entries, metadata) is explicit enough that an agent cannot confuse it with other document tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context: this is for double-blind peer review where reversible anonymization is needed, pairs with deanonymize_document, and warns the agent to review the flagged-items list rather than trust output silently (BETA heuristic). It does not explicitly enumerate alternatives or state when NOT to use it, but the conditions for correct use and the failure precondition ('Refuses documents open in Word') are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full behavioral burden and does so thoroughly: it discloses insertion at START, page-break and section-break behavior, default page numbering, conditional refusal, backup rotation semantics, atomic validated save, and the Word-open refusal. This goes well beyond a simple operation summary.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but information-dense and front-loaded: the core action and key placement behavior appear in the first line, and the spec example is a necessary structural reference. No sentence is filler; each adds a distinct behavioral or parameter detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (which covers return-value documentation), the description still reports what the tool returns and which numbering applies to which sections. It also covers safety behaviors (backup, atomic save, refusal conditions), so an agent has everything needed to call it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 does: it gives a complete example spec structure with section kinds, fields, and page_numbering settings, explains title-page line centering and abstract heading styling, and clarifies backup=False semantics. The 'force' flag is mentioned even though it is absent from the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Assemble long-document front matter in one call', and immediately distinguishes itself from piecemeal sibling tools by stating the requested sequence is inserted at the START with existing content becoming the body. This makes the tool's role unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly communicates when to use the tool: to assemble front matter in a single call, and it states refusal conditions (existing leading TOC or lowerRoman section, documents open in Word) unless force is true. However, it does not explicitly name alternative tools for fine-grained control when a full assembly is not needed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so excellently. It discloses read-only behavior, optionality of rule keys, rejection of unknown keys, the exact return shape, resolution through basedOn/docDefaults, and the fact that theme-indirected fonts are never guessed and instead land in 'unverified'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The purpose is front-loaded, and every sentence adds value. The ruleset example is large but necessary because the schema is just an object with additionalProperties true. The description remains focused and ends with a useful 'Read-only.' note.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is complete for a tool of this complexity: it covers the return structure, parameter semantics, resolver behavior, edge cases like unverified fonts, and safety. The output schema is present, and the description's extra return-field detail further strengthens completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 provides a complete ruleset example that gives real meaning to the opaque 'rules' object, and it explains unknown-key handling. The 'file_path' parameter is self-evident from its name and required status.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Validate the document against a formatting ruleset' with concrete application contexts (university dissertation guide, journal style sheet). This clearly separates it from generic validation and document-checking siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage context is clear: use when a document must be checked against a custom formatting ruleset. It does not explicitly name alternatives or provide when-not-to-use guidance among the many validation-related sibling tools, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for disclosing side effects and safety. It explicitly states 'Read-only' and 'No file_path needed,' and it explains the meaning of each interactive_state value, including 'blocked if a long operation is running.' This gives the agent a clear behavioral model without needing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact yet information-dense: purpose, state values, per-document details, usage guidance, parameter clarification, and read-only safety are all included in a few sentences. The most important identification and usage information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given a zero-parameter input schema and the presence of an output schema, the description fully covers what the agent needs: what the tool checks, what the state values mean, when to use it, and that it is non-destructive. 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.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and 100% schema coverage, so there is little for the description to add. It still proactively clarifies 'No file_path needed,' which prevents an agent from assuming a required file-path argument based on sibling tools. This is useful semantic guidance beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a clear verb and resource: 'Check whether Word is running and what state it is in.' It then enumerates the exact state values (ready, busy, blocked, not_running) and the per-document information returned, which makes the tool's purpose unmistakable and distinguishes it from document-editing siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Use before live editing to confirm Word is responsive, or to discover which files are locked,' which gives concrete, actionable usage context. It does not state exclusions or name specific alternative tools, so it falls just short of the highest bar.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility for side effects. It discloses Word's automatic renumbering, the backup slots and rotation behavior, atomic validated saving, and refusal to run while Word has the document open—strong coverage for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four tightly packed clauses deliver core operation, parameter rules, and side effects with no filler. Information is front-loaded: operation first, then selection semantics, then behavioral caveats.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a five-parameter mutation tool with no annotations, the description covers selection semantics, renumbering, backup behavior, save atomicity, and the Word-open refusal. The existence of an output schema relieves it from documenting return values.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description compensates by defining direction's allowed values, the note_id/position selection rule for one note vs all, and the backup flag's precise effect. file_path is left to self-evidence, which is acceptable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The opening clause "Convert footnotes to endnotes or back" names a precise operation and resource, immediately distinguishing it from sibling footnote/endnote tools. The direction syntax and one-note-vs-all scoping make its function unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly instructs when to supply note_id or position (ONE note) and when to omit them (ALL), which is the central usage decision. It doesn't name alternative tools, but no sibling performs the same conversion, so the context is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly: it discloses that the document is never modified, that existing output files are refused, that output_path=None returns inline data, and how merged/nested cells behave.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but efficient, front-loading the core purpose and then covering edge behaviors. Every sentence adds meaningful information with no filler or repetition of schema fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is moderately complex, but the description covers output formats, merge handling, nested-table behavior, file-vs-inline output, overwrite refusal, and non-modification. Since an output schema exists, return-value details do not need to be duplicated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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: format is tied to CSV/JSON, include_merges is defined with concrete topology fields, output_path is explained with inline vs file semantics, and table_index is linked to list_tables.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: exporting a body-level table to CSV/JSON as a rows x grid-columns matrix. It clearly distinguishes this from generic table readers like get_table or list_tables by framing the output as an export artifact.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly scopes usage to body-level tables found via list_tables and explains key behavioral options. It does not explicitly name alternatives or exclusions, but 'body-level' and 'list_tables index' give an agent enough context to route correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and delivers: 'Pure guidance: reads nothing, changes nothing' is an explicit side-effect disclosure. It also transparently describes the two output modes based on whether task is supplied.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact, front-loaded with the tool's purpose, and every sentence adds necessary operational detail. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter, an output schema, and a clear behavioral profile. The description covers both calling modes, lists the known task names, and states the no-side-effect guarantee, making it complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description fully compensates. It explains that null lists available tasks, supplies the exact valid task names, and clarifies what task='<name>' returns. This is exactly the semantic depth the schema lacks.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific function: providing recommended tool sequences for common multi-step tasks, with a one-line rationale per step. It also distinguishes this from the many document-manipulation siblings by framing it as pure guidance rather than an operation on the document.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit call patterns: no task lists available tasks, and task='<name>' returns that task's sequence. It clearly identifies the context for use, though it does not explicitly name 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.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses dirty writes, placeholder behavior, backup rotation semantics, atomic validated saves, allowlist refusal of unsafe codes, and refusal to operate on documents open in Word.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place: action, anchor semantics, code examples, validation, dirty-write behavior, backup behavior, and refusal conditions. It is front-loaded with the primary purpose and adds no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 6-parameter mutation tool with no annotations, the description is exceptionally complete: insertion mechanics, parameter details, validation, persistence semantics, backup behavior, and an open-document failure mode are all covered. An output schema exists, so return-value detail is not needed here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates by explaining after_anchor literal-text matching, occurrence selection, field_code validation and examples, backup behavior for backup=False, and the placeholder parameter's temporary display role. This adds substantial meaning beyond the bare schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Insert a generic Word field right after after_anchor text', and reinforces meaning with concrete field_code examples. It distinguishes this from siblings like insert_citation, com_refresh_fields, and list_fields by emphasizing generic field insertion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context for use: generic Word fields, anchor-based positioning, and an allowlist restricting to known-safe field types. It does not explicitly name alternatives or when-not-to-use cases, but the phrase 'generic Word field' and validation rules make the intended use reasonably clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden and does so richly. It discloses the resulting placeholder text, the need for Refresh, auto-backup behavior, atomic save, read-only access to Zotero, and refusal conditions. No major side effect is left ambiguous.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence carries operational meaning, with the core action and field type front-loaded. It avoids filler and does not simply restate the input schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex, 9-parameter tool, the description covers workflow, side effects, failure modes, and safety context well, and an output schema exists so return-value details need not be repeated. Minor gaps remain around optional parameters such as occurrence and db_path, which keeps it from being fully exhaustive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, yet the description compensates by mapping item_keys to search_zotero_library, page to locator, prefix/suffix to attached text, and backup to rotation-only behavior. It does not explain occurrence or db_path, but the most semantically important parameters are well covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a precise operation: 'Insert a REAL Zotero citation field (ADDIN ZOTERO_ITEM CSL_CITATION) after anchor_text,' and explicitly distinguishes it from generic citation insertion by noting it is built exactly as the Zotero Word plugin builds it. This clearly separates it from siblings like insert_citation or add_source.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives explicit workflow guidance: item_keys come from search_zotero_library, detect_citation_system should run first on unfamiliar documents, and multi-item citations are refused rather than guessed. It also states preconditions such as 'only ever read' the Zotero database and refusal of documents open in Word.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it delivers detailed behavioral disclosure: destructive operations are enumerated ('accept all tracked changes,' 'delete all comments'), content-preservation guarantees are stated, refusal conditions are given (protected documents, open in Word), and backup/atomic-save behavior is specified. This is exceptionally transparent for a mutation-heavy operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds needed operational detail; there is no filler. The main purpose and scope are front-loaded in the first sentence, and the remaining sentences cover exceptions, reporting, backup, and save behavior without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a six-parameter, no-annotation tool, the description covers intended scope, side effects, safety (content preservation, atomic save), refusal cases, backup semantics, and reporting. An output schema exists, so the description need not enumerate return fields; what remains is complete enough to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 six parameters. It does: backup behavior is described, keep_title is explicitly tied to 'title kept unless keep_title=False,' scrub_metadata is detailed with author/last-modified-by/company, accept_revisions and remove_comments are covered by the opening sentence, and file_path is implied through 'Refuses documents open in Word.'
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ('Prepare a manuscript for submission') and enumerates the concrete operations it performs: accept tracked changes, delete comments, scrub metadata. This clearly distinguishes it from single-purpose siblings like accept_revisions or delete_comment by framing it as the one-call submission pipeline.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'in one call' plus the explicit list of bundled operations gives clear context for when an agent should select this tool over individual editing tools. However, it does not explicitly name alternatives or state when NOT to use it, such as 'if you only need to accept revisions, use accept_revisions instead.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden, and it excels. It discloses refusal modes, the 'nothing changed' guarantee, auto-backup behavior, atomic validated saves, and the refusal of documents open in Word. This is far beyond minimal mutation-tool disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but tightly organized: addressing first, then type rules, then refusal cases, then backup behavior. Every sentence adds actionable information and no space is wasted.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given five parameters, no annotations, and 0% schema coverage, the description covers all the high-stakes facts an agent needs: how to select the control, valid value types, failure conditions, backup semantics, atomicity, and environment restrictions. An output schema exists, so return-value details need not be restated.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description compensates thoroughly: it explains the tag/index exclusivity, the string/boolean/option type mapping for value, and the exact semantics of backup. Only file_path's obvious meaning is not elaborated, but the critical parameter semantics are fully covered.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise verb and resource: 'Set one content control's value.' It immediately clarifies the two addressing modes (tag or list_content_controls index) and states 'exactly one', which distinguishes it from sibling tools like list_content_controls and insert_content_control.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It clearly explains how to use the tool: address by tag or index, provide the right value type per control kind, and use backup=False only to skip rotation. It also gives strong when-not-to-use guidance by listing locked controls and unwritable types that are refused. It does not name an alternative tool to substitute, but the context is explicit enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses important behaviors beyond the schema: auto-backup to prev/anchor slots, the nuance that backup=False only skips rotation, atomic validated save, and refusal to operate on documents open in Word. Since no annotations are provided, this fully carries the behavioral transparency burden.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized, front-loading the core purpose and then adding behavioral caveats in a compact way. Every clause adds useful information and there is no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex nested write operation with seven parameters and no annotations, the description covers the addressing model, edit payload, backup semantics, failure condition, and save behavior. Since an output schema exists, the description does not need to explain return values, making it complete enough for correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description compensates well by explaining the key semantics: edits is a list of row/cell/text objects, the host cell is addressed by table_index/row/cell, and nested_index selects among multiple nested tables. It also clarifies the backup parameter's behavior beyond the schema's Boolean default.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: writing cells inside a nested table, and clearly distinguishes this from the many sibling table-editing tools by emphasizing NESTED and host-cell addressing. The mention of edits shape and nested_index makes the operation concrete and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly signals the intended context: use for nested tables, where the host cell is identified by table_index/row/cell and nested_index selects among several nested tables. It does not explicitly name an alternative like set_cells or state when not to use this tool, so it provides clear context without explicit exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and covers behavioral traits in detail: style/run preservation, newline splitting, mc:Fallback rewriting, refusal of non-text content, backup rotation semantics, atomic validated save, and refusal when the document is open in Word.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The main action is front-loaded and every subsequent sentence adds a distinct operational constraint or behavior. The description is dense but no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description covers selection, formatting behavior, content restrictions, backup behavior, save semantics, and failure conditions. The output schema can handle return-value details, so nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, but the description compensates: text semantics are defined ('\n' splits into paragraphs), backup behavior is clarified (backup=False skips rotation only), and box_index is sourced from get_textbox_text. file_path is left to its self-explanatory name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object: 'Replace the text of one text box.' It further clarifies the target resource by referencing 'box_index from get_textbox_text', which distinguishes this from paragraph-level tools like replace_paragraph_text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The prerequisite is explicit: the caller needs a box_index from get_textbox_text. The description also gives clear usage conditions for special content and Word-open states, though it does not explicitly name alternative tools for when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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, and it delivers thoroughly. It discloses that the embedded workbook, literal caches, and range formulas are rewritten together, that formatting is preserved, that an auto-backup is made, that backup=False only skips rotation, that saves are atomic and validated, and that the tool refuses documents open in Word.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause earns its place: core action first, then parameter semantics, then refusal conditions, then backup and safety behavior. The use of colons and semicolons packs substantial detail without filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the description is complete: it covers supported chart types, data constraints, series-count restrictions, refusal reasons, backup behavior, formatting preservation, and the Word-open refusal. Since an output schema exists, not detailing return values is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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. It clarifies that data must match add_chart's shapes and must preserve the series COUNT, explains series_names as renames, identifies chart_index as coming from list_charts, and explains the backup parameter's precise semantics. This adds essential meaning beyond the generic anyOf schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a precise verb and resource: 'Replace the data of an existing bar/column/line/pie/scatter chart in place.' It clearly distinguishes this from adding a new chart and ties chart_index to list_charts, making it easy for an agent to know exactly what operation this tool performs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives strong contextual guidance: it tells the agent the chart must already exist, the index comes from list_charts, data shapes mirror add_chart, and it enumerates refusal conditions (combo, 3D, series-count changes, ragged data, documents open in Word). However, it does not explicitly state 'use add_chart for new charts' or name an alternative for unsupported cases, so the routing guidance is strong but slightly implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral disclosure burden. It states the tool is read-only, explains that live counts use Word's ComputeStatistics/status-bar engine while file mode counts whitespace tokens, and warns that the two can differ. It also flags live per-section counts as best-effort mirrors, which is exactly the kind of non-obvious 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense, purposeful sentences. The core purpose is front-loaded, then mode behavior, then the sibling alternative in a concise warning. There is no repetition or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderately complex counting tool with no annotations and no schema descriptions, the description covers purpose, modes, limitations, read-only behavior, and the key alternative. It stops short of fully specifying the live parameter's 'auto' semantics and what counts include/exclude, but an output schema exists and the provided context is solid enough for correct selection and basic invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 schema's silence. It maps by_section to 'per heading section,' explains the 'live' parameter's two modes, and gives context for file_path. However, it does not explain the 'auto' default for live or what triggers each mode, leaving some parameter semantics implicit.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb-resource combination: 'Count words/characters/paragraphs, total and per heading section.' It clearly distinguishes itself from its sibling word_count_with_exclusions by naming that alternative and its use case. An agent can understand exactly what this tool computes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit guidance on when to prefer a different tool: 'For journal counts that exclude references, captions, or other zones, use word_count_with_exclusions.' It also clarifies the two operational modes (live Word engine vs. file mode), so the agent can choose based on whether the document is open.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and covers a lot: auto-created styles, backup rotation behavior, atomic validated save, and refusal to operate on documents open in Word. This goes well beyond the raw schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Four dense sentences with no filler: purpose, positioning, alternatives, and safety/backup behavior all earn their place. The most decision-relevant information is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter creation tool with no annotations and a large sibling set, it explains the core operation, the disambiguation guidance, positioning, backup behavior, and a critical refusal condition. The output schema can cover return shape, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 key parameters with the positioning trio (after_index, after_anchor, at_end), the anchor-matching caveat, level range, and backup=False semantics. It leaves file_path and text to their obvious meanings and does not fully define after_index semantics, so not perfect.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Insert a NEW heading paragraph', a specific verb and resource, and adds scope (level 1-9; Heading styles auto-created if missing). It also explicitly distinguishes itself from apply_style and change_heading_level, so an agent can tell the operation apart in the large sibling list.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use apply_style for restyling an existing paragraph and change_heading_level for shifting existing heading levels. It also advises preferring after_index for structural work because anchor matches are ambiguous given recurring heading text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 discloses auto-backup semantics, the meaning of backup=False, atomic validated saving, and that the tool refuses documents open in Word. This gives an agent realistic expectations about persistence, safety, and failure conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but well-organized: purpose first, then key parameter conventions, workflow guidance, and finally side-effect/failure behavior. Every sentence earns its place, and the structure keeps the dense content scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 21 parameters, no annotations, and no per-parameter schema descriptions, the description covers the critical context: what the tool adds, how it relates to citation workflow, prerequisite detection, backup behavior, and an important failure condition. The output schema exists, so not explaining return values is appropriate.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% parameter description coverage, but the description provides meaningful semantics for the most important parameters: tag, source_type, authors/editors, and backup. It does not individually describe every bibliographic field, but names like volume, issue, pages, and publisher are self-explanatory, and the description compensates for the schema's lack of detail on the highest-risk parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('Add a Word-native bibliography source to the document store') and immediately differentiates itself from related tools by naming insert_citation and insert_bibliography as the downstream consumers. This distinguishes add_source from sibling citation tools without requiring the agent to inspect their schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells the agent when to use this tool versus alternatives: cite with insert_citation, render with insert_bibliography, and run detect_citation_system first on unfamiliar documents. It also warns about the consequence of mixing citation systems, giving an agent clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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 discloses auto-creation of Heading1-9, auto-backup behavior with the prev/anchor slots, that backup=False only skips rotation, atomic validated save, and refusal of documents open in Word. This is strong, specific, and non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but compact: main behavior, disambiguation from siblings, and safety semantics are all covered in three sentences. It is front-loaded with the core purpose and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, return values need not be described. The description covers the core operation, sibling routing, backup behavior, save semantics, and a key failure condition (Word-open refusals). For a batch mutation tool with no annotations, this is remarkably complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 style ('by id or name'), indices ('a batch of paragraphs'), and backup semantics ('backup=False skips rotation only'). However, file_path is left completely implicit, and indices are not specified in terms of zero-based indexing or ordering.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a precise action ('Apply a paragraph style') and resource ('to a batch of paragraphs'), with the effect ('changing their full look'). It also distinguishes itself from sibling tools like set_paragraph_format and change_heading_level by naming what those tools do instead.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly names alternatives and the conditions for using them: 'To give a paragraph an outline level WITHOUT changing its appearance use set_paragraph_format's outline_level; to promote/demote existing built-in headings use change_heading_level.' This gives clear when-to-use vs. when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full transparency burden and does so thoroughly. It discloses that this is a 'BETA (heuristic)' converter, that unresolved items are 'left verbatim and flagged', that dry_run leaves the file 'byte-identical', that errors leave the original untouched, and that the tool refuses documents open in Word. Backup and atomic-save behavior are also explicitly described.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but appropriately dense for a complex, heuristic conversion tool. It front-loads the critical BETA warning, then covers scope, limitations, safety, backup, and exclusions in clearly separated sentences that each add actionable information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity, the lack of annotations, and the sparse schema, the description is remarkably complete. It covers supported conversions, what gets flagged, field-based exclusions, prerequisite detections, dry-run/backup/error safety, and open-document refusal. The presence of an output schema means the absence of a detailed return-value explanation is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by enumerating valid target styles, explaining dry_run behavior, and detailing backup semantics. However, it never explicitly names or documents the source_style parameter or its accepted values, leaving that somewhat to inference from default 'auto' and the conversion-direction examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Convert a manuscript's PLAIN-TEXT citations and reference list to a target publication style', and enumerates exact style names. It also distinguishes itself from nearby siblings by stating that citation FIELDS are 'routed away' to set_bibliography_style and that parse_references is the read-only stage 1.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: this is for plain-text citations and reference lists needing style conversion. It also names alternatives and exclusions: Word-native or Zotero/Mendeley/EndNote fields should go to set_bibliography_style or be restyled in the manager, and detect_citation_system should be run first on unfamiliar documents.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing side effects. It discloses the refusal-to-overwrite behavior, the backup rotation into '.ks4w-backups prev slot', and the reversibility via 'manage_backups restore'. This is strong behavioral disclosure for a mutation-like tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no filler. The main action and primary use case come first, and the overwrite/backup behavior second. Each sentence adds information essential to calling the tool correctly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose, alternatives, overwrite semantics, side effects, and reversibility. The presence of an output schema means return-value documentation is already provided elsewhere, so nothing essential is missing for an agent to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It meaningfully explains dest_path (explicit target, contrasted with create_snapshot's generated name) and overwrite (default refusal plus backup rotation). It does not explicitly define file_path as the source, though the tool name and parameter name make that reasonably inferable.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Copy'), a specific resource ('a document'), and the byte-for-byte semantics of the copy. It explicitly contrasts itself with create_snapshot ('create_snapshot names such a copy for you; this tool takes an explicit dest_path'), making its purpose distinct from its sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives a concrete use case ('before editing') and explains when to prefer the sibling alternative ('create_snapshot names such a copy for you'). It also clarifies the overwrite condition and the undo path, leaving little ambiguity about when this tool should be selected.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden, and it excels: it explains fragmented-run safety, formatting preservation, max_replacements abort semantics, auto-backup behavior, atomic validated save, and refusal to modify documents open in Word. This goes far beyond what the schema or annotations provide.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence earns its place. It leads with the core purpose, immediately clarifies scope of matching, and then packs in essential edge cases, exclusions, and safety semantics without repetition or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a high-complexity tool with 7 parameters, nested formatting objects, an output schema, and many sibling tools that overlap. The description covers selection criteria, replacement behavior, safety, sibling distinctions, output shape, and failure semantics. Nothing critical is missing for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 find (None vs literal), replace, max_replacements (cap aborts changing nothing), backup (backup=False skips rotation only), and the formatting criteria keys. However, it never explains the 'scope' parameter, which is non-obvious and has a default in the schema. This is a meaningful gap given the total absence of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource: 'Replace text ONLY where it carries specific EFFECTIVE formatting'. It also immediately distinguishes itself as 'the mutation twin of find_formatted', making its relationship to a sibling tool explicit. This is exactly the clarity needed for an agent to tell it apart from related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives precise behavioral when-to-use guidance: find=None replaces entire matching stretches; with find, only occurrences wholly inside a matching stretch. It also explicitly routes alternatives: 'No regex here (search_and_replace covers that)' and 'text boxes are never touched (set_textbox_text edits those)'. This is model guidance for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does so thoroughly. It discloses index-shift hazards, expect-based refusal, returned replaced_text, backup/rotation behavior, atomic validated saves, live-edit semantics, paragraph-mark preservation, and rejection of paragraphs with tracked revisions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence and clause adds operational value. The core purpose is front-loaded, followed by warnings, alternative routing, backup behavior, and live-mode constraints, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the essential hazards, safety measures, alternative tool routing, file/live mode behaviors, backup semantics, and tracked-change limitations. Since an output schema exists, enumerating return values is unnecessary; it even mentions the key returned field, replaced_text.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description gives operational meaning to index, expect, backup, new_text, and the file/live distinction. The main gap is that it never specifies the indexing base for the index parameter or the accepted values/meaning of the live parameter beyond general live-editing context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Replace one paragraph's full text', and adds preservation constraints ('keeping style and base formatting'). It also distinguishes itself from search_and_replace by naming the exact alternative, so an agent can tell them apart.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly states when to use search_and_replace instead ('text-anchored replacement immune to index shifts') and frames this tool as the fallback when search_and_replace's length limit is exceeded. The expect parameter is also recommended as a safety mechanism against index-shift mistakes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden and does so well. It discloses side effects (auto-backup into .ks4w-backups, atomic validated save), conditional behavior (backup=False skips rotation only), and a refusal condition (documents open in Word). This is unusually transparent for a mutating tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every element earns its place: the scope, the accepted values, boundary conditions, workflow advice, backup semantics, and safety behavior. The most important fact — what the tool modifies and how — is front-loaded, and the formatting is scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutating citation-formatting tool with no annotations, the description covers scope, alternatives, prerequisites, side effects, persistence behavior, and locking. The output schema handles return-value expectations, and the required parameters are covered by the input schema, so nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema parameter descriptions are absent, so the description must compensate. It adds meaningful semantics for style by enumerating all accepted values, and for backup by explaining rotation behavior when backup=False. file_path is only implied, but its name and the document-focused context make its purpose clear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does 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 the style Word-native CITATION and BIBLIOGRAPHY fields render in', followed by an exhaustive style list. It actively distinguishes itself from sibling tools by noting that plain-text citations use convert_citation_style and that manager-managed citations are outside its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use guidance: run detect_citation_system first on unfamiliar documents, and explains when not to use it — it only affects Word-native fields, while manager citations and plain-text citations have their own paths. This directly prevents misuse and routes the agent to alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden and does so well. It discloses that both files are treated read-only, that the diff is computed without Word, and that per-change detail is capped at detail_cap on huge diffs while counts remain complete. It also enumerates the full range of returned information.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause earns its place: core purpose, output components, cap behavior, sibling distinction, and read-only safety. It is front-loaded with the main action and the alternative tool, making the most important routing information immediately visible.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex diff tool with no annotations, the description covers what it returns, when to use it versus the sibling, the detail cap behavior, and the read-only safety profile. The presence of an output schema further reduces the need for the description to explain return value structure. Nothing critical is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does 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 explicitly clarifies detail_cap's behavior ('Per-change detail is capped at detail_cap entries on huge diffs'), which goes beyond the schema. old_path and new_path are only implied by 'both documents' and their schema names, leaving a small gap in explicit parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and object ('Diff two saved drafts agent-readably') and enumerates the precise output categories, so the agent knows exactly what the tool does. It also explicitly contrasts itself with com_compare_documents ('Deliberately NOT a redline'), distinguishing it from a closely related sibling.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives an explicit when-not-to-use rule: 'use com_compare_documents for a Word-rendered tracked-changes comparison.' It also states that the tool is read-only and computed without Word, which gives clear context for safe invocation among the large sibling toolset.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and meets it thoroughly. It discloses mutation semantics, subtree behavior, refusal conditions with no partial changes, backup rotation behavior, atomic validated save, and the 'refuses documents open in Word' constraint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds necessary operational detail. It is front-loaded with the core action, then moves logically through addressing, subtree behavior, refusal conditions, backup behavior, and Word-lock refusal.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite high complexity and no annotations, the description covers operation semantics, edge cases, error/refusal behavior, and backup handling. The presence of an output schema means return values need not be described. Nothing essential is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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. It explains the meaning of delta (-1/+1), the addressing modes (heading_text or paragraph_index), subtree=True semantics, and backup=False nuance beyond the raw schema types.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a precise operation, 'Promote (delta=-1) or demote (delta=1) a heading,' and specifies how headings are addressed (heading_text or paragraph_index). It also distinguishes itself from alternatives like set_paragraph_format by explicitly calling out heading-level restrictions that belong elsewhere.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit when-to-use scope and an explicit alternative: headings based on outlineLvl overrides or custom styles should instead be adjusted via set_paragraph_format's outline_level. It also clarifies when the tool will refuse to act, which directly guides correct selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It discloses mutation behavior, duplicate-name refusal, missing-key semantics, the SDT skip behavior, auto-backup and rotation details, atomic validated save, and refusal of documents open in Word. This is extensive and highly useful.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence adds substantive information about behavior, constraints, or alternatives. The main purpose is front-loaded, and the density is high without being bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity and the presence of an output schema, the description covers all essential operational facets: field types, accepted values, refusal modes, alternative routing, backup behavior, save guarantees, and an external blocker (open in Word). No critical context is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 all parameters. It explains the 'values' mapping semantics, type constraints per field kind, 'missing' behavior, and the exact meaning of backup=False. Only 'file_path' is left implicit, but that is a standard path parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
Description starts with a specific verb and resource: 'Set form-field values by name (legacy fields) or tag/alias (content controls)'. It distinguishes legacy fields from content controls and explicitly routes SDT types to set_content_control_value, making sibling differentiation clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete usage rules: text fields take strings, checkboxes take booleans, dropdowns only accept option values. It also names the alternative tool explicitly for SDT types, and explains the 'missing' parameter's two modes, so an agent knows when and how to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
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, and it does so thoroughly: it states mutation occurs in place, formatting behavior across runs, missing-key semantics for each mode, auto-backup behavior, atomic validated saving, and refusal to operate on Word-open documents. This goes well beyond simply naming the operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence and clause adds distinct value: scope, placeholder behavior, missing-mode semantics, copy alternative, backup behavior, save behavior, and safety condition. The information is dense but organized, front-loading the core purpose before details.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of the tool, the lack of annotations, and the presence of an output schema, the description is complete enough for correct invocation. It covers mutation semantics, parameter behavior, failure modes, backup behavior, and a key operational restriction, leaving no critical gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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: it explains the meaning of data[name], defines all missing modes ('error', 'skip', 'empty'), and clarifies backup=False behavior. It also makes the file_path and data semantics clear through usage context such as 'template' and 'data lacks'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action ('Fill a template IN PLACE') and identifies both target mechanisms: replacing {{name}} placeholders and setting MERGEFIELDs. It also differentiates from mail_merge, so an agent can distinguish it from a closely related sibling without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit when-to-use signal by contrasting in-place filling with producing copies, directing the agent to mail_merge for the copy behavior. It also details the missing-mode options and warns that the tool refuses documents open in Word, which helps an agent decide whether to call it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully carries the behavioral burden. It discloses Word's resolution order (run properties, character style, paragraph-style chain, document defaults), that matches report the resolution level, that query matching is case-sensitive, that text-box content is excluded, that theme references are counted rather than guessed, and that the tool is read-only. This is rich, non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every sentence adds value: purpose, resolution model, query behavior, scope, exclusions, theme handling, and mutation twin. It is front-loaded with the core purpose and then provides exactly the caveats an agent needs, with no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's high complexity — nested formatting object, inheritance semantics, multiple scopes, exclusions, and a sibling mutation tool — the description covers every decision point. The presence of an output schema means return-value documentation is unnecessary, and the description still notes that matches report the satisfied formatting level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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 itself. It does: query semantics (null vs case-sensitive string), scope values ('body' with tables, 'all' with footnotes/endnotes), and formatting keys with value types. The only under-explained parameter is file_path, which is self-evident from its name.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Find') and a distinct resource ('text by its EFFECTIVE formatting'), listing concrete criteria (bold/italic/underline/strike, font, size_pt, color, highlight, style). It clearly separates this tool from plain text search and mentions the mutation twin replace_formatted, so an agent can identify its unique role.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives explicit usage semantics: query=None vs a query string, scope='body' vs 'all', and the text-box exclusion with named alternatives (get_textbox_text or get_text include_textboxes). It also names replace_formatted as the mutation twin, clarifying when not to use this read-only version.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full behavioral burden, and it does so thoroughly. It discloses safety and side-effect behaviors: dry_run returns an identical report without touching the file, auto-backup writes to .ks4w-backups with backup=False skipping rotation only, saves are atomic and validated, and open-in-Word documents are refused. Per-category refusal conditions and human-review outputs are also spelled out.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long but every sentence earns its place; complex per-category behavior is organized into a clear scannable structure with code identifiers. The main operational contract is front-loaded, followed by category details and then safety/backup behavior, with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex 8-parameter repair tool with no annotations, this description is remarkably complete. It covers what each category does, when it refuses, what reports contain, dry-run behavior, backup behavior, and document-lock constraints. Since an output schema exists, detailed return-shape documentation is unnecessary, and nothing essential for correct invocation is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does 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. Every category parameter (alt_text_placeholders, heading_skips, table_headers, doc_title) is explained with concrete behavior, heading_strategy's two values are named, and dry_run and backup semantics are described directly. Only file_path is left implicit, which is acceptable for an obvious parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb ('Repair'), resource ('audit_accessibility findings'), and mechanism ('one opted-in category at a time'), making the tool's function immediately clear. It also distinguishes itself from the sibling audit_accessibility by contrasting repair with detection, and the per-category details leave no ambiguity about scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly frames usage in a workflow: 'audit -> fix -> audit' shows when this tool belongs after audit_accessibility. It also gives exclusions ('with none enabled the call refuses', 'Refuses documents open in Word') and names an alternative path for alt_text_placeholders via set_image_alt_text, so an agent knows both when to use and when not to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does so thoroughly. It discloses the mutation safety profile ('atomic validated save'), the backup mechanism with exact slot names and the meaning of backup=False, the refusal behavior for unsupported control types, and the constraint about documents open in Word. This goes well beyond what the schema or annotations convey.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is dense but every clause carries necessary operational or selection information. It front-loads the core purpose, then adds refusal rules, follow-up routing, and backup/safety behavior in a logical order. The length is justified by the tool's complexity and the complete absence of parameter descriptions in the schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 7-parameter, no-annotation tool, this description covers creation semantics, constraints, refusal cases, alternatives, backup behavior, and open-document refusal. The output schema exists, so return-value details are not required. There are no material gaps that would prevent an agent from selecting and invoking the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate fully. It explains after_anchor as literal plain paragraph text, occurrence as which anchor match to use, tag as unique and refused if it exists, alias and initial text as optional, and backup as skipping rotation when false. Virtually every parameter's semantic role is clarified beyond its bare name and type.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('insert'), a precise resource ('new PLAIN-TEXT content control / inline SDT'), and an exact placement ('right after after_anchor text'). It clearly differentiates this tool from siblings like set_content_control_value and fill_form_fields by framing creation versus later filling, and by specifying the supported control type.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use the tool, what it cannot do (checkbox/dropdown/date/picture/gallery/repeating controls are refused), and points to alternatives for both those unsupported controls and for later filling of the created control. It also gives concrete operational constraints: unique tag required, backup behavior, and refusal when the document is open in Word.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations available, the description carries the full behavioral burden and does so thoroughly. It discloses that the source file is never modified, that Word-open documents are refused, that problematic objects like OLE or ActiveX abort the whole insertion without half-applying, that styles reconcile by name, and that backup slots are rotated. This far exceeds typical disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is long, but it is dense and purposefully structured: purpose first, then positional choice, then carried/reconciled content, formatting behavior, return values, and safety guarantees. Every sentence adds operationally relevant information with no filler, and the most important selection guidance is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a complex merge tool with no annotations and an output schema to handle return details, the description is exceptionally complete. It covers what is carried, what is stripped, what causes refusals, formatting modes, backup behavior, positional semantics, and safety guarantees. An agent has enough context to invoke the tool correctly and predict its side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain all parameters itself. It does this comprehensively: after_index is defined as a body item index counting paragraphs and tables, after_anchor requires a full plain-text match and refuses ambiguous multiple matches, at_end is appending after the last body item, formatting modes are spelled out, and backup behavior is clarified. Nothing is left to guesswork.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: inserting the ENTIRE body of source_path into target_path, and frames the tool as the document-assembly tool for merging chapter files. It explicitly distinguishes itself from com_merge_documents and copy_table, so an agent can pick it correctly among siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states when this tool is appropriate (merging chapter files into one manuscript) and names alternatives with their limitations: com_merge_documents only concatenates whole files, while copy_table transplants a single table. It also gives concrete positional guidance, e.g., prefer after_index for structural work and avoid after_anchor for recurring heading text.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral disclosure burden and meets it: explains the prev/anchor slot scheme, that restore rotates current content into prev so restores are undoable, refuses documents open in Word, validates before atomic replace, and dry_run defaults to true. There is no contradiction with annotations because none were provided.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Organized by action with clear labels and no filler; every sentence adds operational value. The opening establishes the folder scheme and the create_snapshot boundary before detailing each action, making critical information easy to find.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a multi-action backup tool with no annotations and six undocumented parameters, the description supplies all necessary semantics: valid action values, defaults, source/scope choices, restore behavior, safety checks, and reporting. Nothing an agent needs to call the tool correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description maps action values, source options, scope options, dry_run default, and file_path vs directory usage. Every parameter receives practical meaning beyond its bare name, fully compensating for the absent schema documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb 'Manage' with resource 'automatic backups under hidden .ks4w-backups/' and enumerates three concrete actions (list, restore, purge) with distinct behaviors. Clearly separates itself from create_snapshot by noting snapshots are permanent keepers this tool never touches.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Each action includes explicit when/where context: list for slot files, legacy files, and orphans; restore for overwriting from prev/anchor/legacy paths; purge for legacy/orphans/slots with dry_run semantics. The note about create_snapshot snapshots being permanent keepers provides a when-not boundary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
GitHub Badge
Glama performs regular codebase and documentation scans to:
- Confirm that the MCP server is working as expected.
- Confirm that there are no obvious security issues.
- Evaluate tool definition quality.
Our badge communicates server capabilities, safety, and installation instructions.
Card Badge
Copy to your README.md:
Score Badge
Copy to your README.md:
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/nometalalchemist/KitchenSink4Word'
If you have feedback or need assistance with the MCP directory API, please join our Discord server