draftly-wps
Server Quality Checklist
Latest release: v0.1.0
- Disambiguation5/5
The tools are organized by host prefixes (wps_word_, wps_et_, wps_wpp_) and within each group, verbs clearly differentiate operations (get, set, create, delete, etc.). No two tools have overlapping purposes, and each maps to a unique WPS function, making selection unambiguous.
Naming Consistency5/5All tools follow a strict wps_{host}_{verb}_{noun} snake_case pattern consistently across 86 tools. General tools like wps_status also adhere to the wps_ prefix, ensuring a predictable and uniform naming scheme.
Tool Count2/586 tools is an extremely high count, far exceeding the typical 3-15 range for a cohesive server. While it covers three office applications, the sheer number risks overwhelming agents and indicates a lack of scope control.
Completeness5/5The tool set provides comprehensive lifecycle coverage for Word, Spreadsheet, and Presentation documents, including creation, editing, formatting, tables, charts, pagination, and export. Notable gaps are minimal, making the surface highly complete for the stated purpose.
Average 3.7/5 across 70 of 86 tools scored. Lowest: 1.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 5 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under GPL 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.
Add related servers to improve discoverability.
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
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility for behavioral disclosure. It only states 'clear range content' without explaining side effects (e.g., irreversible, affects formulas, clears formatting). The agent is left guessing the operation's exact consequences.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence, but it is under-specified rather than concise. It lacks necessary details about the clearing operation. For a tool with one parameter, it could easily include behavioral context without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's single parameter, lack of output schema, and absence of annotations, the description is critically incomplete. It does not describe what gets cleared, return values, undo behavior, or impact on other cells. The agent cannot reliably use this tool based solely on the description.
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 100% (one parameter 'range' with description '区域，如 A1:D10'). However, the tool description adds no additional meaning to the parameter beyond what the schema already provides. It does not explain the format, supported ranges, or behavior when range is invalid.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose2/5Does the description clearly state what the tool does and how it differs from similar tools?
Description '清空区域内容' (Clear range content) is a tautology of the tool name 'wps_et_clear_range'. It restates the name without specifying what 'clear' entails (values, formatting, or both), and does not distinguish it from siblings like wps_et_write_range which could also empty a range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., wps_et_write_range with empty string). There is no mention of prerequisites, scope (clears values only vs formatting), or whether it respects merged cells.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions reading 'address and value', hinting at a non-destructive behavior, but with no annotations provided, it fails to disclose whether the cursor or selection state is altered, or if there are any side effects. The behavioral insight is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5Is the description appropriately sized, front-loaded, and free of redundancy?
Extremely short, but the lack of English version and the non-front-loaded Chinese text with no additional structure reduces clarity. Under-specification is not conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has zero parameters and no output schema, a complete description would clarify the format of 'address and value', return type, and whether it works on single or multi-cell selections. It is severely incomplete.
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 100% as there are no parameters, so the description adds no burden. Baseline 3 is appropriate since the description does not need to add parameter meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose1/5Does the description clearly state what the tool does and how it differs from similar tools?
The description is only provided in Chinese, meaning 'Read the address and value of the current selection.' While this indicates a read operation, it lacks an English version, which severely limits global AI readability. It does not distinguish this tool from siblings like wps_et_read_range or wps_et_probe.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/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 wps_et_read_range. The description provides no context on prerequisites, use cases, or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral transparency. It does not disclose whether the tool is destructive (e.g., overwrites existing title), what happens if slide_index is out of range, or if any permissions are needed. The description is too terse to be transparent.
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 a single, short sentence with no filler. It is front-loaded with the action. However, it could be slightly more informative without losing conciseness.
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?
Given the tool's simplicity (2 required params), the description is minimalist. There is no output schema, so information about return values or success indicators is missing. For a tool that could have edge cases (invalid index, special characters in title), the description is incomplete.
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 100%, so the schema already documents both parameters. The description adds no extra meaning beyond what the schema provides, which leads to a baseline of 3. No nuance or formatting details are given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'set the title text of the specified slide' which is a specific verb-resource combination. However, it only repeats what the tool name already conveys and does not differentiate from siblings like wps_wpp_set_background or wps_wpp_set_slide_layout.
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 or when not to. For instance, it does not mention that slide_index is 0-based or 1-based, nor does it indicate if title replaces or appends existing text. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must describe behavior. It does not mention that this is a mutable operation (changes are written), whether it overwrites existing notes or appends, whether undo is supported, or if there are any prerequisites (e.g., slide must exist). This is a critical gap 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 a single, short sentence that is easy to parse. It is front-loaded with the action. However, it could benefit from slightly more detail without being verbose.
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?
Given it is a simple tool with two parameters, no output schema (agent cannot know return value), and no sibling differentiation, the description is insufficient. The agent lacks guidance on expected behavior (e.g., success indicator, error conditions) and how this tool fits in a workflow (e.g., add notes before presenting).
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 100% with short descriptions for both parameters ('备注文字' and '幻灯片序号（默认当前页）'). The description adds no extra meaning beyond what the schema already says. For a two-parameter tool, the agent would benefit from knowing that '备注文字' is the full text to set, and 'slide_index' starts from 0 or 1, and what '默认当前页' means in terms of index. The description fails to enrich the schema.
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 the verb ('设置', set) and resource ('指定幻灯片的演讲者备注', speaker notes of a specific slide). It distinguishes from siblings like wps_wpp_read_slide or wps_wpp_add_slide which do different things. Could be improved by explicitly mentioning it is for the 'WPS Presentation' (wpp) context.
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 on when to use this tool vs. alternatives like wps_wpp_read_slide (to read notes) or wps_wpp_add_slide. There is no mention of prerequisites (e.g., a presentation must be open, or the slide must exist). The agent must infer usage from context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 fails to mention what the tool actually does internally (e.g., whether it mutates anything, requires a workbook to be open, or what side effects it might have). The description mentions '输出各种取值方式的结果' but does not clarify whether this is a read-only operation or could have 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence with no filler. It is appropriately sized for a tool with no parameters and a simple purpose. It loses one point because it is in Chinese and the translation is not provided, which may reduce clarity for some agents.
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?
Given there are no parameters and no output schema, the description must explain what the tool returns and when to use it. It only says it outputs various value retrieval results, but does not specify what those results are, how to interpret them, or any prerequisites. As a development diagnostic tool, more detail about expected output format or usage scenarios would be 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?
The tool has no parameters, so the schema provides no information. The description adds the purpose of outputting multiple value retrieval results, which is meaningful context. With zero parameters, a baseline of 4 is appropriate because the description compensates for the absence of parameter information by clarifying the tool's scope.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose3/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states it diagnoses the WPS Spreadsheet Range value API and outputs results of various value-obtaining methods. The verb 'diagnose' is somewhat vague but understandable for a probe tool. It is not clearly distinguished from sibling tools like 'wps_et_probe' vs 'wps_et_read_range' or 'wps_et_get_selection'.
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 provides minimal guidance on when to use this tool. It is labeled '开发用' (for development), which implies it is for debugging, but it does not mention alternatives or when not to use it, nor does it specify scenarios where this probe is preferable over reading a range normally.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It only states 'apply style' without revealing whether the operation is destructive, what happens if the style doesn't exist, or any return value. The schema's range parameter is not mentioned in the description, leaving the agent unsure about the modification scope.
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 a single concise sentence (14 characters) that efficiently conveys the core action. It is front-loaded with the verb and resource. However, it could be slightly more informative without losing conciseness, such as mentioning the range parameter.
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 two parameters (one enum, one required string) and no output schema, the description is too minimal. It omits the range scope, does not explain the effect of applying a style (e.g., overwriting existing formatting), and provides no context for deciding between this tool and sibling tools like wps_word_set_font. The description leaves significant gaps for an AI agent.
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 100% (both parameters have descriptions). The tool description adds no additional meaning beyond the schema; it does not elaborate on 'style_name' or 'range'. Baseline 3 is appropriate since the schema already documents the parameters adequately.
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 the tool applies a style to target text, giving examples like 'Heading 1'. This distinguishes it from sibling formatting tools (e.g., wps_word_set_font, wps_word_set_alignment) because applying a predefined style is a different operation. However, it does not explicitly differentiate from alternatives or mention the scope (selection vs. all), which is covered by 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?
The description provides no guidance on when to use this tool over sibling formatting tools. It does not mention prerequisites, such as requiring a selection, or when direct formatting might be preferred. No exclusions or alternative tool references are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits such as whether the deletion is undoable, destructive to the selection, or if it affects formatting. The single phrase '删除当前选中的文字' lacks such detail, leaving the agent uninformed 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 extremely concise: one short sentence that directly states the action. Every word is functional; there is no verbosity or waste.
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?
Given the simplicity of the tool (zero parameters, no output schema), the description is minimal. However, it lacks any mention of return behavior, whether the action is reversible, or what happens when there is no selection. A more complete description would include these contextual details.
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 zero parameters and 100% schema coverage, so no parameter description is needed. The baseline of 3 applies—the description does not need to add parameter semantics.
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 the tool deletes selected text in a WPS Word document. It does not explicitly distinguish itself from siblings like `wps_word_replace`, but the specific verb 'delete' and reference to 'selection' make it unambiguous among nearby tools.
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 provided on when to use this tool versus alternatives such as `wps_word_replace` or `wps_word_clear_range` (if it existed). The description does not mention prerequisites like ensuring text is selected, nor 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of behavioral disclosure. It only restates parameter meanings and does not disclose any behavioral traits such as whether the operation is destructive, requires an open document, or affects the entire document by default. The description adds minimal transparency 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 concise: two short sentences with the purpose front-loaded. It efficiently conveys the core action and parameter options without extraneous text. It earns a 4 because it is lean but not overly terse to the point of being unhelpful.
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 the tool's low complexity (2 parameters, no output schema), the description is minimally adequate. It covers the purpose and parameter meanings, but lacks information about return values, prerequisites (e.g., document must be open), and side effects. For a simple setter, this is acceptable but not 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 100% (both parameters have descriptions in the schema). The description adds value by explaining the enum values in Chinese ('selection=当前选中 / all=全文'), which is essentially the same as the schema's descriptions. Since coverage is high, baseline is 3; the description does not significantly extend understanding of 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 states the tool's purpose: '设置段落对齐' (set paragraph alignment). It specifies the verb and resource. However, it does not differentiate from sibling tools like wps_word_set_paragraph_format which may also affect alignment, so it loses a point for lack of differentiation.
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 provides only the meanings of the range parameter ('selection' vs 'all') but gives no guidance on when to use this tool versus alternatives. For example, there is no mention of when to use this dedicated alignment tool instead of the more general wps_word_set_paragraph_format. No exclusions or prerequisites are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states that bold/italic accept true/false. It fails to mention side effects, whether it modifies existing formatting, prerequisites (e.g., an open document), or what happens when parameters are omitted. This is insufficient 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 very short and to the point, consisting of two sentences. It conveys core info efficiently with no wasted words. Could benefit from a slightly more structured presentation but remains concise.
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?
With 5 parameters, no output schema, and no annotations, the description is too minimal. It does not clarify that all parameters are optional, how omitting parameters affects formatting, or what the tool returns. Lacks context for an AI agent to fully understand its behavior.
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 100% with Chinese descriptions for each property. The description adds minimal value beyond the schema—it repeats the range values and notes bold/italic accept true/false. Baseline 3 applies as schema already does the heavy lifting.
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 the tool's purpose as setting font formatting. It adds explanation for the 'range' parameter values. However, it does not differentiate from sibling tools like wps_word_set_alignment or wps_word_set_paragraph_format, which handle other formatting aspects.
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 explicit guidance on when to use this tool versus alternatives. The description implies it's for font properties but lacks when/when-not instructions or references to other related tools among siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full behavioral burden. The description omits critical details: it does not state that this tool is non-destructive (additive), whether it modifies an existing textbox or creates a new one, what happens if the slide_index is invalid, or whether it returns a confirmation/error. For a mutation tool in a presentation context, this is insufficient.
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 Chinese description is brief (one sentence) and front-loaded. It directly conveys the core purpose with no wasted words. However, given there are 8 parameters and no additional behavioral context, it could be considered under-specified rather than concise. Still, for a tool with 100% schema coverage, the description is appropriately terse.
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?
The tool has 8 optional parameters and no output schema. The description only covers the high-level action. With no guidance on default behaviors (e.g., what happens if no slide_index is given), error handling, or return type, an AI agent may not correctly infer how to use this tool reliably. Sibling tools like wps_wpp_add_shape are similarly terse, so this is consistent but still incomplete.
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 100%, so baseline is 3. The description adds no parameter-level details beyond what the schema already provides. Parameters like top, left, width, height have default values documented in schema, and slide_index defaults to 'current page' – these are already clear. The description does not clarify relationship between parameters (e.g., positioning relative to slide dimensions) or constraints (e.g., text must be a string).
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 the action (add textbox and write text) and the target resource (a slide/page). It distinguishes itself from siblings like wps_wpp_add_shape (adds generic shapes) and wps_wpp_read_slide (reads content). The verb 'add' is specific, though it doesn't explicitly mention it's for a presentation slide; however, the namespace 'wps_wpp' implies WPS Presentation.
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 provides no guidance on when to use this tool versus alternatives like wps_wpp_add_shape or wps_wpp_insert_image. No context about prerequisites (e.g., a slide must already exist) or when not to use it. Among 76 sibling tools, several deal with adding or modifying slide content (add_slide, add_shape, insert_image), yet no differentiation is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose behavioral traits. It correctly indicates the tool modifies slide content (coloring), but fails to mention that it overwrites existing formatting or whether it's reversible (destructive). No mention of undo, save requirements, or scope (single slide vs all). Adequate but incomplete 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 very concise, with two clear sentences. The first states the core action, the second lists styles. No wasted words, though it could be restructured to first state purpose then provide style details.
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?
Given the tool has 2 parameters, no output schema, and no annotations, the description is incomplete. It doesn't specify whether the tool applies to the current slide or a specific slide_index, how style selection impacts output, error conditions (e.g., no slide), or return value. The schema's slide_index description hints at default behavior, but the description should clarify.
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 covers both parameters with descriptions. The description adds minimal value: 'style' enum values are listed and default is noted, but the description doesn't explain how each style affects the coloring beyond 'color scheme'. Schema coverage is 100%, so baseline 3 is appropriate.
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 the tool beautifies a slide by coloring titles and body text according to a color scheme, with specific style options. It distinguishes this tool from other slide-related siblings like unify_font or set_background, which focus on different aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use beautify_slide versus other formatting tools like unify_font, apply_template, or set_background. There is no mention of prerequisites (e.g., needing slides) or when not to use it. The sibling context shows many related formatting tools, making this gap significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for behavioral disclosure. It only states the action without mentioning that this is a destructive mutation (changing layout may disrupt content), any required permissions, or side effects. The description is wholly insufficient for understanding the tool's 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 a single efficient sentence with no wasted words. However, it lacks any structural front-loading or emphasis on key information. For a simple tool, this is acceptable but not exemplary.
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?
Given the absence of annotations and output schema, the description should provide more context. It does not explain what happens after applying a layout (e.g., content rearrangement, fallback), slide index default behavior, or error conditions. The description is incomplete for an agent to confidently use 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 coverage is 100% – both parameters have descriptions and the layout enum is fully defined. The description adds no new meaning beyond the schema, meeting the baseline of 3. It does not clarify default behavior for slide_index or explain the nature of the layouts.
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 ('切换' = switch) and the resource ('幻灯片版式' = slide layout), specifying '指定幻灯片的' (specified slide) and 'PowerPoint 经典版式'. This uniquely identifies the tool's purpose among siblings, none of which deal with layout changes.
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 provides no guidance on when to use this tool versus alternatives, nor does it mention prerequisites, exclusions, or context. An agent receives no instruction on when to prefer this over other slide manipulation tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states 'create chart' but does not explain where the chart is inserted, whether it replaces existing charts, required data formatting, or side effects. Minimal transparency beyond the basic action.
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 single concise sentence that immediately conveys the tool's purpose. It front-loads the action and includes example chart types for quick comprehension.
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 tool with 3 parameters and no output schema, the description is minimally adequate. It tells the agent the tool creates a chart from a data range but omits details like the chart's placement in the spreadsheet, default behavior when no chart_type is specified, or constraints (e.g., data must be contiguous).
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 100%, so the schema already describes all parameters. The description mentions chart types in parentheses but does not add new meaning to parameters like data_range format or title usage. Baseline score of 3 is appropriate.
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 creates a chart from a data region and lists example chart types (bar/line/pie). The verb 'create' and resource 'chart' are specific, and the chart type examples distinguish this from other tools in the siblings list that do not create charts.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites, preferred contexts, or situations where another tool (e.g., a formula or pivot table) would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It reveals that it adds a slide with optional title and layout, but does not explain what happens after addition (e.g., does it return a slide ID? does it select the new slide?), error conditions, or side effects like changing the current slide index.
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 very short (two sentences) and front-loaded with the purpose. Every word is functional, though some behavioral details could be added without bloating it.
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 3 optional parameters and no output schema, the description is too minimal. It omits default layout (title_content, though in schema), behavior after insertion, and constraints. It feels incomplete for an AI agent to use confidently.
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 100%, so baseline is 3. The description adds the layout enum values and notes the title is optional, but does not clarify the 'position' parameter (e.g., indexing, behavior when omitted). It adds marginal value beyond the schema definitions.
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 new slide), specifies the resource (slide), and lists the available layouts. It effectively distinguishes from sibling tools like wps_wpp_add_textbox or wps_wpp_delete_slide, which perform different operations.
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 provided on when to use this tool versus alternatives (e.g., wps_wpp_set_slide_layout for modifying existing slides). There is no mention of prerequisites, such as requiring an active presentation, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. The description only states the basic action; it does not mention whether the deletion is permanent, if there is an undo capability, if it affects other slides (e.g., reindexing), or any required permissions. The description adds minimal value beyond the tool 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 single, concise sentence in Chinese with no wasted words. It is front-loaded and to the point. For a simple tool with one parameter, this is appropriately sized.
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 the tool's simplicity (1 parameter, no output schema, no nested objects), the description is nearly complete for basic understanding. However, it lacks any mention of what happens after deletion (e.g., slide reindexing) or constraints like not being able to delete the last slide, which would be useful for an AI agent. The description is adequate but has 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 100% (single parameter slide_index with description '幻灯片序号'). The description does not add meaning beyond what the schema already provides. Baseline is 3 when coverage is high and no additional parameter details are given.
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 '删除指定幻灯片' (delete specified slide) which is a specific verb+resource combination. It identifies the tool's purpose of deleting a slide, and among siblings like wps_wpp_add_slide, wps_wpp_duplicate_slide, and wps_wpp_move_slide, it distinguishes itself as the deletion operation. However, it does not explicitly differentiate from these siblings in the description text.
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 provided on when to use this tool versus alternatives like removing all content from a slide instead of deleting it, or using other slide manipulation tools. There are no explicit conditions, prerequisites, or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden but fails to disclose what 'all text' includes (e.g., text in shapes, tables, notes) or the return format. It does not describe behavior on invalid slide index or whether it's a read-only operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is one sentence, concise and front-loaded with the purpose. However, it could be slightly expanded without losing conciseness to cover behavioral details.
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?
Given the single parameter, no output schema, and no annotations, the description is too minimal. It lacks details on return value, scope of text extraction, and error handling, making it incomplete for an agent to use confidently.
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 100% and the description repeats the slide_index start-from-1 info already in the schema. No additional meaning or examples are added, so baseline 3 is appropriate.
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 reads all text from a specified slide by index, with specific verb 'read' and resource 'slide'. It distinguishes from siblings like wps_wpp_add_slide or wps_wpp_set_slide_title.
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 on when to use this tool vs alternatives like wps_wpp_get_outline, wps_wpp_get_presentation_info, or other read tools. No mention of prerequisites or 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose behavioral traits such as whether existing filters are replaced, what happens if the range already has a filter, or whether the tool modifies the sheet in place. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short (one sentence) and uses a semicolon to separate two main functions, keeping it compact. Every part adds value, though it could slightly benefit from clearer separation of the two modes.
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 the tool has 3 parameters (1 required) and no output schema, the description provides adequate purpose and hints at the dual behavior. However, it lacks details on return value, side effects, or required permissions, which are relevant given the sibling tools are numerous and some perform similar spreadsheet operations.
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 100%, so baseline is 3. The description adds the context that 'field' and 'criteria' together enable filtering, but does not elaborate beyond what the schema already explains (e.g., column index start, format of criteria).
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 ('开启自动筛选', meaning 'enable auto filter') and specifies the resource ('区域', meaning 'range'). It also distinguishes two modes: enabling auto filter on a range without additional parameters, and filtering by a specific column when 'field' and 'criteria' are provided.
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 cases (apply auto filter or filter by column) but does not explicitly state when to use this tool vs alternatives like sorting or conditional formatting. There is no exclusionary guidance or mention of prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It usefully discloses the color format conversion (#RRGGBB to BGR) and promises no need to handle the conversion. However, it does not clarify whether formatting is replaced or additive, whether it clears unspecified formatting properties, or how it behaves with merged cells or partial ranges. The disclosure is helpful but incomplete.
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 concise: two sentences in Chinese, listing the key formatting options and the color conversion note. It is front-loaded with the purpose. A slightly more structured breakdown (e.g., grouping parameters) could improve readability, but overall it is efficient.
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 8 parameters and no output schema, the description adequately lists the formatting capabilities. However, it lacks behavioral context (e.g., does it reset other formatting? what is the return value?), and does not mention edge cases or limitations. It is minimally complete for a utility tool but leaves 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 coverage is 100%, so baseline is 3. The description adds value by summarizing the set of parameters and explaining the color conversion behavior, which is not in the schema. However, it does not add detailed semantics beyond what the schema already provides for each parameter.
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 'format range' and lists the specific formatting attributes (bold, font size, font name, font color, background color, alignment, column width). This distinguishes it from sibling tools like wps_et_write_range (data writing) or wps_et_set_conditional_format (conditional formatting), though it does not explicitly name alternatives.
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 provides no guidance on when to use this tool versus other range-related tools (e.g., wps_et_write_range, wps_et_clear_range, wps_et_set_conditional_format). It does not state prerequisites, typical use cases, 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.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
描述仅说明写入值，但未披露关键行为：是否覆盖已有内容、是否触发公式重算、是否需要权限或激活的工作表。由于没有提供注解，描述承担了完整的行为披露责任，但提供的层次不足。
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
描述仅一句话，简洁且直接。提供了必要的格式示例，但未包含冗余信息。虽然可以更丰富，但现有长度仍合理。
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?
考虑到只有2个参数且无输出模式，工具功能简单，描述基本完成了任务。但缺少行为细节和与其他工具的区别，使得在复杂场景下不够完整。
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?
输入模式文档覆盖率达到100%，两个参数均在模式中被描述。描述中重申了cell的格式示例，但未增加关于值类型（如是否支持公式或数字）、单元格引用范围等额外语义。由于模式已完备，基础评分3合理。
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?
描述'向单元格写入值'明确了工具的作用——向表格单元格写入数据，动词+资源结构清晰。同时指定了cell格式如'A1'，但没有与相近工具如wps_et_write_range进行区分，且缺乏对写入行为的进一步说明。
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?
描述未提供任何关于何时使用此工具或替代工具的指导。考虑到存在write_range和set_formula等类似工具，缺少这些区分信息使智能体在选择时无法得到明确指引。
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided. The description only states 'insert text' without disclosing behavioral traits like whether the cursor moves after insertion, whether formatting is preserved, or if there are any side effects (e.g., overwriting content at start/end). The minimal description fails to inform the agent of important runtime 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 extremely brief (one sentence plus a colon-enum mapping). It is front-loaded with the action. While concise, it could benefit from an additional sentence clarifying insertion behavior. No extra words, but the brevity may sacrifice clarity.
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 has only 2 parameters and no output schema, so moderate description is expected. The description covers the core action and position options, but omits details like whether insertion is plain text, if it affects subsequent content, or how it interacts with cursor position. This leaves gaps for an AI agent to reason 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?
Schema description coverage is 100% (both parameters have descriptions). The description adds the explicit mapping of enum values to Chinese phrases ('cursor=光标处 / start=文首 / end=文末'), but this largely mirrors the schema's enum descriptions. The addition is marginal, so a baseline score of 3 is appropriate.
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 verb 'insert' and the resource 'text in the current document'. It lists the three positional options (cursor, start, end), which distinguish it from sibling tools like wps_word_replace, wps_word_append_paragraph, etc. The purpose is unambiguous and specific.
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 wps_word_append_paragraph or wps_word_replace. The description only explains the parameter options without any context about when insertion is appropriate or when to avoid it. Given the many sibling tools, this omission is significant.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 states the tool reads all tables, but omits important traits: whether it is destructive, what happens if no tables exist, how hidden tables are handled, or the exact format of the 2D array. The read nature is implied, but not explicitly assured.
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?
A single sentence in Chinese that is concise and to the point. Every word serves a purpose, with no redundancy or filler. Well-structured and front-loaded with the key action and result.
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?
Given no output schema or annotations, the description is too minimal. It does not explain edge cases (empty document, no tables), return value details beyond '2D array', or how the tool interacts with the current document state. The tool is simple but lacks completeness for reliable agent 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?
There are no parameters, so schema coverage is 100% trivially. The description does not add parameter details because there are none. Baseline is 3 per the rule for high schema coverage, and the description is adequate but not exceptional.
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 reads all tables in the document and returns a 2D array. It uses a specific verb ('read') and resource ('tables'), and distinguishes from sibling tools like wps_word_read (plain text) and wps_word_get_paragraphs.
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 on when to use this tool versus alternatives like wps_word_read or wps_word_create_table. The description does not mention prerequisites, context, or exclusions, leaving the agent to infer usage 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.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explains the behavioral effect of each action ('修订变为正式内容' for accept, '还原为修订前状态' for reject). However, with no annotations provided, the description carries the full burden. It doesn't disclose that the operation is irreversible, whether it requires document save, or if it works across the entire document only. Given no annotations, a 3 is reasonable as it provides some behavioral context but lacks depth.
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 extremely concise, at one sentence with two clauses. Every part is informative: it states the verb, the resource, and the two actions with their effects. No extraneous words or redundant information.
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?
The tool has only one parameter, no output schema, and no annotations. The description is complete in stating what the tool does, but it lacks critical context for an AI agent: e.g., whether the operation can be undone, whether it requires the document to be open, or what happens after execution (return value). For a simple tool, a 2 is appropriate given these 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?
The input schema has 100% description coverage (the 'action' parameter is described as '默认 accept'), so the baseline is 3. The description adds minimal value beyond the schema: it explains the effect of 'accept' and 'reject' actions, which the schema does not. This adds some meaning but doesn't significantly overcome the baseline.
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 the tool's purpose: to accept or reject all revisions in a WPS Word document. It uses specific verbs ('接受', '拒绝') and identifies the resource ('修订'). It distinguishes itself from sibling tools like wps_word_get_revisions by targeting resolution rather than retrieval.
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 provided on when to use this tool versus alternatives. For instance, it doesn't mention that this tool operates on all revisions at once, and that selective resolution might require other tools (like wps_word_get_revisions followed by individual actions). There's no explanation of prerequisites or context for use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden of disclosing behavioral traits. The description only mentions the action and optional parameters (text, fill color) but does not explain side effects, permissions, or what happens to existing shapes. It does not address the default slide behavior or coordinate system. For a mutation tool with no annotations, this is insufficient.
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 single sentence that is front-loaded with the action and key information. It contains no superfluous words or redundant explanations. Every part serves a purpose, making it highly concise and well-structured.
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?
Given the tool has 8 parameters (all optional) and no output schema or annotations, the description is too brief. It does not explain the coordinate system, default values, or how the shape is inserted (e.g., to the current slide versus a specified slide). It also does not mention what happens if parameters are omitted. The schema descriptions help, but the high parameter count and lack of behavioral context leave the agent with an incomplete understanding.
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 100%, so the baseline is 3. The description adds minor value by repeating the shape types and mentioning optional text and fill color, which aligns with the parameters. However, it does not add significant new meaning beyond what the schema already provides (e.g., default values, coordinate system, or behavior of slide_index). It is adequate but not exceptional.
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 the action ('insert basic shapes'), lists the specific shape types (rectangle, rounded rectangle, oval, diamond, arrow), and indicates the use case (flowcharts/diagrams). It is specific and uses a verb+resource structure. However, it does not explicitly distinguish this tool from related siblings like wps_wpp_add_textbox or wps_wpp_insert_image, which would earn a top score of 5.
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 for drawing flowcharts or diagrams, providing some context. However, it does not give explicit guidance on when to use this tool versus alternatives, nor does it mention when not to use it or any prerequisites. The context is implied but not structured as actionable guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are not provided, so the description carries the full burden. It does not disclose behavioral traits such as whether existing cell content is overwritten or appended, whether formatting is preserved, or what happens if the cell index is out of bounds. However, the basic write operation 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 very concise: one sentence that clearly states the action and object, plus an explicit note about indexing. Every word adds value, and no space is wasted.
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 the tool's moderate complexity (4 required parameters, no output schema), the description is brief and covers the basic action. However, it does not explain what constitutes a valid table (e.g., must already exist in the Word document), or what the tool returns upon success or failure. With no output schema, the description could have included behavior on errors or confirmation.
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 100% description coverage for all parameters (table_index, row, col, text). The schema already states that offsets start at 1 and that text is the string to write. The description adds a brief note about table_index starting at 1, which is redundant with the schema. The description does not provide additional semantics beyond what the schema offers.
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 the tool writes text to a cell of a table, and specifies that the table_index starts at 1. It effectively differentiates from siblings like wps_word_create_table (which creates tables) and wps_word_read_tables (which reads tables).
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 provided on when to use this tool versus alternatives like wps_wpp_write_table_cell (which writes to presentation table cells) or wps_et_write_range (which writes to spreadsheet cells). There is no mention of prerequisites, such as the table must already exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It fails to disclose side effects (e.g., how other slides re-index after the move), error conditions (e.g., invalid slide_index), or whether the tool operates on the active presentation. The statement is too minimal.
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?
A single, clear sentence is perfectly concise. Every word earns its place—no fluff, no repetition. Ideal for quick parsing.
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 simple move operation with two parameters and no output schema, the description captures the essential action. However, it omits details about index shifting after the move, possibly confusing the agent about the result. It is minimally adequate but not thorough.
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?
Both parameters have descriptive schema comments (slide_index: 'Slide number to move'; to_position: 'Target position (starting from 1)'). Schema coverage is 100%, so the description adds no additional meaning beyond what is already in the schema. Baseline score of 3 is appropriate.
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 '把指定幻灯片移动到新位置' (Move the specified slide to a new position) uses a specific verb ('move') and resource ('slide'), clearly distinguishing it from sibling tools like delete_slide, duplicate_slide, or add_slide.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives (e.g., duplicate_slide vs. move_slide) or any prerequisites (e.g., the presentation must be open). The agent receives no context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It does not reveal whether the change is permanent or undoable, whether it affects only the current presentation, or what happens to text in non-textbox elements. The default font behavior is implied by the schema but not explicitly stated in the 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?
The description is a single sentence that immediately conveys the core action and scope. No superfluous words. Perfectly concise and front-loaded.
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 simple tool with one parameter and no output schema, the description is minimally adequate. It covers what the tool does but omits details like scope (all slides), behavior for different text container types, and reversibility. Could be improved with a sentence about the default behavior or limitations.
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 100% (font_name has a description). The tool description adds no additional meaning beyond the schema; it merely restates the action. Baseline 3 is appropriate since the schema already documents the parameter sufficiently.
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 (unify fonts), resource (all text box fonts), and scope (entire presentation). It distinguishes itself from sibling tools, none of which target font unification.
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 provides no guidance on when to use this tool versus alternatives, nor does it specify prerequisites or when not to use it. For example, it doesn't mention that this operation overwrites existing fonts across all text boxes, which would be important context for an agent deciding between this and individual font changes.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states '不保存' (do not save), which is critical behavioral context. Since no annotations are provided, the description carries the full burden—it covers the main side effect (no save on close) but does not mention if unsaved changes trigger a confirmation dialog, if the application closes entirely, or if the action is reversible. A score of 3 is appropriate for adequate but not exhaustive 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 a single, front-loaded sentence with zero wasted words. It communicates the action, target, and critical behavioral detail (no save) in the most efficient manner possible for a zero-parameter tool.
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 that this is a simple close action with no parameters and no output schema, the description is adequate but missing important context: whether the action can be undone, what state the application is left in (does it close the workbook but keep the application open?), and what happens with unsaved changes besides not saving. These gaps prevent a higher 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?
The input schema has zero parameters (100% coverage), so there is nothing for the description to add beyond stating the tool takes no arguments. The baseline is 4 for 0-parameter tools, and the description confirms the no-save behavior which is the only relevant parameter-like information.
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 the action is to close the current workbook and it will not save, using the specific verb '关闭' (close) and resource '当前工作簿' (current workbook). It distinguishes from siblings like wps_et_save which saves without closing, and wps_word_close which closes a Word document.
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 provided on when to use this tool versus alternatives like wps_et_save (to save and keep open) or combined operations. It does not mention prerequisites (e.g., that a workbook must already be open), nor does it explain what happens if there are unsaved changes or if the workbook is being closed as part of a larger workflow.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It mentions the 'order' parameter with allowed values and implies sorting by a key column. However, it does not disclose whether the sorting is stable, modifies the original data or creates a copy, or what happens if there are merged cells or empty cells. A score of 3 is appropriate because it covers the basic behavior but lacks deeper transparency.
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 concise with two sentences: the first states the core function, and the second clarifies the 'order' parameter values. It is front-loaded with the main action. It could be slightly improved by mentioning the default order (already in schema) but is still efficient.
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 has 3 parameters with full schema coverage and no output schema. The description covers the basic sorting action and the 'order' parameter but lacks context on error cases, performance considerations, or how it interacts with other spreadsheet features (like filters or tables). A score of 3 indicates it is adequate but has room for improvement.
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 already has 100% coverage with descriptions for all three parameters. The description adds no additional parameter semantics beyond what the schema provides. Per guidelines, when schema_description_coverage is high (>80%), the baseline is 3, and the description does not elevate this.
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 '按某列对区域排序' (sort a range by a column), which is a specific verb-resource combination. It also mentions the 'order' parameter with allowed values 'asc/desc', which helps distinguish it from other spreadsheet tools like wps_et_auto_filter or wps_et_write_range that have 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives. While it is clear what the tool does, there is no mention of prerequisites (e.g., whether the range must contain data, if headers are required), or when it would be better to use other siblings like wps_et_auto_filter or wps_et_format_range.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must fully disclose behavioral traits. It only states 'reads selected text' without clarifying what happens if nothing is selected, whether formatting is preserved, or if the operation is read-only (though inferred from the name). Key behavioral gaps remain.
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 single sentence that is front-loaded and efficient. Every word serves a purpose with no redundancy.
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 having no parameters and no output schema, the description is too minimal. It lacks details about the return value format, error cases (e.g., no selection), and does not help the agent understand what to expect from the output. Given the complexity of the sibling tool set, more context is needed for correct usage.
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 and schema description coverage is 100% (trivially). Since there are no parameters to describe, the baseline is 4. The description does not add any parameter semantics, but none are needed.
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 '读取当前选中的文字' (Read the currently selected text) clearly states the verb (read) and the resource (currently selected text), distinguishing it from siblings like wps_word_read which reads the entire document, and wps_word_get_paragraphs which reads paragraph structure.
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 provided on when to use this tool versus alternatives. There is no mention of prerequisites, such as requiring a selection to exist, or when to prefer wps_word_read or wps_word_get_paragraphs instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 max_chars defense against explosions, which is positive. However, it does not mention if the tool is read-only, whether it modifies document state, or if it requires the document to be open. Without annotations, this is minimal but adequate.
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 extremely concise at 30 characters, with no wasted words. It front-loads the primary purpose and then addresses the parameter. It could be slightly more structured (e.g., separating purpose from param note), but overall it earns its brevity.
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 low complexity (1 param, no enums, no output schema), the description is mostly complete for the core function. However, it lacks details on return format (plain text?), behavior for non-text content (images), or any prerequisites (document must be active). The description does not need to be exhaustive, but there are small 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 100%, so baseline is 3. The description echoes the parameter purpose ('限制返回长度防爆') but does not add new meaning beyond the schema's own description ('最多返回字符数'). It complements effectively but without extra enrichment.
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 clear verb ('读取') and specific resource ('当前活动 Word 文档全文'), indicating reading full content. It distinguishes itself from sibling tools like wps_word_read_tables (focused on tables) and general probe tools, though it could explicitly state it returns the entire document text.
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 for retrieving full document content, but provides no explicit guidance on when to use vs. alternatives like wps_word_read_tables (for tables) or wps_word_get_selection (for selection). No exclusions or context about document size or performance impact are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It does not mention side effects, idempotency, permissions, or what happens when no parameters are set. As a formatting setter, it is likely non-destructive, but this is not stated. The description adds no behavioral context beyond the action itself.
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 single short sentence that front-loads the purpose and enumerates key parameters. Every word contributes meaning; there is no redundancy or filler.
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?
Given 5 optional parameters, no annotations, and no output schema, the description should cover more context: behavior when multiple parameters conflict, defaults, impact of the 'range' parameter (selection vs all), and whether the tool returns anything. The current description is insufficient for an agent to reliably use this tool without additional inference.
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 100%, so the baseline is 3. The description briefly lists the parameters (段前/段后间距, 行距, 首行缩进) in a condensed form, which mirrors the schema properties. It adds no additional constraints, default values, or usage nuances beyond what the schema already provides.
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 resource ("段落格式"), and enumerates the specific formatting properties (段前/段后间距, 行距, 首行缩进). This distinguishes it clearly from sibling tools like wps_word_set_font or wps_word_set_alignment.
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 paragraph formatting is needed, but provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no excluded scenarios. The distinction from siblings is implicit through the listed properties.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 of behavioral disclosure. It states the tool probes API support, which suggests a read-only operation, but it does not explicitly confirm no side effects, mention required permissions, describe the return format, or disclose any safety considerations. The description is insufficient for a diagnostic tool with no 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 a single, concise sentence that front-loads the purpose and context. Every word contributes to meaning, with no redundancy or filler. It is appropriately sized for a zero-parameter diagnostic tool.
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?
The tool has no output schema, so the description should explain what the return value represents. It only mentions detecting API support but does not describe the format of results (e.g., list of supported features, boolean flags, etc.). For a diagnostic tool, this is a significant omission. Additionally, no annotations are provided to fill in behavioral 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?
The tool has zero parameters, and schema description coverage is 100% (trivially). The description adds no parameter information because there are none. Baseline is 3, and the description does not need to compensate for missing param details. It adequately describes the tool's action without needing to elaborate on 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 uses the specific verb '探测' (probe/detect) and clearly identifies the resource: API support for slide size, layout, and template. This distinguishes it from siblings like wps_wpp_get_presentation_info (which retrieves presentation info) and wps_word_probe (for Word).
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 includes '诊断用' (diagnostic use), implying the tool is for checking API support rather than normal operations. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide any exclusions or prerequisites. Usage guidance is implied but not explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states the basic action and the source of shape_index. It does not describe what happens if the cell already contains text (e.g., overwrite or append), whether the operation is reversible, or any error conditions. For a mutation tool, this is insufficient.
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 single sentence that is front-loaded with the primary action and then provides a key usage hint. Every word is necessary; there is no fluff. It is concise and efficient.
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?
Given that this is a mutation tool with 5 parameters and no output schema, the description is too brief. It fails to mention default behavior when slide_index is omitted, behavior on out-of-bounds row/col, or whether the function overwrites or appends text. The note about shape_index is helpful but incomplete for a robust agent to use safely.
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 100% coverage with descriptions for all five parameters. The description adds a note about shape_index being the return value of wps_wpp_add_table, but this is already stated in the schema description for that parameter. Thus the description adds minimal new meaning beyond the schema, meeting the baseline of 3.
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: '向幻灯片表格单元格写入文字' (write text to a slide table cell). It also specifies that the shape_index parameter comes from the return value of wps_wpp_add_table, which helps distinguish it as a follow-up operation. The tool name and sibling context confirm it's for WPP presentations, not Word or spreadsheet tables.
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 that this tool should be used after wps_wpp_add_table, since it mentions shape_index is taken from that tool's return value. However, it does not explicitly state when to use this tool versus alternatives like wps_word_write_cell or wps_et_write_cell, nor does it provide any exclusions or prerequisites beyond the shape_index hint.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses the default cell behavior and data structure. However, it does not specify whether the write overwrites existing content, how the range is determined, or error handling. This is adequate but not 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 extremely concise: two sentences, no filler, front-loaded with the main action. Every sentence contributes meaning.
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 simplicity (two parameters, no output schema), the description covers the essential behavior: what it writes, how data is structured, and the default cell. It lacks edge-case details but is complete for a basic write range operation.
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 100%, so baseline is 3. The description adds value by clarifying that data is row-major (each sub-array is a row) and that cell defaults to 'A1'. This goes beyond the schema's brief descriptions.
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 the action: writing a two-dimensional array starting from a specific cell. It explains the row-major structure and the default starting cell. However, it does not explicitly contrast with sibling tools like wps_et_write_cell, but the purpose is distinct enough.
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 provided on when to use this tool versus alternatives (e.g., wps_et_write_cell for single cell writes, or other range operations). The description lacks any context about prerequisites, limitations, or selection criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 only states 'create a new blank document' without disclosing behavioral traits such as whether it opens a new window, returns a document handle, or affects the current application state. For a mutation tool, this is inadequate.
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 single sentence that conveys the essential purpose with no wasted words. It is appropriately sized for the tool's simplicity.
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 the tool has no parameters, no output schema, and no annotations, the description is complete enough for a basic understanding. However, it could be improved by mentioning what happens after creation (e.g., document becomes active, returns a document ID) to fully inform the agent.
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?
There are zero parameters, so the schema coverage is trivially 100%. The description adds no parameter information because none is needed. Baseline 3 is appropriate as the description does not need to compensate for missing schema details.
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 verb 'create' and the resource 'new blank WPS document', which is specific and distinguishes it from sibling tools like 'wps_word_open' (open existing) or 'wps_word_save'. There is no ambiguity about what the tool does.
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 (when a new blank document is needed) but provides no explicit guidance on when not to use, prerequisites, or alternatives. Since there are no other 'new' tools among siblings, the usage is straightforward, but the lack of any contextual guidance prevents a higher score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the tool opens a sidebar using the CreateTaskPane API but does not specify whether it is read-only, destructive, or what happens if the pane is already open. The phrase '可直接对话操作当前文档' implies modification via the pane, but the tool invocation itself may have no side effects on document content. This ambiguity leaves the agent without clear safety or effect 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 two concise Chinese sentences with no wasted words. The purpose is front-loaded (打开/唤起 Draftly 侧边栏), followed by technical and functional details. 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?
Given the tool has no parameters, no output schema, and no annotations, the description provides a reasonable high-level overview. However, it fails to mention what the agent can expect as a return value (likely void), and it does not clarify prerequisites (e.g., if a document must be open). These gaps reduce completeness for a simple action 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?
The tool has zero parameters, so dimension baselines at 4. The description adds meaning by explaining what the tool does (opens a sidebar) and its purpose (chat-based editing), which is relevant context beyond the empty schema. No parameter documentation is needed, and the baseline is appropriately applied.
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 opens/evokes the Draftly sidebar, a structured chat panel docked on the right side of the WPS main window. It specifies the verb (打开/唤起), resource (Draftly 侧边栏), and technical basis (Claude Agent SDK). This is distinct from all sibling tools, which focus on document editing, 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 Guidelines2/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It mentions the chat panel can operate the current document, but does not compare it to direct editing tools or explain scenarios where this conversational approach is preferred. Sibling tools like wps_word_read, wps_word_insert_text, etc., are all available without any usage trade-offs being indicated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 core behavior (adds a comment, find_text behavior), but it doesn't mention side effects (e.g., whether the document is saved, whether view changes), permissions required, or what happens if find_text is provided but not found. This is adequate but not thorough 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise—only two sentences. The first sentence states the purpose, and the second clarifies the parameter behavior. No wasted words; every sentence contributes essential information. This is excellent conciseness.
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 tool with only 2 parameters, no output schema, and no annotations, the description covers the basic usage and the key parameter interaction. However, it lacks details expected for a mutation tool: error handling (what if find_text not found?), where the comment appears in the UI, and whether the comment is visible to others. It is minimally complete but could be more robust.
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 100% (both text and find_text have descriptions in the schema), so the baseline is 3. The description adds value by explaining the relationship between find_text and the comment placement (if omitted, comment goes to document start), which goes beyond the schema's '要批注的目标文字（可选）'. This extra context justifies a point above baseline.
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 the tool adds a comment ('添加批注') and explains the two modes: with find_text to apply the comment to a specific text occurrence, without it the comment is placed at the first character of the document. This is a specific verb+resource and helps distinguish from sibling tools like wps_word_get_comments and wps_word_delete_comment, though it loses a point for not naming those siblings explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly notes when to use each parameter (with find_text for targeted comments, without for document-start comments), but it does not explain when to choose this tool over alternatives such as wps_word_insert_text or wps_word_replace, nor does it mention prerequisites like needing a document to be open. Guidance is functional but not complete regarding alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden for behavioral disclosure. It states the tool deletes a comment and that the index starts at 1, but does not mention whether deletion is permanent, requires specific permissions, or what happens if the index is invalid. With no annotations, a detailed behavioral description would be expected, but these details are missing.
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 very concise with two short sentences, no wasted words. However, it lacks some behavioral detail that might be necessary, but for a simple deletion operation it is appropriately sized.
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 single-parameter deletion tool with full schema coverage and sibling context available, the description provides minimum viability. It explains how to get the index (wps_word_get_comments) and the index base (1), but does not describe return values (no output schema exists) or error handling. It is adequate but leaves 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 100% with a single parameter that already describes itself as '批注序号，从 1 开始' (comment sequence number, starting from 1). The tool description repeats this information, adding no extra semantic value. Baseline is 3 due to high schema coverage.
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 explicitly states the tool deletes a specific comment (删除指定批注), which is a clear verb+resource pairing. It is distinguishable from sibling tools like wps_word_add_comment, wps_word_get_comments, and wps_word_resolve_revisions, though it does not explicitly differentiate itself.
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 advises that the index starts from 1 and directs the user to use wps_word_get_comments to obtain the index. This provides clear context for when to use the tool, though it does not explicitly state when not to use it or mention alternative tools for different operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It discloses that headings are extracted with their levels and text, but omits crucial behavioral details: read-only nature, required document state, behavior when no headings exist, performance implications, or error conditions. The description is too sparse for a tool with zero 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?
A single, front-loaded sentence that communicates the extraction purpose and scope with zero wasted words. It earns its place as a concise description for a simple tool.
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?
The description lacks context around prerequisites (e.g., document must be open), output format (no output schema), and edge cases (no headings). For a tool with no parameters and no output schema, the description should at least clarify these points to prevent agent confusion, especially given the large sibling set.
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?
There are zero parameters, and schema description coverage is 100% trivially. The baseline for 0 params is 4. The description adds useful context about what is extracted (heading style paragraphs only), which goes 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 clearly states the verb ('extract') and resource ('document outline') and specifies it retrieves the level and text of all heading style paragraphs. This distinguishes it from siblings like wps_word_read (full content) and wps_word_get_paragraphs (all paragraphs).
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 needing the document's structural outline rather than full content, but it offers no explicit guidance on when to use vs. alternatives, prerequisites (e.g., 'requires an open document'), or when not to use this tool. With many sibling tools, some directive would be helpful.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 key behavioral trait of applying to all slides when slide_index is omitted. However, it does not mention whether the operation is destructive, idempotent, or if any permissions are needed. Adequate but not 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 a single sentence, front-loaded with the action, and contains no wasted words. It is exceptionally concise.
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 tool (2 parameters, no output schema), the description covers the primary behavior and scope. It doesn't explain error conditions or return values, but these are less critical for a set operation. Reasonably 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 coverage is 100% with clear descriptions for both parameters. The description reinforces the slide_index default behavior but adds no new meaning beyond the schema. Baseline 3 is appropriate.
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 verb 'set' and resource 'slide background color', and specifies the scope behavior (all slides if no index). This is specific and distinguishes from sibling tools like wps_wpp_beautify_slide or wps_wpp_set_slide_title.
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 provides no guidance on when to use this tool vs alternatives, nor any exclusions or prerequisites. It only states what it does, leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose behavioral traits. It mentions that omitting dest_sheet causes automatic new sheet creation, and explains value_fields structure and allowed functions. However, it does not cover error handling, modification of existing data, permission requirements, or limits on data size.
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 a single paragraph of four sentences in Chinese, efficiently front-loaded with the primary action. It explains parameter structure without unnecessary elaboration, making it 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?
Given the tool's complexity (8 parameters, nested objects) and no output schema, the description adequately covers the core purpose, parameter structure, and default behavior. It omits return values and error handling, but for a creation tool with good schema coverage, it is sufficiently complete for an agent to use.
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 100%, so the baseline is 3. The description adds value by clarifying that row_fields/column_fields are header text arrays and detailing the value_fields object structure (field, func, name) with allowed functions. This slightly exceeds the schema's individual descriptions but does not significantly compensate for the high 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 clearly states the tool creates a pivot table based on a data range. It specifies the key parameters (row_fields, column_fields, value_fields) and their structure, distinguishing it from sibling tools like wps_et_create_chart or wps_et_sort_range which serve different spreadsheet operations.
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 implicitly defines the tool's purpose (creating pivot tables) but does not provide explicit guidance on when to use it versus alternatives, such as summarizing data with formulas or using other wps_et_* tools. No exclusions or alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description indicates a read operation by the verb 'get' and lists the information returned, but it does not explicitly state it is read-only, mention error conditions, or confirm no side effects. With no annotations, the description carries the burden and is minimally 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 a single sentence that front-loads the verb and resource. It is concise with no unnecessary words, earning its place by efficiently conveying the tool's purpose.
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 purpose and output items but lacks details on the return format or data type. Since there is no output schema, the description could be more complete by stating how the information is structured. Adequate for a simple tool but with a clear gap.
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 add parameter meaning. Schema coverage is trivially 100%. The baseline for no parameters is 4, and the description does not contradict this.
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 gets current workbook information, listing three specific items (name, number of sheets, current sheet name). It has a specific verb '获取' (get) and resource '当前工作簿信息' (current workbook info), distinguishing it from sibling tools like wps_et_get_sheets which focuses on sheet-level data.
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 provided on when to use this tool versus alternatives. There is no mention of when not to use it, prerequisites, or which sibling tools might be more appropriate for related tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It simply states the action (set slide size) without revealing side effects, whether it applies to all slides or the current slide, whether it is destructive, or any dependencies. This lack of behavioral context makes it insufficient for an agent to fully understand the implications of invocation.
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 extremely concise, consisting of two short lines. The first line states the purpose and unit, the second gives examples. Every word earns its place; there is no redundancy or fluff. The information is front-loaded and easy to parse for an agent, making it an ideal model of conciseness.
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 the tool's simplicity (2 parameters, no required fields, no output schema), the description covers the core function and provides useful value examples. However, it lacks details on whether the size applies to all slides or the current selection, what happens if parameters are omitted, and any return value or confirmation. These gaps reduce completeness, especially since annotations are absent.
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 already describes width and height as numbers in points (100% coverage), so the baseline is 3. However, the description adds practical value by providing common ratio examples (16:9 → 960x540, 4:3 → 720x540), which helps an agent choose appropriate values beyond the schema's dry definitions. This extra context justifies a score above baseline.
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 sets slide size, explicitly mentions the unit (points), and provides common aspect ratio examples (16:9 and 4:3), leaving no ambiguity about its function. The verb 'set' and resource 'slide size' directly match the tool name, effectively distinguishing it from siblings like wps_wpp_set_slide_title or wps_wpp_set_background.
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 does not provide any explicit guidance on when to use this tool versus alternatives or when not to use it. It only lists common size values, which implies typical use cases but omits context like prerequisites, restrictions, or comparative advice. While sibling tools do not overlap in functionality, the absence of usage guidance limits its helpfulness for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior2/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 disclosing behavioral traits. It only says 'list all worksheet names', which implies a read-only operation but does not mention return format, whether it operates on the active workbook, or any potential side effects. This is minimal and does not go beyond the 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 a single, concise sentence that directly states the tool's function. It is front-loaded with the key action and resource, containing no redundant words 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 the tool's simplicity (no parameters, no output schema, no annotations), the description is largely complete. It clearly communicates the purpose, though it doesn't specify the exact return structure (e.g., an array of strings). For a simple listing tool, this is sufficient for an agent to understand its function.
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 baseline score is 4. The description adds no parameter information, which is appropriate since there are none to document. No additional meaning is needed 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 states the action (list), the resource (worksheet names in the workbook), and distinguishes itself from sibling tools like wps_et_get_workbook_info by focusing specifically on sheet names. It is unambiguous and directly conveys the tool's purpose.
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 does not provide explicit guidance on when to use this tool versus alternatives. It simply states what it does, leaving the usage context implied. There are no alternative names or exclusions mentioned, so the agent must infer that this is the tool for listing sheet names.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 describes the tool as a diagnostic probe, suggesting it is non-destructive and read-only. However, it does not disclose what the output looks like, whether it requires an active document, or any side effects. The behavioral description is minimal and lacks details beyond the core purpose.
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 a single sentence that efficiently conveys the tool's purpose and intent. It is front-loaded with the action ('探测') and target. While concise, it could benefit from a brief mention of return value or typical usage context without becoming verbose. Overall, it is appropriately sized for the tool's simplicity.
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 the tool has no parameters and no output schema, the description is adequate but incomplete. It explains what the tool does (probe support for revision/comment APIs) but does not provide any details about the expected output or how to interpret the results. For a diagnostic tool, this is a notable gap. The sibling tools indicate a complex environment, so more context would be helpful.
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 zero parameters, and schema description coverage is 100%. The description does not need to add parameter semantics, and it correctly omits any parameter information. With no parameters, a baseline score of 4 is appropriate, as no additional elaboration is required.
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 ('探测' - detect/probe) and a clear resource ('修订模式/批注相关 API 支持度' - revision mode/comment API support). It explicitly states it is for diagnostic purposes, which distinguishes it from sibling tools that perform actions (e.g., wps_word_toggle_track_changes, wps_word_add_comment). The purpose is immediately clear.
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 includes '诊断用' (for diagnostic use), which implies the tool should be used to check API support before performing revision or comment operations. However, it does not provide explicit guidance on when to use it vs alternatives, nor does it mention when not to use it. The sibling tools are action-oriented, so the intention is inferred, but not explicitly stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 placement behavior (after original) and that it returns the new index. However, it does not mention any side effects, required permissions, or error handling (e.g., what happens if slide_index is out of bounds). The transparency is adequate but not rich.
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 extremely concise: two sentences, no wasted words. The action is front-loaded, and the return value is stated. 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 tool's simplicity (one parameter, no output schema, no annotations), the description is largely complete. It covers the core behavior and return value. It could mention that the slide must exist or that the index is 0-based, but these are minor omissions for a clear, simple 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 input schema already describes the parameter 'slide_index' with a Chinese description. The tool description does not add any additional meaning or usage context for the parameter. With 100% schema coverage, baseline is 3, and the description provides no extra 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 explicitly states the action 'duplicate', the resource 'slide', and the effect 'new page follows immediately after the original page'. It also mentions the return value 'new_slide_index'. This clearly distinguishes it from siblings like 'add_slide' (adds blank slide) or 'delete_slide'.
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 (to duplicate a slide) but provides no explicit guidance on when to use this tool versus alternatives like 'wps_wpp_add_slide' or 'wps_wpp_move_slide'. No prerequisites or context for when not to use it are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It correctly identifies the tool as a read-only information retrieval operation. However, it does not mention whether the document must be open, error conditions, or performance characteristics. No contradiction since annotations are absent.
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?
A single sentence in Chinese clearly states the tool's purpose and output. Every word is informative: '获取当前活动 Word 文档信息：文件名、路径、段落/字数/字符数、表格数。' No waste 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?
For a simple zero-parameter info retrieval tool, the description is largely complete in listing output fields. However, it does not mention what happens if no document is open, or if the document has no table count. With no output schema, the description could be slightly more explicit about format or edge cases.
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 has 0 parameters with 100% coverage. The description adds value by listing exactly what information is returned (file name, path, paragraph/word/character counts, table count), which the empty schema cannot convey. This fills the gap for 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 explicitly states the tool retrieves current active Word document info, listing specific attributes: file name, path, paragraph/word/character counts, and table count. This clearly distinguishes it from siblings like 'wps_word_get_paragraphs' or 'wps_word_read'.
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 getting document metadata when you need an overview, but does not provide explicit guidance on when to use it vs. alternatives like 'wps_word_read' or 'wps_word_get_outline'. No exclusions or timing advice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 states that the tool inserts a table and returns a shape_index, and explains why the indexing is needed. However, it does not describe side effects (e.g., overwriting existing shapes), boundary conditions (e.g., rows/cols >0), or potential errors. The transparency is adequate but lacks depth 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two efficient sentences. The first sentence states the core purpose, and the second provides critical context about the return value and indexing. Every word serves a purpose; there is no redundancy or fluff.
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 has 7 parameters and no output schema. The description explains the return value's role and indexing logic but does not cover defaults, error handling, or the format of shape_index. It also does not mention that size parameters (width, height) have defaults. While the core function is clear, some completeness is missing for a multi-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 input schema has 100% coverage with parameter descriptions including defaults (e.g., top=120, left=60). The description does not add any new meaning or clarify parameter usage beyond what the schema already provides. Per the baseline rule for high schema coverage, a score of 3 is appropriate.
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 (insert table) and the target (slide). It further explains how the returned shape_index is used with a sibling tool, distinguishing it from other table-creation tools like wps_word_create_table. This provides a specific verb+resource combination with sibling differentiation.
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 connects this tool to wps_wpp_write_table_cell and explains the unique indexing requirement for slide tables. This gives strong contextual guidance on when to use this tool (before writing to a slide table) and implies it is not for Word tables. A small omission is not stating prerequisites (e.g., slide must exist) or explicitly saying 'do not use for documents'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 clearly conveys the read-only behavior and enumerates output fields, but it does not mention edge cases like empty comment sets or whether the result is an array. This is adequate but not rich.
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?
A single concise sentence in Chinese efficiently conveys the action and the fields returned. It is front-loaded with the verb 读取 and avoids unnecessary 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?
As a parameterless getter with no output schema, the description lists the expected return fields, which is sufficient for most use cases. It could be more explicit about the return format, but overall it covers the essential 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?
The tool has zero parameters, so schema description coverage is trivially 100%. Per the rubric, a baseline of 4 applies, and the description correctly focuses on the output rather than parameters. No further explanation is needed.
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 reads all comments in the document and specifies the returned fields (序号, 作者, 内容, 被批注的原文). This distinguishes it from sibling tools like wps_word_add_comment and wps_word_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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when retrieving comments, but it does not explicitly state when to use it over alternatives such as wps_word_add_comment or wps_word_get_revisions. The sibling list provides context, but no direct guidance is given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 that enabling records subsequent edits as revisions and mentions related tools. However, it does not address idempotency (what happens if already enabled/disabled), permissions, or whether the effect is document-wide. The description is adequate for a simple toggle but lacks some behavioral detail.
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 consists of two concise sentences. The first sentence directly states the purpose, and the second explains the effect and links to related tools. Every word is meaningful; no wasted space. Front-loaded and easy to parse.
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 boolean toggle tool with no output schema and no annotations, the description is reasonably complete. It covers the action, the effect, and downstream tools. It could optionally mention the return value (e.g., success/failure) or error conditions, but these are not essential for correct usage. The description provides sufficient context for an agent to use this 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 coverage is 100% with a single boolean parameter described in the schema. The tool description restates the parameter's purpose (enable/disable) but adds no additional semantics beyond the schema. It does not explain default behavior, error cases, or edge cases for the parameter. Baseline 3 is appropriate given high 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 clearly states the verb 'toggle' (开启/关闭) and resource 'track changes mode'. It distinguishes from sibling tools by explicitly mentioning related tools for viewing and resolving revisions, making the tool's role in the workflow 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 explains when to use this tool (to enable/disable track changes) and what happens after enabling (edits recorded as revisions). It references sibling tools for viewing and resolving revisions, providing guidance on subsequent steps. However, it does not explicitly state when not to use it or alternative approaches, though for a simple toggle such exclusions are not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears the full burden. It states the result (sequence number) but doesn't disclose side effects, error conditions, or whether the call is read-only. The description is truthful but minimal; it does not contradict any 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?
A single, clear sentence in Chinese that fully describes the tool's function. No wasted words; front-loaded and efficient.
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 zero-parameter tool without an output schema, the description adequately covers the core functionality. It does not explain behavior if no presentation is open or if there is no current slide, but the tool is simple enough that this is sufficient.
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 schema is trivially 100% covered. The description adds no parameter information, which is acceptable. Per guidelines, baseline for no parameters is 4.
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's purpose: getting the sequence number of the current slide. The verb '获取' (get) and resource '当前所在幻灯片的序号' (current slide's sequence number) are specific. It distinguishes well from sibling tools like wps_wpp_read_slide or wps_wpp_add_slide.
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 guidance on when or when not to use this tool versus alternatives is provided. For a simple getter, usage is implied, but the absence of explicit context or prerequisites keeps it at an adequate but not exemplary level.
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 description must cover behavioral traits. It clearly states the tool is a read-only operation (get info) and lists the returned fields (name, slide count), providing adequate transparency for a simple query 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?
Single sentence, perfectly concise. States verb, resource, and outputs 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?
Given no parameters and no output schema, description is nearly complete. It specifies purpose and outputs. Could optionally mention the data format (string/integer), but not required for a simple info tool. No output schema is needed based on this tool's simplicity.
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 has zero parameters and description coverage is 100%. Description adds meaning by specifying the exact info returned (name and slide count), which is not in the schema. With no parameters, this is fully appropriate.
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?
Description clearly states this tool retrieves presentation info (name and slide count). It differentiates from siblings like wps_wpp_get_current_slide, which focuses on the current slide, and wps_wpp_read_slide, which reads slide content.
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?
Implied usage: get basic metadata about the active presentation. No explicit guidance on when to use this vs siblings (e.g., vs wps_wpp_probe for richer info). No exclusions 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?
The description discloses how freeze_rows and freeze_cols interact (pass 0 or omit to avoid freezing that direction) and how freeze:false cancels freeze. This adds behavioral context beyond the schema, though it could mention that modifications apply to the current or specified sheet.
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 long, front-loaded with the purpose, and contains no redundant information. Every word serves a clear function.
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 tool with 4 parameters and no output schema, the description is sufficiently complete. It explains the core operation and parameter effects, though it could mention the default sheet behavior (already in schema) or any 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 description adds meaning beyond the schema by explaining the effect of 0 values and the combination of freeze_rows and freeze_cols. Since schema coverage is 100%, the baseline is 3, but the description enhances understanding of parameter behavior.
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 verb ('freeze panes') and the resource ('rows and columns'). It distinguishes itself from sibling tools by being a dedicated freeze panes operation, which is unique among the spreadsheet tools.
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 explains the tool's functionality but does not provide explicit guidance on when to use it versus alternatives. However, the context is clear enough that an agent can infer its use for freezing rows/columns, so it is adequate but not directive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 describes the tool as a read operation (scanning) and lists outputs, but does not disclose potential side effects, performance implications, or auth requirements. The behavior is simple enough that the lack of detail is acceptable, but not exemplary.
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 in Chinese, each earning its place: the first lists the output, the second gives usage guidance. No filler, front-loaded with purpose, highly efficient.
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 no parameters and no output schema, the description adequately explains what the tool returns and when to use it. It could be more precise about the return format, but the list of returned items is sufficient for a context-gathering tool. Sibling tools like wps_et_probe exist, but this description defines its own niche.
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 there is no schema to add meaning to. The description compensates by explaining the output items, which is valuable for an agent. The baseline for 0-param tools is 4, and the description meets 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 clearly states the tool's purpose: 'scan table context' and lists specific items it returns (current table, all worksheet names, UsedRange, selected cells, header row). It distinguishes itself from sibling tools like wps_et_probe or wps_et_get_selection by covering a broad set of context 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 explicitly says 'call it before modifying the table to understand the structure,' providing a clear when-to-use directive. It does not mention when not to use or alternatives, but the guidance is sufficient for a discovery tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It explains the action (insert section break), default type, and notes that WPS paragraph page breaks also create sections. However, it does not disclose potential side effects (e.g., impact on existing formatting, whether the operation is undoable, or if the document must be open). The description is adequate but not rich.
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, front-loaded with the core purpose. Every sentence adds value: the first states the action and use case, the second clarifies the default and notes an alternative behavior. No 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?
Given the tool has one optional parameter, no output schema, and no annotations, the description covers the essential aspects: purpose, default, and a relevant note about paragraph breaks. It could mention that the document must be open, but that is implied by the tool family. Overall, it is sufficiently complete for a simple operation.
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 100% coverage (one parameter with enum and description). The tool description adds value beyond the schema by explaining the default type ('默认 next_page') and providing context about when to use different types. This extra information helps the agent choose the correct parameter 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 clearly states the action ('在文末插入分节符' – insert section break at end of document) and the specific use case ('分节封面'等需要独立页码/页脚的场景). It also specifies the default type. This is a specific verb+resource, and it is distinct from sibling tools like 'wps_word_probe_sections' or 'wps_word_insert_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 provides a clear usage scenario (independent page numbers/footers) and mentions that paragraph page breaks also create new sections, implying this tool is for explicit control. However, it does not explicitly state when *not* to use it or list alternative tools (e.g., 'wps_word_insert_text' for manual page breaks).
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. It discloses key behaviors: atomic append+formatting, no cursor dependency, empty document handling, and page break via \x0c. It lacks details on error handling, undo behavior, or return value, but covers core traits adequately.
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 concise—three sentences without redundancy. It front-loads the main purpose and function, with supporting details following efficiently.
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 11 parameters, no output schema, and many siblings, the description covers purpose, usage context, and key behavioral traits. It omits return value and error scenarios but is overall sufficient for an agent to understand when and how to use 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 coverage is 100%, so baseline is 3. The description lists formatting options but adds no significant meaning beyond the schema's parameter descriptions. It clarifies that formatting applies to the same paragraph, which is marginally 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?
The description clearly states the verb (append), resource (paragraph at end of document), and scope (with formatting in one call). It distinguishes from siblings like wps_word_insert_text (which inserts at cursor) and separate formatting 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 specifies it is 'independent of cursor position' and 'safe for linear typesetting like theses', and that empty documents get a first paragraph. It implicitly differentiates from cursor-dependent tools but 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. It discloses the key behavioral trait: the document is closed without saving. This is essential for an agent to understand the irreversible nature. However, it does not mention any confirmation prompts or other side effects, which 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 a single, short sentence that is front-loaded and contains no unnecessary words. It is highly concise and structured effectively.
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 parameters and no output schema, the description is complete enough. It clarifies the action and the important behavior (no save). It could mention that the document is permanently closed, but the current text implies this.
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?
There are no parameters, so the description does not need to add parameter semantics. The schema coverage is 100% by default. The description is sufficient for a parameterless 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 clearly states the action: close the current document. It specifies the resource (current document) and the verb (close), and distinguishes it from sibling tools like wps_word_save or wps_word_open.
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 does not explicitly state when to use this tool versus alternatives. It implies that it closes without saving, but does not guide the agent on when to save first or use other tools. For a simple tool, this is acceptable but not exemplary.
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 discloses key behavioral traits: inserts at document end regardless of cursor, and creates a table with default gridlines/borders. It does not cover failure modes or permission requirements, but the stated behaviors are clear. A more thorough description could mention idempotency or side effects on existing content.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just two short sentences, yet it communicates purpose, behavior, and usage guidance. There is no extraneous information. The main action is front-loaded, and the workflow tip adds value 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?
Given no output schema and only two simple parameters, the description is nearly complete: it specifies insertion position, border style, and integration with append_paragraph. It lacks explanation of default table formatting or constraints (e.g., minimum rows/cols), but for this tool, the description covers essential context adequately.
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 100%, and the description does not add additional parameter semantics beyond what the schema already provides. The parameters (rows, cols) are self-explanatory integers. The description does not enhance understanding of the parameters, so a baseline score of 3 is appropriate.
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 inserts a table with borders at the end of the document, independent of cursor. It specifies the default gridline style and distinguishes itself by not relying on cursor position, setting it apart from any potential alternative table creation workflows.
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 explicit workflow guidance: use with append_paragraph to add a title before and content after the table. It clearly states when to use this tool within a sequence. However, it does not explicitly mention when not to use it or list alternatives, but given the simplicity and uniqueness of this tool, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It successfully communicates a key behavior: when replace_all is false, only the first match is replaced. This adds critical context like a dependency on the replace_all parameter for mode control. However, it does not specify side effects (e.g., whether the replacement triggers track changes, whether selection is affected, or if formatting is preserved), leaving room for improvement. Despite that, the description provides meaningful insight 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 extremely concise with two sentences and no superfluous text. The first sentence states the core purpose, and the second provides a critical behavioral note. Every word earns its place, making it highly efficient for an AI agent to parse quickly.
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 has 3 simple parameters, no output schema, and a straightforward function (find-and-replace in a WPS Word document), the description provides enough context: it explains the basic operation and the key parameter behavior. It does not explain what happens with no matches or whether formatting is preserved, but with low complexity, the coverage is sufficient. The explicit single-vs-all behavior compensates for missing output schema 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 100%, so the baseline is 3. The description adds value by clarifying that replace_all=false limits to first match, which is not fully explained in the schema's description ('是否全部替换，默认 true'). This nuance helps the agent understand the parameter's impact on tool behavior, justifying an above-baseline score. However, the find_text and replace_text parameters' format or case-sensitivity are not elaborated, preventing a top score.
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 title 'wps_word_replace' and description '查找替换' clearly indicate the tool performs find-and-replace in a WPS Word document. The description explicitly distinguishes between single and all replacements with 'replace_all=false 只替换第一处' (replace_all=false only replaces the first occurrence), which differentiates it from a simple 'replace all' behavior. This unambiguous verb+resource pair with behavioral nuance earns a top score.
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 for find-and-replace tasks, and the sibling tools list includes many other WPS Word operations (e.g., wps_word_insert_text, wps_word_read). However, no explicit guidance is provided on when to use this tool versus alternatives like wps_word_get_selection for manual replacement or wps_word_insert_text for simple text entry. The description lacks 'when-not-to-use' or contextual exclusions, earning a median score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full responsibility for behavioral disclosure. It adds value by specifying the exact line thicknesses for the three_line style (2.25pt top/bottom, 0.5pt column line) and noting that vertical lines are removed. However, it does not disclose the behavior for grid style (no thickness given), what happens if the table_index is invalid, or whether the operation is reversible. The description partially compensates for missing annotations but leaves gaps.
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 extremely concise: two short sentences in Chinese. The first sentence states the purpose and enumerates the style options with details. The second sentence provides usage timing (call after table creation). Every word serves a purpose, and the key information is front-loaded. 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 the tool's low complexity (2 parameters, simple enum, no output schema, no annotations), the description covers the essential aspects: what each style does, when to invoke it (after table creation). It is missing details on the grid style's exact appearance, error conditions, or reversibility. However, for a straightforward border-setting operation, the provided information is largely sufficient for correct usage, earning a 4 rather than a 5 due to the minor gap on grid style specifics.
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 100% (both parameters have descriptions). The tool description adds significant meaning beyond the schema: for the 'style' parameter, it explains the three_line style in detail (thicknesses, no vertical lines) and clarifies that grid means regular grid lines. The schema only says '边框样式，默认 grid'. For 'table_index', the description does not add new information but references the existing schema description. The extra detail on style values justifies a score above the baseline of 3.
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 sets table border styles, naming two specific styles ('three_line' for thesis tables and 'grid' for regular grid). It provides distinctive details about the three_line style's thicknesses and absence of vertical lines, which differentiates it from any other border-related tool among siblings. The verb '设置' (set) plus resource '表格边框样式' (table border style) is specific 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 explicitly advises to call this tool after creating the table ('建表后调用'), giving a clear timing instruction. It implies using it to transform default full borders into a three-line or grid style. While there are no alternative border tools among siblings to exclude, the provided usage context is clear and practical, though it does not explicitly mention 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.
- Behavior3/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 that the tool updates fields (TOC and PAGE), implying a write operation. However, it does not mention potential side effects (e.g., saving, undo ability, performance impact) or whether the operation is reversible. The description is adequate but lacks additional behavioral context beyond the 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?
The description is extremely concise: two sentences in Chinese. The first sentence states the action and its effect, the second provides usage timing. Every sentence is informative and there is no wasted 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?
Given the tool's simplicity (no parameters, no output schema), the description is reasonably complete. It covers what the tool does (updates all fields) and when to use it. It does not explicitly mention handling of other field types beyond TOC and PAGE, but '全文所有域' implies all fields, and the examples are sufficient. A minor gap is lack of mention of prerequisites (e.g., document must have a TOC), but this is minor.
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 and schema coverage is 100% (vacuously). According to the scoring guidelines, a baseline of 4 applies. The description adds value by explaining the effect on TOC and page numbers, which is necessary since there are no parameters to convey this information.
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 ('更新' - update) and resource ('全文所有域' - all fields in the entire document). It clearly identifies the tool's function as regenerating TOC and refreshing page numbers, which effectively distinguishes it from sibling tools like insert_text, replace, etc.
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 explicit when-to-use guidance: '写完全文后调用它' (call it after finishing writing the document). This gives clear context for the tool's intended use case. It does not explicitly state when not to use it or mention alternatives, but given the tool's specialized nature, such exclusions are not necessary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It discloses the silent failure behavior due to path authorization and states the visual unification effect. However, it does not mention whether the operation is reversible, what happens to existing content, or any other side effects beyond the sandbox issue.
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 highly informative sentences with zero waste. The purpose is front-loaded, and the critical path authorization warning is placed immediately after. Every word 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 one-parameter tool with no output schema, the description covers the operation, accepted file types, and the important sandbox constraint. Minor gaps: it does not explicitly state that the presentation is modified in-place or whether the operation is reversible, but these are largely 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?
The single parameter 'path' has schema description '绝对路径'. The description adds the file extensions (.pptx/.potx) and the crucial sandbox authorization recommendation, which adds meaningful context beyond the schema 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?
The description clearly states 'Apply theme/template file (.pptx/.potx absolute path)' and 'unify visual style across whole presentation', which is a specific verb+resource pairing. It distinguishes from siblings like wps_wpp_unify_font or wps_wpp_beautify_slide by focusing on full template 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 provides explicit context: it explains the sandbox authorization constraint and recommends placing template files in ~/Downloads to avoid silent failure. However, it does not explicitly contrast with alternative tools for partial styling tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 behavior. It states the tool reads the outline and what content is returned (titles and all text), which is useful. However, it does not explicitly mention that the operation is read-only and non-destructive, nor does it describe potential limitations (e.g., hidden slides, return format), leaving some room for ambiguity.
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 single, well-structured sentence that immediately states the tool's purpose and then gives a concrete usage example. No unnecessary words or repetition, making it highly concise and 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 tool has no parameters and no output schema, the description adequately covers what the tool does and when to use it. It explains the return content (titles and all text) and the intended post-generation validation context. It could be slightly more explicit about prerequisites (e.g., an open presentation) but is otherwise complete for a simple read 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?
The input schema has zero parameters, so the baseline is 4. The description adds no parameter-specific detail, but with no parameters to document, this is acceptable and does not need to compensate for any coverage 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 clearly states the tool reads the full presentation outline, including page-by-page titles and all text. The verb '读取' (read) combined with the specific resource '全篇演示文稿大纲' distinguishes it from sibling tools like wps_wpp_read_slide or wps_wpp_get_presentation_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?
It provides a clear usage context: '用于生成完毕后整体校验内容是否正确' (used to verify content correctness after generation). However, it does not explicitly mention when not to use it or point to alternatives like reading individual slides, 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.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It honestly discloses that shape animation functionality is excluded because the underlying API causes WPS crashes, which is a critical behavioral trait. It does not detail side effects like overwriting existing transitions, but the scope is clearly defined.
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: the first states the core function and an important limitation, the second gives a key usage hint. It is front-loaded, no redundant words, and 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?
Given no output schema and no annotations, the description covers the tool's purpose, its boundary (no shape animations), and a critical usage condition. It lacks details on return values or version-specific behavior for effect_code, but is adequate for a setter tool with well-documented parameters.
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 100%, so baseline is 3. The description only adds context about slide_index (applies to all if omitted). For other parameters (duration, effect_code, advance_time, advance_on_click), the schema descriptions already explain their meaning, and the tool description does not add significant new 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 uses a specific verb ('set') and resource ('slide transition effect'), and explicitly distinguishes page transitions from shape animations, which prevents confusion with unrelated concepts. Among sibling tools, there is no other transition tool, so it uniquely identifies 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that shape animations are not provided due to crash risks, indirectly indicating this tool is only for page transitions. It gives a clear usage note about applying to all slides if slide_index is omitted, but does not explicitly state when to prefer this tool over alternatives (though no direct alternative exists).
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 full burden. It discloses the critical behavior: omitting path on an unsaved workbook triggers an error (with mitigation documented), and the path is subject to sandbox restrictions. This goes beyond a simple 'save' statement. Missing details on return value or side effects, but the key behavioral risks are addressed.
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, front-loaded with the main action. Every sentence earns its place: the first states the core function, the second provides critical usage and behavioral details. No wasted words.
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 simple save operation with no output schema, the description covers usage and behavioral constraints well. However, it does not mention what the tool returns (e.g., success, path, error), which leaves the agent guessing about the outcome. This is a notable gap given the lack of output schema.
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 100% (one parameter with description). The tool description adds value by explaining the parameter's necessity for first saves, the consequence of not providing it, and the sandbox context. This goes beyond the schema's brief 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 clearly states the tool saves the current workbook (wps_et_save for WPS spreadsheet). It distinguishes from sibling save tools by specifying '当前工作簿' (current workbook) and the ET context, while siblings like wps_word_save target different document types.
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 explains when to use the path parameter (first-time save) and warns about the native dialog freeze if omitted. It also mentions the WPS sandbox restriction and suggests using ~/Downloads. However, it does not provide explicit when-not-to-use guidance or compare with other save tools, though the sibling context makes this 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?
The description indicates the tool reads by paragraph, returning strings, and has a configurable limit. Since no annotations are provided, the description carries full burden. It is transparent about behavior but could mention whether formatting is preserved or if the output is plain text. Still, 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 extremely concise: two short sentences that convey purpose, output format, and usage context. No superfluous information. Every word 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 tool's simplicity (one optional parameter, no output schema, no nested objects), the description is complete. It explains what it does, how it returns data, and when to use it. No missing context for effective usage.
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 100%, so the baseline is 3. The parameter 'max_paragraphs' is described in the schema as '最多返回段落数，默认 200', which is clear. The description reiterates '每段一个字符串' but adds no additional semantic detail beyond what the schema provides.
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 reads the current document by paragraphs, returning each paragraph as a string. It distinguishes itself by noting suitability for long documents or locating specific paragraphs, differentiating from tools like wps_word_read, wps_word_get_selection, and wps_word_get_outline.
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 mentions use cases: reading long documents or locating paragraphs. It implies this is for sequential paragraph reading. However, it does not explicitly state when NOT to use it or provide alternatives among sibling tools, leaving some ambiguity about overlapping functions like wps_word_read or wps_word_get_outline.
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 fully carries the burden of disclosing behavioral traits. It warns about silent interception and insertion failure if the path is unauthorized, which is critical information 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 front-loaded with the purpose statement. The caution about sandbox restrictions is necessary but somewhat verbose. It earns its place but could be slightly trimmed.
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 3 parameters, no output schema, and no annotations, the description covers the core functionality and a critical behavioral nuance. It adequately prepares the agent for using the tool in sandboxed environments.
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 100% and parameter descriptions are already clear. The description reinforces path authorization but does not add new semantic meaning beyond what the schema provides. Baseline 3 is appropriate.
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 '在光标处插入图片' (insert image at cursor) with specific verb and resource. Among siblings, it distinguishes itself as a Word-specific image insertion tool, unlike wps_word_insert_text or wps_wpp_insert_image.
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 explicit guidance on when to use by detailing WPS sandbox authorization constraints and recommending placing images in ~/Downloads. It does not include when-not-to-use or alternative tools, but the precautions are highly 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 carries the full burden of behavioral disclosure. It explicitly states the critical side-effect (no save), which is essential for an agent to avoid data loss. This is a key behavioral trait beyond the basic action of closing.
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 single, front-loaded sentence containing only essential information: action, object, and critical side-effect. Every word earns its place with no waste.
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 simplicity (0 parameters, no output schema, no nested objects), the description is complete. It clearly states what the tool does and its major behavioral consequence. There are no missing details needed for a human or agent to use 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?
The schema has 0 parameters, so the description has no parameters to document. Schema description coverage is 100%, so there is no gap. The description doesn't need to add parameter meaning; the 0-param context is fully covered. A baseline of 4 is appropriate given the minimal complexity.
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 verb (关闭, close), resource (当前演示文稿, current presentation), and the critical side-effect (不保存, without saving). This distinguishes it from siblings like wps_wpp_save and wps_word_close, which operate on different contexts or actions.
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 destructive action (closing without saving) but does not explicitly state when to use this tool versus alternatives like wps_wpp_save. No exclusion criteria or prerequisites are mentioned, but the context of 'close' and 'don't save' is reasonably clear for a developer familiar with document workflows.
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 bears full responsibility. It discloses critical behaviors: the blocking dialog when file is already open, the sandbox path restrictions, and that errors are explicit (no false success). This level of detail for a simple open operation is exceptional.
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 efficiently structured: the first sentence states the primary purpose, followed by two separate warning paragraphs. Every sentence serves a purpose, and there is no redundant or unnecessary text. It is concise yet comprehensive.
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, critical behavioral caveats, and error behavior. It does not explicitly describe the return value or confirm success, but for an open tool with no output schema this is a minor gap. Given the complexity (single param, no nested objects), the description is nearly 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?
The single parameter 'path' has schema coverage at 100% with description '文件绝对路径'. The tool description adds context about path authorization (sandbox restrictions) but does not add new semantic meaning beyond what the schema already provides. Baseline 3 is appropriate.
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 opens local or cloud-synced spreadsheet files, using a specific verb (打开) and resource (表格文件). This distinguishes it from sibling tools like wps_word_open and wps_wpp_open which target different document types.
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 explicit guidance: warns against opening files already open in WPS (causes blocking dialog) and explains sandbox restrictions with actionable advice. It does not explicitly name alternative tools, but the purpose implies when to use this tool versus sibling open 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 must fully disclose behavior. It does so by explaining the return format (2D array), indexing (0-based row/column), and the special case of no cell parameter returning an {address, value} structure. It also clarifies that single cells return a nested array. The only missing detail is whether the tool is read-only or destructive, but the name 'read_range' and the description strongly imply a read operation, mitigating this 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 extremely concise, consisting of just three sentences covering all key points: purpose, return format, single vs range behavior, and optional parameter behavior. No extraneous information. Every sentence is necessary and front-loaded with the most important information 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 1 optional parameter, no output schema, and no nested objects, the description is nearly complete. It covers the input, all output cases, and the expected indexing. It could optionally mention that the returned address for selection reading is a string like 'A1:B3', but this is implicit from the context. The sibling tools (e.g., wps_et_write_range) are clearly differentiated.
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 100%, with the schema already describing the cell parameter as '单元格地址。单格 A1 或区域 A1:B3，统一返回二维数组 value[r][c]'. The description adds significant value beyond the schema by explaining the return format in detail, including 0-based indexing, the difference between single cell and range output, and the behavior when no cell is provided. This richness merits a score above baseline 3.
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 '读取单元格值' (read cell value) and specifies the return format: a 2D array where value[r][c] directly maps to row and column, with the first cell at value[0][0]. It distinguishes between single cell and range inputs, and explains the behavior when no cell parameter is provided. This effectively differentiates it from siblings like wps_et_write_range or wps_et_set_formula.
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 guidance on how to use the tool: pass a cell address (single like 'A1' or range like 'A1:B3') or omit to read the current selection. It explains the return structure for each case. However, it does not explicitly state when not to use this tool versus alternatives (e.g., wps_et_write_range is for writing, not reading), but the sibling tools are sufficiently distinct in 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 provided, the description carries the full burden of behavioral disclosure. It effectively conveys the tool's mutation behavior (modifying cell formatting) and covers all four operational modes, though it could add notes on scope (e.g., what happens to overlapping formats) or performance implications on large ranges. The description is transparent enough for safe use.
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 single, well-structured sentence with type-specific details separated by semicolons. It front-loads the tool's purpose and efficiently conveys all operational modes and parameter relationships without repetition or 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?
Given the tool's moderate complexity (8 parameters, 4 modes), the description covers all types and key parameter combinations. The high schema coverage (100%) and lack of output schema reduce the need for return value documentation. It could add a note about the clear type's effect on existing formats or default values, but overall it is sufficiently complete for effective agent use.
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 100%, so the baseline is 3. The description adds significant value beyond the schema by explaining how parameters combine for each type (e.g., operator+value1[+value2]+fill_color/font_color for cell_value). This provides crucial semantic context that the schema's individual descriptions lack, particularly for conditional logic and color construction.
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 sets conditional formatting for WPS spreadsheets. It lists the four types (cell_value, color_scale, data_bar, clear) with specific formatting details for each, differentiating itself from sibling tools like wps_et_format_range and wps_et_clear_range, which handle general formatting or clearing without the conditional logic.
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 each type (e.g., cell_value for comparisons, clear for removal). However, it does not explicitly state when not to use this tool or mention alternatives among siblings, though being the only conditional formatting tool in the list, this is less critical. The guidance is practical and sufficient for a well-informed agent.
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 burden. It explains what happens after writing (ET computes formula), how to interpret results (numeric success, #-prefix errors), and gives Excel-standard semantic clarification for functions like VLOOKUP. A slight deduction because it doesn't mention whether the write is destructive to existing cell content or if multiple writes are idempotent.
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 (two sentences) and front-loads the primary action, then immediately provides critical follow-up instructions. Every sentence adds unique value: first sentence states action and engine, second gives verification protocol and error patterns, with parenthetical adding semantic nuance. Zero waste.
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 no output schema, the description compensates well by explaining what to expect after execution (numeric value vs #-prefix errors). It doesn't explain pagination or batch behavior, but this is a simple single-cell formula write with two required params. Could mention whether the formula must reference existing ranges, but overall complete for typical spreadsheet formula usage.
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 100% (both cell and formula have descriptions). The input schema already documents cell as a string like 'D2' and formula as a string starting with '='. The description adds mild value by giving formula examples (=VLOOKUP(...), =SUMIF(...), =SUMPRODUCT(...)) but doesn't significantly expand beyond schema—baseline 3 is appropriate.
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 writes a formula to a cell (specific verb '向单元格写入公式'), explicitly requires the formula to start with '=', and notes that ET engine performs actual computation. It also distinguishes from nearby Excel functions like wps_et_write_range or wps_et_read_range by focusing on formula writing.
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 users they must call read_range after writing to verify results—this is a mandatory follow-up step. It also lists error patterns (#NAME?, #REF!, #VALUE!) that indicate formula errors, providing clear diagnostic guidance. While it doesn't name explicit sibling tools, the 'must read back' advice is protocol-level 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 fully bears the transparency burden. It discloses that this is a hot update requiring no restart, and it affects the add-in code immediately. However, it does not mention potential side effects (e.g., state loss, reinitialization impact) or any prerequisites or permissions, which would have been useful for a mutation-like 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 two concise sentences in Chinese: first defines the purpose and benefit, second explains the usage context. Every part is essential, no redundancy. It is front-loaded with the core action and benefit.
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 tool with one optional parameter and no output schema, the description covers the core purpose, usage trigger, and default parameter behavior. Missing information (e.g., return value, error conditions) is acceptable given the tool's simplicity, but could be slightly more complete if it mentioned that it returns nothing or indicates success.
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 100% coverage with a clear enum and description. The description adds value beyond the schema by explicitly stating the default behavior when 'host' is omitted ('所有三个宿主都重载'), which is not captured in the schema. This helps the agent understand optionality.
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 ('reload addin code'), the resource ('specified host's WPS add-in'), and the benefit (hot update without restart). It distinguishes itself from sibling document-operation tools by being a maintenance/reload utility, and the title 'reload_addin' reinforces this.
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 explicit when-to-use guidance: after modifying add-in JS (including republish/manual sync). It also explains the default behavior when 'host' is omitted. No alternative tools exist among siblings, so no exclusion criteria are needed, but explicit when-not-to-use is absent.
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 explicitly states the tool is read-only ('只读，不修改文档'), which is a key behavioral trait. It also discloses the prerequisite (track changes must be enabled). It does not mention potential edge cases (e.g., empty result if no revisions) or return format, but the core behavioral characteristic is transparently communicated.
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 single sentence that efficiently conveys the purpose, prerequisite, and return fields. It is front-loaded with the main action and uses a colon to separate the action from the details. Every part is essential; 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 the tool has no parameters, no output schema, and no annotations, the description adequately covers the purpose, the fields returned, the prerequisite, and the read-only nature. It does not explicitly state the return format (e.g., array of objects) or behavior when there are no revisions, but the listed fields imply the structure. This is sufficient for a simple retrieval 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?
The tool has zero parameters, and schema coverage is 100%. According to guidelines, this earns a baseline of 4. The description does not add parameter-specific details because there are none, but it provides context about the prerequisite (track changes mode) which is relevant to understanding the tool's operation even though it is not a 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 clearly states the verb ('读取' - read) and resource ('修订记录' - revision records), lists the specific fields returned (序号、类型、作者、涉及文字), and distinguishes itself from siblings by explicitly noting it is read-only and requires track changes to be enabled first. This aligns with the tool's name and differentiates it from tools like `wps_word_resolve_revisions` which modifies revisions.
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 includes a critical prerequisite: '需先开启修订模式才会产生修订' (need to enable track changes mode first). This tells the agent when to use the tool (after enabling track changes) and implicitly when not to (if track changes is off). It also states the tool is read-only, implying it is safe to call without side effects. However, it does not explicitly contrast with alternatives like `wps_word_get_comments` or `wps_word_resolve_revisions`.
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 tool's behavior: it probes ('探测') specific sectioning and page number capabilities. The term '探测' implies a read-only investigation, and the listed items (section count, footer link status, restart numbering capability) give clear behavioral expectations. However, it does not explicitly state that the tool is non-destructive or require any permissions.
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, both front-loaded with essential information. The first sentence states the core function and what it checks, the second provides a concrete usage scenario. Every word earns its place; there is no redundancy or fluff.
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 has no parameters and no output schema, the description provides a reasonable set of expectations: it checks section count, footer link status, and restart numbering capability. It also explains why an agent would use it (thesis page numbering). However, it does not describe the return format or structure, which would be helpful for a more complete understanding.
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 zero parameters, and schema description coverage is 100% (vacuously). Per guidelines, 0 parameters sets a baseline of 4. The description adds no parameter information because there are none to describe, but it also does not introduce any confusion. The score reflects the baseline with no deduction.
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's function: '探测当前文档分节与页码 API 的支持度' (detect support of sectioning and page number API). It specifies the exact items checked (number of sections, footer link status, PageNumbers restart numbering capability) and provides a concrete use case for thesis page numbering. This distinguishes it from sibling tools like wps_word_probe and wps_word_add_section_break.
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 specific scenario: '用于判断论文正文页码从1重新开始、封面无页码的分节方案是否可行' (used to determine if the sectioning scheme for thesis body page numbers restart from 1, cover no page numbers is feasible). This provides clear context for when to use the tool. However, it does not explicitly mention when not to use it or compare with alternatives like wps_word_probe, which slightly reduces 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 provided, the description carries the full burden of behavioral disclosure. It effectively warns that omitting the path on an unsaved document would previously freeze the process but now raises an error instead. It also explains the sandbox constraint on the path. Missing details about overwrite behavior or return values, but the key safety behaviors are 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 concise, comprising three focused sentences. It front-loads the core action, then adds necessary conditional behavior and a practical suggestion. No wasted words; 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?
Given the tool's simplicity (one optional parameter, no output schema), the description is quite complete. It covers the main behavioral nuance (path requirement for first save) and the sandbox aspect. It does not elaborate on return values or error handling beyond the freeze mitigation, but these are minor omissions for a save 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?
The schema already provides 100% coverage with a description for the single 'path' parameter. The tool description adds value by explaining when the parameter is required (first save) and the sandbox restriction with a recommended path (~/Downloads). This goes beyond the schema's simple 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 clearly states the action '保存当前文档' (save the current document) and distinguishes it from sibling tools like wps_word_new, wps_word_open, and wps_word_close. It adds specific context about the path parameter's necessity based on save history, 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear guidance on when to include the path parameter (first save) and when it can be omitted (already saved). It also warns about the sandbox restriction and recommends ~/Downloads. However, it does not explicitly compare to alternative save-related tools like wps_word_export_pdf, so some usage context is implied rather than fully 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, the description carries full burden. It discloses the different behavior for unsaved vs. already-saved documents, the risk of a freezable dialog (and current mitigation), and the path sandbox constraint. This is substantial behavioral transparency for a save 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 two sentences in Chinese, front-loaded with the purpose, and every sentence provides essential information. There is no fluff 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 single-parameter save tool with no output schema, the description covers the key edge cases and restrictions. It could mention what happens on success (e.g., saved file location) but the core context is adequately covered.
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 100%, so the baseline is 3. The description adds significant meaning beyond the schema: clarifies that 'path' is mandatory for first-time saves and explains the consequence of omitting it (dialog freeze, now an error). This enriches the 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 clearly states the tool saves the current presentation (保存当前演示文稿), which is a specific verb+resource. It distinguishes from siblings by being the only presentation save tool among many WPS 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 provides critical usage context: when the document has never been saved, the 'path' parameter is mandatory; otherwise, saving triggers a 'Save As' dialog that could freeze the process (now detected). It also warns about the WPS sandbox restriction on paths and suggests using ~/Downloads. This gives clear when-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 provided, but the description clearly discloses the dynamic nature of the PAGE field, section linking behavior, and the requirement to call the tool for each section. It does not cover error cases (e.g., invalid section_index) or behavior when a section already has content, which are minor gaps.
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 core purpose, followed by well-structured examples and a critical warning. It is longer than strictly necessary, but every sentence serves a purpose; the structure aids comprehension.
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 7 optional parameters and no output schema, the description covers the primary use case thoroughly, references a relevant sibling tool (wps_word_probe_sections), and explains parameter interactions. It lacks information about error handling and return values, but these are minor omissions for a tool with this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so each parameter is already described in the input schema. The description adds significant meaning by providing example parameter combinations for real use cases, explaining interactions (e.g., restart with link_to_previous:false), and clarifying defaults and intent beyond the schema's isolated 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 the tool adds auto page numbers (PAGE field) to section footers with alignment options. It clearly distinguishes from siblings by providing a specific, non-overlapping function; no other sibling tool handles page numbering.
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 outlines when to use the tool with a detailed thesis numbering workflow (cover, preface, body) and warns about the common pitfall of section linking inheritance. It also recommends using wps_word_probe_sections for section structure, providing clear contextual guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/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 that the TOC is generated by a TOC field, is updateable via right-click or UpdateFields, and includes page numbers and hyperlinks. However, it doesn't state whether this operation is destructive to existing content, whether it requires specific permissions, or what happens if after_text is not found. A 3 is appropriate as it adds meaningful behavior beyond annotations (which are absent) but leaves some gaps.
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 main action and key features, followed by pre-conditions and parameter explanation. At three sentences, every sentence serves a distinct purpose (what, prerequisites, behavior), with no fluff. It is efficiently structured.
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 (3 optional params, no output schema, no nested objects, no annotations), the description covers the essential aspects: what the tool does, how to prepare, where the TOC appears, and how to update it. There is no glaring omission for a tool of this type, and it provides complete guidance for an AI agent to use 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 coverage is 100%, so baseline is 3. The description adds value by explaining that 'after_text' should be a paragraph text (often '目录') and that omitting it places the TOC at document start. While levels and upper_level parameters are self-explanatory from schema, the description clarifies the insertion behavior which is not obvious from schema alone. This raises it to 4.
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 (insert auto-generated TOC with specific features: TOC field, updateable, page numbers, hyperlinks). It distinguishes from hand-written static TOCs and provides the exact use case (replacing manual TOCs). This effectively differentiates it from sibling tools like wps_word_read or wps_word_append_paragraph.
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 preconditions (set heading levels to 'Title 1/2/3' styles first), specifies where to insert (after a specific paragraph like '目录' header, or at document start), and implies when to use (for auto-generated TOC vs. manual ones). It provides clear context on when-not-to-use (no need if headings aren't styled).
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. It discloses the core behavior (checking bridge status) and coverage of three hosts. Although it does not explicitly state side effects or output format, the verb '检查' and tool name imply a non-mutating diagnostic action, offering sufficient transparency for a status check 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 two sentences, front-loaded with the purpose and followed by a clear usage directive. Every sentence contributes value with no 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 zero-parameter diagnostic tool, the description covers purpose, scope (three hosts), and usage context. A minor gap is the absence of return-value expectations, but given the simplicity and the absence of an output schema, the provided context is largely 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?
The tool has zero parameters, so the baseline is 4. The description contains no parameter information, but there are no parameters to document, and the context of 'check connection status' is enough without them.
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 ('检查' – check) and identifies the exact resource: the WPS add-in bridge connection status across three hosts (wps/et/wpp). This clearly distinguishes it from the many sibling tools that perform document/operation tasks.
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: '任何 wps_* 调用失败时先调用它排查' – call this first whenever any wps_* call fails, positioning it as a diagnostic tool for troubleshooting. This provides clear, actionable usage guidance relative 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?
No annotations are provided, so the description carries full burden. It fully discloses critical behavioral traits: the blocking native dialog if the file is already open, the inability of the object model to intercept it, the sandbox restrictions on allowed paths, and the explicit error throwing for unauthorized paths. This is highly transparent.
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 moderately long but every sentence adds critical information. The key purpose is front-loaded, followed by warnings and sandbox limitations. A minor improvement could be splitting into two paragraphs for readability, but overall it is well-structured and informative.
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 1 simple parameter and no output schema. The description covers all behavioral aspects: opening behavior, blocking scenarios, sandbox constraints, and error handling. Given the complexity of the WPS environment, the description is complete and leaves no obvious gaps for the agent.
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 100% (only one parameter 'path' with description '文件绝对路径'). The description does not add further detail about the path parameter beyond what the schema already provides, but since schema coverage is high, baseline 3 is appropriate.
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 '打开本地或云同步的演示文稿' which is a specific verb ('打开' = open) and resource ('演示文稿' = presentation). It clearly distinguishes itself from sibling tools like wps_wpp_close or wps_wpp_get_presentation_info by stating directly what it does.
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 warns against using this tool when the file is already open in WPS, describing the blocking dialog issue. It also provides guidance on sandbox restrictions, advising to use files under ~/Downloads or pre-open with shell if a path fails. This is comprehensive 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?
No annotations are provided, so the description carries the full burden. It discloses that the tool can only call macros that already exist, cannot write new code, and explains the permission reason. This is comprehensive 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?
The description is two sentences, front-loaded with purpose, and includes a concise explanation of limitations. Every sentence adds value 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 simple tool with two parameters and no output schema, the description covers purpose, usage guidelines, and behavioral limitations comprehensively. No critical information 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 100%, so baseline is 3. The description does not add extra semantics beyond what the schema already provides for the two parameters. It mentions the limitation but not parameter details, hence no additional 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 clearly states the tool calls existing macros (VBA Sub/Function) in the current workbook. It specifies the verb 'call' and resource 'existing macros', distinguishing it from all sibling tools which are for other WPS operations.
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 when to use (calling existing macros) and when not to use (cannot write new macro code), providing a clear explanation of the design limitation. This helps the agent avoid incorrect usage.
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 transparently reveals that WPS may return 'success' while the file is never actually created on unauthorized paths, that this failure is invisible at the object model layer, and that the tool does not guarantee path correctness. This is critical operational context that goes far beyond basic parameter documentation.
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. Every sentence carries weight: default path, sandbox warning, failure mode, recommendation, verification note. However, it could be slightly restructured for clarity—the '重要' paragraph runs long and mixes distinct concerns (permissions, silent failure, verification). Minor structural polish would elevate it to 5.
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 input schema (1 optional param) and no output schema, the description fully covers the tool's behavior, failure modes, and best practices. The silent-failure warning is essential for safe agent usage. No gaps remain for the agent to infer or discover by trial and error.
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 100% coverage (1 param described), so the baseline is 3. The description adds value by explaining the default behavior when path is omitted, and by warning about authorization constraints on the path parameter. A small gap: it doesn't confirm whether directory creation is attempted or expected.
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 action verb and resource: '把当前文档导出为 PDF'. It immediately distinguishes itself by specifying the default behavior when no path is given (same directory, same name, .pdf extension). Among siblings like wps_wpp_export_pdf, this is uniquely the Word document PDF export tool.
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 provides explicit guidance on where to export and what pitfalls to avoid. It warns that WPS is a sandbox app, lists authorized directories (~/Downloads, original document directory), explains that writing to unauthorized paths leads to silent failure, and gives a concrete recommendation: '强烈建议导出到 ~/Downloads'. It also instructs the agent to verify file existence after export.
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 excels by detailing a critical behavioral trait: that opening an already-open file causes a native modal that blocks all WPS commands until dismissed, which no annotation could capture. It also transparently explains sandbox restrictions and the error handling (explicit error, not silent failure), providing comprehensive 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is moderately concise (about 3 sentences in Chinese) and front-loads the core purpose. It earns its sentences: each adds distinct value (purpose, blocking warning, sandbox workaround). It could be marginally tighter by combining the sandbox and workaround into one sentence, but the current structure is well-organized and readable for its length.
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 tool (1 required param, no output schema, no enums, no nested objects), the description covers all necessary context: the action, critical caveats (blocking dialog, sandbox restrictions), and alternative paths to unblock users. For a file-opening tool, it is remarkably complete in warning about environmental constraints that could cause failures, leaving no obvious gaps for an agent to make incorrect assumptions.
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 100% coverage with one parameter 'path' described as '文件绝对路径' (absolute file path). The description adds value beyond the schema by explaining the sandbox restrictions that affect which paths are usable, giving crucial context for the parameter's semantics that the schema alone cannot provide. While the parameter is straightforward, the description's path-related usage guidance elevates the score above baseline 3.
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 uses the verb '打开' (open) and specifies the resource as '本地或云同步的 WPS 文字文档' (local or cloud-synced WPS Word documents). It distinguishes itself from siblings like wps_word_new, wps_word_save, and other tools by focusing exclusively on the open action for WPS Word files.
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 provides explicit guidance on when to use this tool and critical prerequisites: it warns against opening a file already open in WPS due to a blocking native dialog, advises pre-checking with wps_status or known context, and explains the sandbox access restrictions with actionable workarounds (use files under ~/Downloads or pre-open via shell/finder). This gives clear when-to-use and when-not-to-use instructions.
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 discloses critical behavioral traits: WPS is sandboxed to ~/Downloads or the original directory, exports to other paths return 'success' without creating a file, and no error is surfaced at the object model level. It also notes the tool does not guarantee path validity. This is exemplary transparency.
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 somewhat long, but every sentence adds value—purpose, sandbox restriction, failure mode, and verification advice. It is front-loaded with the main action and then provides necessary caveats without unnecessary 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?
Given the complexity of sandbox restrictions and silent failures, this description covers the main purpose, critical constraints, failure behavior, and post-action verification. It is fully sufficient for an agent to use the tool safely despite lacking an output schema or annotations.
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 schema only says 'path' is an optional export path, but the description adds crucial semantics: the path must be in ~/Downloads or the document's original directory, otherwise silent failure occurs. This guidance directly enriches understanding of the parameter beyond the schema 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 clearly states the action: '把当前演示文稿导出为 PDF' (export the current presentation to PDF). This is a specific verb+resource+output format, and it distinguishes from sibling wps_word_export_pdf by specifying '演示文稿' (presentation) vs. document.
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 provides explicit guidance: strongly recommends exporting to ~/Downloads ('强烈建议导出到 ~/Downloads') and warns against unauthorized paths that will be silently blocked. It also instructs to verify the file after export, which is critical for correct usage.
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 well. It discloses that unauthorized file paths may be silently intercepted, causing insertion failure or blank images—an important non-obvious behavior. It also clarifies the default slide selection 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?
Two well-structured sentences: the first states the action and default, the second warns about the sandbox restriction with a suggested mitigation. No redundant words, and the critical info 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 tool with 6 parameters and no output schema, the description provides all essential context: the action, the default behavior, the key environmental constraint, and a workaround. The schema covers parameter details, so the description is not missing critical information.
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 100%, so baseline is 3. The description adds value by explaining the sandbox authorization caveat for the path parameter, which is not in the schema. It also reinforces the slide_index default, but does not add detail for top/left/width/height beyond 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?
Description clearly states the action: insert an image into a specified slide, with a default to the current slide if slide_index is omitted. This distinguishes it from sibling tools like wps_word_insert_image by explicitly mentioning slides.
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 guidance: explains the default behavior when slide_index is not passed, and gives a critical prerequisite about file authorization in the WPS sandbox, including a suggestion to place images in ~/Downloads. This tells the agent when to use it and what conditions must be met.
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/Antares422/draftly-wps'
If you have feedback or need assistance with the MCP directory API, please join our Discord server