MiOffice — AI-Powered Workspace Studio

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 describes key traits: it opens MiOffice in the browser, processes files privately, and ensures files never leave the device. This covers operational context and privacy aspects, though it lacks details on error handling or performance limits.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by additional context in the second. Both sentences earn their place by providing essential information without redundancy, making it efficient and well-structured.

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

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

Given the tool's complexity (a file conversion with privacy features), no annotations, and no output schema, the description is mostly complete. It covers the what, how, and privacy aspects, but lacks details on output format (e.g., PDF quality) or error cases, leaving minor gaps.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter information is needed. The description adds value by explaining the conversion process and privacy features, which compensates for the lack of parameters. However, it does not specify input file requirements (e.g., supported Excel versions).

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

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

The description clearly states the specific verb ('Convert') and resource ('Excel (XLSX) to PDF'), distinguishing it from sibling tools like 'mioffice_word_to_pdf' which handles different file types. It precisely defines the tool's function without ambiguity.

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

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

The description provides clear context about when to use this tool (for converting Excel files to PDF) and mentions the private processing aspect. However, it does not explicitly state when not to use it or name alternatives among siblings, such as other conversion tools in the list.

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

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

With no annotations provided, the description carries the full burden and adds valuable behavioral context: it discloses that the tool opens MiOffice in the browser for processing and ensures privacy by keeping files on-device. However, it doesn't mention potential limitations like file size constraints, browser requirements, or processing time.

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

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

The description is highly concise and front-loaded: the first sentence states the core purpose, and the second adds crucial behavioral context. Every sentence earns its place with no wasted words, making it easy to scan and understand.

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

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

Given the tool's complexity (a file conversion with privacy features), no annotations, no output schema, and 0 parameters, the description is mostly complete: it explains what the tool does, how it works (browser-based), and key behavioral traits (privacy). However, it lacks details on output format specifics or error handling.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately adds no parameter details, maintaining a baseline score of 4 as it doesn't need to compensate for any gaps.

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

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

The description clearly states the specific action ('Convert HEIC to JPG') and resource (HEIC files), distinguishing it from sibling tools like 'mioffice_image_convert' by specifying the exact format conversion. It goes beyond the tool name by explaining the conversion process.

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

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

The description provides clear context for when to use this tool ('Convert HEIC to JPG') and implies usage for privacy-sensitive processing ('files never leave your device'), but it doesn't explicitly state when not to use it or name alternatives among the many sibling tools (e.g., 'mioffice_image_convert' might be a broader alternative).

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It usefully adds context about the tool opening MiOffice in the browser and processing files privately on-device, which are important behavioral traits not inferable from the name alone. However, it doesn't mention potential limitations like supported image formats, compression levels, or what happens after processing (e.g., download location), leaving gaps in transparency.

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

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

The description is perfectly concise with two sentences that each earn their place: the first states the core function, and the second adds crucial behavioral context about privacy and browser interaction. It's front-loaded with the main purpose and wastes no words, making it highly efficient and well-structured.

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

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

Given the tool's moderate complexity (browser-based image compression with privacy focus), no annotations, no output schema, and 0 parameters, the description is adequate but has clear gaps. It covers the what and how (compression via browser with on-device processing) but doesn't address output details (e.g., what the compressed file looks like or where it's saved) or potential constraints (e.g., file size limits), making it minimally complete.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the lack of inputs. The description doesn't need to explain parameters, and it appropriately doesn't mention any. The baseline for 0 parameters is 4, as the description correctly avoids redundant parameter information while focusing on tool behavior.

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

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

The description clearly states the verb 'compress' and resource 'image', making the purpose specific and understandable. It distinguishes from siblings like 'image_convert' or 'image_resize' by focusing on compression rather than format conversion or size adjustment. However, it doesn't explicitly contrast with 'pdf_compress' for different file types, leaving some sibling differentiation incomplete.

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

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

The description implies usage when privacy is important ('files never leave your device') and when browser-based processing is acceptable, but doesn't explicitly state when to use this tool versus alternatives like 'image_convert' for format changes or 'upscale_image' for quality enhancement. No clear exclusions or named alternatives are provided, leaving usage context somewhat implied rather than explicit.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the tool opens MiOffice in a browser, processes files privately on-device, and converts image formats. This covers the operation mode and privacy aspects, though it doesn't mention potential limitations like supported formats or processing time.

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

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

The description is extremely concise and well-structured in a single sentence. It front-loads the core purpose ('Convert image format') and efficiently adds important context about privacy and browser-based processing. Every word earns its place with no wasted information.

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

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

Given the tool's complexity (image conversion with privacy features), no annotations, and no output schema, the description provides adequate but incomplete context. It covers the what and how (conversion, browser-based, on-device processing) but lacks details about supported formats, conversion quality, or error handling. For a tool with behavioral complexity, more completeness would be helpful.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's behavior and context. This meets the baseline expectation for tools without parameters.

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

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

The description clearly states the tool's purpose: converting image formats. It specifies the action ('convert image format') and mentions the resource (images), but doesn't differentiate from siblings like 'mioffice_heic_to_jpg' which is more specific. The description adds privacy context but doesn't make the purpose distinct from similar tools.

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

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

The description implies usage context by mentioning 'files never leave your device' and browser-based processing, suggesting privacy-focused scenarios. However, it doesn't explicitly state when to use this tool versus alternatives like 'mioffice_heic_to_jpg' for specific format conversions or 'mioffice_image_compress' for size reduction. Usage is implied but not clearly defined relative to siblings.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds value by explaining that the tool opens a browser interface ('Opens MiOffice in your browser'), processes files locally ('files never leave your device'), and handles privacy ('privately'). This covers key operational traits beyond basic functionality.

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

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

The description is highly concise and front-loaded, with two sentences that efficiently convey the core action, tool behavior, and privacy aspect. Every word serves a purpose, making it easy to parse without wasted text.

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

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

Given the tool's moderate complexity (image processing with local execution) and no annotations or output schema, the description is reasonably complete. It covers what the tool does, how it operates, and privacy implications. However, it could mention output specifics (e.g., resized image format or dimensions) for full completeness.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, earning a baseline score of 4 for not adding unnecessary information while maintaining clarity.

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

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

The description clearly states the tool's purpose with a specific verb ('Resize') and resource ('an image'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'mioffice_image_compress' or 'mioffice_image_convert', which prevents a perfect score.

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

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

The description implies usage context by mentioning 'Opens MiOffice in your browser to process the file privately', suggesting this is for local, private image resizing. However, it lacks explicit guidance on when to use this vs. alternatives like 'mioffice_upscale_image' or 'mioffice_image_compress', leaving some ambiguity.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it opens a browser-based tool (MiOffice), processes files privately (files never leave the device), and implies a user-interactive workflow. However, it lacks details on supported image formats, rotation angles, or error handling, leaving some behavioral aspects unclear.

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

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

The description is front-loaded with the core purpose ('Rotate an image') and efficiently adds context in a single, clear sentence. Every word earns its place, with no redundancy or fluff, making it highly concise and well-structured for quick understanding.

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

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

Given the tool's complexity (browser-based, interactive) and lack of annotations and output schema, the description is moderately complete. It covers privacy and workflow but misses details like supported formats, rotation options, or what happens after processing. For a tool with no structured data, it should provide more behavioral context to be fully adequate.

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

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

The input schema has 0 parameters with 100% coverage, so no parameters need documentation. The description adds value by explaining the tool's operational context (browser-based, private processing), which isn't captured in the schema. This compensates well for the lack of parameters, though it doesn't need to detail inputs.

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

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

The description clearly states the action ('rotate') and resource ('an image'), making the purpose immediately understandable. It distinguishes from siblings by specifying rotation rather than compression, conversion, or other image operations. However, it doesn't explicitly contrast with similar tools like 'mioffice_image_resize' beyond the verb difference.

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

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

The description implies usage context by mentioning that it 'Opens MiOffice in your browser' and processes files privately, suggesting this is for local image rotation with privacy. However, it provides no explicit guidance on when to use this vs. alternatives like 'mioffice_image_convert' (which might also handle rotation) or other image tools, nor does it mention prerequisites or exclusions.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. While it states this is a listing/filtering operation (implied read-only), it doesn't disclose important behavioral aspects like pagination, rate limits, authentication requirements, error conditions, or what the output format looks like. For a tool that presumably returns a potentially large list (125+ items), this is a significant gap.

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

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

The description is extremely concise (two short sentences) with zero wasted words. It's front-loaded with the core purpose ('List all 125+ MiOffice applications') followed by the key usage detail. Every word earns its place in this efficient description.

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

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

Given this is a listing tool with no annotations and no output schema, the description is insufficiently complete. It doesn't explain what information is returned about each application, how results are structured, whether there's pagination for 125+ items, or any error handling. For a discovery tool that should help users understand available options, more context about the return format would be valuable.

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

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

Schema description coverage is 100%, so the schema already fully documents the single parameter with its enum values and default. The description mentions filtering by category but adds no additional semantic context beyond what's in the schema. This meets the baseline expectation when schema coverage is complete.

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

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

The description clearly states the specific action ('List all 125+ MiOffice applications') and resource ('MiOffice applications'), distinguishing it from sibling tools which are all specific conversion/processing tools rather than listing tools. It provides concrete scope information (125+ applications) that isn't obvious from the name alone.

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

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

The description provides clear context about when to use this tool ('Filter by category'), but doesn't explicitly state when NOT to use it or name specific alternatives among the sibling tools. The agent can infer this is for discovery/listing rather than processing, but no explicit exclusion guidance is provided.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves URLs but does not explain how the search works (e.g., exact match, partial match), error handling, or performance aspects like rate limits. This is a significant gap for a tool with no annotation coverage.

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

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

The description is concise and front-loaded, consisting of two clear sentences: 'Get the URL for any MiOffice tool. Search by name or tool key.' Every word contributes to understanding the tool's purpose without unnecessary elaboration, making it efficient and easy to parse.

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

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

Given the complexity of a search tool with no annotations, no output schema, and 100% schema coverage for one parameter, the description is incomplete. It lacks details on search behavior, result format, error cases, and how it differs from siblings like 'mioffice_list_tools.' This makes it inadequate for full agent understanding.

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

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

Schema description coverage is 100%, with the parameter 'toolName' documented as 'Tool key or search term (e.g., "merge pdf", "remove background").' The description adds minimal value by mentioning 'Search by name or tool key,' which aligns with the schema but does not provide additional syntax or format details. Baseline 3 is appropriate as the schema handles most of the parameter documentation.

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

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

The description clearly states the tool's purpose: 'Get the URL for any MiOffice tool' with the action 'Search by name or tool key.' It specifies the verb ('Get'), resource ('URL for any MiOffice tool'), and method ('Search'), but does not explicitly differentiate it from sibling tools like 'mioffice_list_tools' which might list tools rather than retrieve URLs.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions searching by name or tool key but does not specify scenarios, prerequisites, or exclusions, such as when to use 'mioffice_list_tools' for listing tools instead. This lack of context leaves usage unclear.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: it opens a browser interface, processes files privately without data leaving the device, and compresses PDFs to reduce size. This covers operational context and privacy aspects, though it could add details like performance expectations or error handling.

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

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

The description is highly concise and front-loaded, with two sentences that efficiently convey the tool's purpose, method, and privacy benefit. Every sentence earns its place by adding critical information without redundancy or unnecessary detail.

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

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

Given the tool's low complexity (0 parameters, no output schema, no annotations), the description is largely complete. It explains what the tool does, how it operates, and privacy assurances. However, it could be more complete by mentioning potential limitations (e.g., file size constraints) or the compression outcome (e.g., approximate size reduction), which would help an agent use it effectively.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description adds value by explaining the process (opens browser, private processing) and outcome (reduces PDF size), which compensates for the minimal parameter info. A baseline of 4 is appropriate as it provides meaningful context beyond the empty schema.

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

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

The description clearly states the tool's purpose with a specific verb ('Compress') and resource ('a PDF'), and distinguishes it from siblings by focusing on PDF compression rather than conversion, editing, or other operations. However, it doesn't explicitly differentiate from similar tools like 'mioffice_pdf_merge' or 'mioffice_pdf_split' beyond the compression focus.

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

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

The description implies usage context by mentioning that it 'Opens MiOffice in your browser to process the file privately,' suggesting it's for local file processing with privacy. However, it lacks explicit guidance on when to use this tool versus alternatives like 'mioffice_pdf_editor' for editing or 'mioffice_pdf_merge' for combining files, and doesn't specify prerequisites or exclusions.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies opening an editor for interactive use but doesn't specify whether this launches a UI, requires user authentication, has rate limits, or what happens upon invocation (e.g., opens a file or starts a session). For a tool with zero annotation coverage, 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.

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

The description is extremely concise and front-loaded: a single sentence that directly states the tool's purpose with examples. Every word earns its place, and there's no wasted text or unnecessary elaboration.

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

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

Given the tool's complexity (opening an editor likely involves interactive or session-based behavior), lack of annotations, and no output schema, the description is insufficient. It doesn't explain what 'Open' entails (e.g., returns a session ID, launches an application), what happens after invocation, or any error conditions. This leaves significant gaps for an agent.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't need to add parameter details, and it appropriately avoids discussing parameters. A baseline of 4 is assigned as it correctly handles the no-parameter case without redundancy.

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

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

The description clearly states the tool's purpose: 'Open the MiOffice PDF Editor — annotate, highlight, fill forms, sign, and more.' It specifies the verb 'Open' and resource 'MiOffice PDF Editor', with examples of actions possible. However, it doesn't explicitly differentiate from siblings like 'mioffice_open_tool' or 'mioffice_pdf_merge', which slightly reduces clarity.

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

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

The description provides no guidance on when to use this tool versus alternatives. It mentions general PDF editing capabilities but doesn't specify prerequisites, when-not-to-use scenarios, or compare to siblings like 'mioffice_pdf_compress' or 'mioffice_pdf_split'. This leaves the agent with minimal usage context.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key traits: the tool opens a browser interface, processes files privately locally, and ensures 'files never leave your device'. This covers privacy, user interaction, and local processing behavior, though it lacks details on error handling or output specifics.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by important behavioral details. Both sentences are essential—one states the action, the other explains the privacy and interface aspects—with zero wasted words, making it highly efficient.

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

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

Given the tool's moderate complexity (browser-based, local processing) and no annotations or output schema, the description is reasonably complete. It covers purpose, privacy, and interface, but lacks details on output format (e.g., merged PDF location/name) or any limitations, leaving minor gaps for full agent understanding.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the process context ('Opens MiOffice in your browser'), which goes beyond the empty schema. Baseline is 4 for zero parameters, as it provides useful operational insight.

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

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

The description clearly states the specific action ('Merge multiple PDFs into one') and resource ('PDFs'), distinguishing it from sibling tools like mioffice_pdf_split or mioffice_pdf_compress. It precisely communicates the tool's function without ambiguity.

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

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

The description provides clear context by explaining that it 'Opens MiOffice in your browser to process the file privately', which implicitly guides usage for local, private PDF merging. However, it does not explicitly state when to use this tool versus alternatives like mioffice_pdf_editor or other PDF tools, missing explicit sibling differentiation.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively adds context beyond basic functionality by explaining the processing method ('Opens MiOffice in your browser') and privacy aspect ('files never leave your device'), which are crucial for understanding how the tool operates. It doesn't cover details like output format or error handling, but provides meaningful behavioral insights.

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

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

The description is perfectly concise and front-loaded, with two sentences that each earn their place: the first states the core purpose, and the second adds essential behavioral context about privacy and processing. There is zero wasted text, making it highly efficient for an AI agent.

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

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

Given the tool's moderate complexity (PDF processing with privacy considerations) and no annotations or output schema, the description is adequate but has gaps. It covers the what and how (extraction via browser with privacy), but lacks details on output (e.g., format of extracted pages), error cases, or limitations. This makes it minimally viable but not fully complete for informed use.

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

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

The tool has 0 parameters with 100% schema description coverage, so the schema fully documents the lack of inputs. The description doesn't add parameter-specific information, which is unnecessary here. A baseline of 4 is appropriate as the description doesn't need to compensate for any parameter gaps, and it aligns with the schema's indication of no required inputs.

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

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

The description clearly states the tool's purpose with a specific verb ('Extract pages from a PDF') and resource ('PDF'), distinguishing it from siblings like 'mioffice_pdf_merge' or 'mioffice_pdf_compress'. However, it doesn't explicitly differentiate from 'mioffice_pdf_editor' which might also handle page extraction, preventing a perfect score.

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

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

The description implies usage context by mentioning 'Opens MiOffice in your browser to process the file privately', suggesting this tool is for local, private PDF page extraction. However, it lacks explicit guidance on when to use this versus alternatives like 'mioffice_pdf_editor' or other PDF tools, and doesn't specify prerequisites or exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it uses AI for background removal, opens a browser interface (MiOffice), processes files privately, and ensures files never leave the device. This covers operational context, privacy aspects, and user interaction, though it could add more on error handling or output specifics.

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

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

The description is highly concise and well-structured in two sentences: the first states the core purpose, and the second explains the operational method and privacy assurance. Every sentence earns its place by adding critical information without waste, making it front-loaded and efficient.

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

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

Given the tool's complexity (AI-based image processing with browser interaction), no annotations, no output schema, and 0 parameters, the description is fairly complete. It covers purpose, method, privacy, and device security. However, it lacks details on output format (e.g., what happens after processing) or error cases, which could be useful for an agent.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by explaining the tool's operation (opens browser, private processing) beyond the schema, which is appropriate. Baseline is 4 for 0 parameters, as it compensates with operational context without redundant param info.

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

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

The description clearly states the tool's purpose: 'Remove image background with AI' specifies the action (remove background) and resource (image) with the method (AI). It distinguishes from siblings like 'mioffice_image_compress' or 'mioffice_image_resize' by focusing on background removal rather than compression or resizing. However, it doesn't explicitly differentiate from all siblings (e.g., 'mioffice_image_convert' could potentially include background removal), keeping it from a perfect score.

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

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

The description implies usage for image background removal, but provides no explicit guidance on when to use this tool versus alternatives like 'mioffice_image_convert' or other image-processing siblings. It mentions that it 'Opens MiOffice in your browser to process the file privately,' which gives some context about the tool's operation, but lacks clear when/when-not instructions or named alternatives for similar tasks.

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

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

With no annotations provided, the description carries the full burden. It discloses key behavioral traits: it opens a browser (implying user interaction), processes files privately (no data leaves the device), and uses AI. However, it misses details like performance expectations, error handling, or output format, which are important for a tool with potential complexity.

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

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

The description is highly concise and front-loaded: the first sentence states the core function, and the second adds critical context about privacy and process. Every sentence earns its place by providing essential information without waste, making it easy for an agent to grasp quickly.

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

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

Given no annotations, 0 parameters, and no output schema, the description is moderately complete. It covers the tool's action, privacy aspect, and interaction method, but lacks details on what happens after upscaling (e.g., file output, success indicators) or potential limitations, leaving gaps for an agent to infer.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description doesn't add param info, which is appropriate. Baseline is 4 for 0 params, as it avoids redundancy and focuses on tool behavior instead.

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

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

The description clearly states the tool's purpose: 'Upscale image with AI' specifies the verb (upscale) and resource (image) with the method (AI). It distinguishes from siblings like 'mioffice_image_resize' by emphasizing AI enhancement rather than basic resizing. However, it doesn't explicitly contrast with all siblings (e.g., 'mioffice_image_convert'), keeping it from a perfect score.

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

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

The description implies usage by mentioning that it 'Opens MiOffice in your browser to process the file privately,' suggesting it's for local, private image upscaling. However, it lacks explicit guidance on when to use this vs. alternatives like 'mioffice_image_resize' or 'mioffice_image_convert,' and doesn't state prerequisites or exclusions, leaving some ambiguity.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds valuable context beyond basic functionality by explaining that it 'Opens MiOffice in your browser to process the file privately — files never leave your device,' which informs about privacy, local processing, and the browser-based interface. This addresses key behavioral traits like security and user interaction.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by additional behavioral context. Both sentences earn their place by adding value—the first defines the action, and the second explains privacy and processing details. There is no wasted text.

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

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

Given the tool's simple conversion function with 0 parameters and no output schema, the description is largely complete. It covers purpose, privacy, and processing method. However, it doesn't mention output format details (e.g., PDF quality or settings), which could be relevant for a conversion tool, leaving a minor gap.

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

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

The input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and behavior. This meets the baseline for tools with no parameters.

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

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

The description clearly states the specific action ('Convert Word (DOCX) to PDF') and resource ('Word (DOCX)'), distinguishing it from siblings like 'mioffice_excel_to_pdf' which handles Excel files. It provides a precise verb+resource combination that leaves no ambiguity about its function.

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

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

The description implies usage context by specifying 'Word (DOCX)' files, which helps differentiate it from other conversion tools in the sibling list. However, it doesn't explicitly state when not to use it or name alternatives, so it lacks explicit exclusion guidance.

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