Aspose.Cells Cloud MCP Server
OfficialServer Quality Checklist
Latest release: v26.4.0
- Disambiguation2/5
Multiple tools have overlapping purposes, such as convert_spreadsheet and convert_excel which are essentially identical, and get_structure_with_file_token and get_spreadsheet_structure share the same misleading description. The large set of text manipulation tools also creates confusion, e.g., remove_symbols vs remove_punctuation_marks.
Naming Consistency3/5Most tools follow a clear verb_noun pattern (e.g., upload_file, remove_extra_line_breaks), but there are notable exceptions like word_case and the inconsistent naming of conversion tools (convert_spreadsheet vs convert_excel_to_pdf vs save_spreadsheet_as_with_scaling_mode).
Tool Count2/5With 37 tools, the server feels heavily over-scoped. The numerous granular text manipulation commands (e.g., remove_first_n_characters, remove_last_n_characters, add_text_at_head, add_text_at_tail) could be consolidated into parameterized functions, and there are multiple near-duplicate conversion tools.
Completeness2/5The server is heavily focused on file conversions and text cleaning but lacks fundamental spreadsheet operations such as creating/editing cells, managing worksheets, handling formulas, or applying formatting. This makes the tool surface incomplete for a general-purpose Excel manipulation server.
Average 3.4/5 across 37 of 37 tools scored. Lowest: 1/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
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.
If you are the author, simply .
If the server belongs to an organization, first add
glama.jsonto the root of your repository:{ "$schema": "https://glama.ai/mcp/schemas/server.json", "maintainers": [ "your-github-username" ] }Then . Browse examples.
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, so description must disclose behavior. It describes scaling modes and output layout, but the schema has no such parameter. The tool likely returns a structure, not modifies printing. This is a significant misrepresentation of what the tool does.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness1/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is verbose and unfocused, spending sentences on printing and scaling that are irrelevant to the actual tool. It is not front-loaded with the true purpose and contains unnecessary details, making it both inefficient and misleading.
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?
For a tool with a simple schema and likely straightforward purpose, the description should clarify what 'structure' means and how file_token is used. It does neither; instead, it talks about page layouts and scaling, leaving a complete gap in understanding the tool's actual function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has one parameter (file_token) with no description, and the description omits any mention of it. Schema coverage is 0%, and the description adds no meaning to the parameter, leaving agents without any clues about what 'file_token' refers to or how to obtain it.
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 claims the tool handles printing and scaling strategies, but the tool name 'get_structure_with_file_token' and its schema (only file_token) suggest it retrieves file structure. No mention of getting structure; the described behavior is misleading and does not align with the name or input parameters.
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 on when to use this tool versus alternatives like get_spreadsheet_structure or save_spreadsheet_as_with_scaling_mode. The description implies usage for printing/scaling, which is likely incorrect, making it actively misleading.
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?
No annotations are provided, so the description carries the full burden. The description misrepresents the tool's behavior by describing print scaling operations that do not match the tool's name or schema. It does not disclose what the tool actually returns, nor does it mention any constraints or side effects. This is deeply misleading.
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 verbose paragraph that is entirely irrelevant to the tool's actual function. It is not front-loaded with a clear purpose, and every sentence adds confusion rather than clarity. It could be replaced with a single accurate sentence.
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?
Even though an output schema exists, the description fails to provide the most basic context about what the tool does. It describes printing and scaling, which is unrelated to retrieving spreadsheet structure. The tool is completely misrepresented, leaving the agent with no accurate information about its function.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter (spreadsheet_b64string) with no description. The description adds no value for this parameter and instead references 'scaling mode' parameters that do not exist in the schema. This actively confuses the agent about what inputs are valid.
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 focuses on print scaling when converting spreadsheets, but the tool name is 'get_spreadsheet_structure', which implies retrieving structure. This is a complete mismatch. The description does not state the actual purpose of getting spreadsheet structure, and it fails to distinguish from siblings like get_structure_with_file_token.
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 given on when to use this tool versus alternatives. The description talks about printing and scaling, which overlaps with sibling tools like save_spreadsheet_as_with_scaling_mode. It does not mention that this tool is for reading/retrieving structure, nor does it provide context 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?
With no annotations, the description carries the full burden, but only discloses that the input must be a Base64 string. It does not mention whether the operation is read-only, what the output looks like, error behavior, or any side effects. This is minimal behavioral disclosure for a tool with no annotation safety hints.
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 gets to the point without unnecessary words. It is concise and structured with a clear verb and object, though it sacrifices detail for brevity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (2 params), the description is still incomplete because it lacks output format details, error handling, and differentiation from many similar sibling tools. There is no output schema or annotations to compensate, leaving key decision-making information missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has no descriptions (0% coverage), so the description is the only source of parameter meaning. It identifies both parameters (spreadsheet_b64string and format) and lists example formats, but does not specify the exact allowed values, case sensitivity, or encoding requirements. The added value is limited.
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 converts spreadsheet content (as Base64) to specified formats like PDF, CSV, HTML, or XPS. It names a specific resource and action, but does not distinguish itself from sibling tools that also convert spreadsheets (e.g., convert_excel_to_pdf, convert_excel_to_csv), so it lacks 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 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 the many sibling conversion tools. The description does not mention alternatives or exclusion criteria, leaving the agent to infer the appropriate context without support.
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 must disclose side effects. It states preservation of alphanumerics and whitespace and return value on success, but omits failure behavior, whether the original file is modified in place, and default range/worksheet behavior when optional parameters are omitted.
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, making it easy to parse, but includes unnecessary filler 'using Aspose.Cells Cloud API' that doesn't help the agent. It is concise overall, though slightly less structured than ideal.
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 provides a general understanding of the tool's function, but given no annotations, an output schema that is not shown, and many sibling text-removal tools, it lacks critical details like default range handling, error outputs, and precise operation scope. It is minimally viable but has clear gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should fully explain parameters. It only vaguely mentions 'range' and 'worksheet' without mapping to the actual _range and worksheet parameters, and does not introduce file_token at all. The format for _range (e.g., 'A1:B2') and default behaviors are missing.
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 action (removes symbol and special characters) and resource (cells in a worksheet range), with specific examples of what gets removed. However, it does not explicitly differentiate from overlapping sibling tools like remove_punctuation_marks.
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 when-to-use or when-not-to-use guidance is provided. The description does not mention alternative tools or advise when this tool is preferred over remove_punctuation_marks or remove_custom_characters.
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 of behavioral disclosure. It states that it saves as a new file, implying a write operation, but does not disclose whether the original file is modified, what authentication is required, what happens on invalid target formats, or what the response contains. The limited statement is insufficient for a conversion tool that creates new files in cloud storage.
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 that front-loads the primary action ('Convert a spreadsheet') and the outcome ('save it as a new file'). It avoids waste and presents the core behavior efficiently. However, it could have used a bit more structure or additional clauses to include usage guidance without becoming verbose, so it is not a 5.
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 many sibling tools (e.g., convert_excel_to_pdf, save_spreadsheet_as_with_scaling_mode) and the absence of annotations, output schema, and param descriptions, the description is too sparse. It does not clarify the return value, how to obtain file_token, which formats are supported, or when to prefer specialized variants. This makes the tool ambiguous in the broader context of the API.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and no enums, so the description must compensate. It only mentions an example format conversion but does not explain that file_token is the identifier of an existing file in Aspose Cloud Storage, nor does it specify allowed values for target_format or how the file_token is obtained. The parameter names are self-descriptive but lack critical details, leaving the agent to guess or rely on external knowledge.
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 converts a spreadsheet in Aspose Cloud Storage to a different format and saves it as a new file. The verb 'Convert' and resource 'spreadsheet' are specific, and the example (XLSX to PDF) adds clarity. However, it does not explicitly distinguish itself from sibling tools like convert_spreadsheet or the save_spreadsheet_as_with_* variants, so it falls short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 does not mention that this is the base version and that save_spreadsheet_as_with_scaling_mode or save_spreadsheet_as_with_save_options_json_data should be used for those specific options, nor does it reference convert_spreadsheet or the format-list tools. There is no when-not to use, leaving the agent without contextual decision-making help.
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 full behavioral burden. It only notes the return value on success, but doesn't disclose failure behavior, whether the original file is modified, permissions required, or how optional parameters (_range, worksheet) affect the operation. This is a significant 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 concise and front-loaded, with only two sentences and no fluff. However, brevity sacrifices critical details, making it efficient but under-specified.
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 4 parameters and no annotations, the description is incomplete. It lacks parameter context, preconditions, default behaviors, and edge-case handling. The presence of an output schema partially covers return values, but overall the description is inadequate for safe and correct invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description provides no parameter meanings. It hints at 'first N' mapping to 'number' and 'specified range' to '_range', but fails to explain file_token, worksheet, or the expected format for _range. The description adds essentially no value over the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: removing the first N characters from each text cell in a specified range. This is specific and distinguishes it from related tools like remove_last_n_characters and trim_text variants.
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 versus similar alternatives (e.g., remove_before_text for variable-length removal). It doesn't mention prerequisites like obtaining a file_token from upload_file. The description only states what it does, not when it should be chosen.
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. It discloses the core save action and mentions custom options, but gives no details on file_token requirements, supported target formats, potential side effects, or return behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the primary action, and includes examples that add substance without excessive verbosity. It could be slightly tighter but remains 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?
For a tool with three required parameters, no schema descriptions, and no output schema, this description is incomplete. It fails to explain the role of file_token and target_format, and does not provide enough context for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only explains save_options_json_data with examples, leaving file_token and target_format completely undefined. It does not compensate for the missing parameter documentation across all three required fields.
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 saves spreadsheet data in a specified format with custom save options, which is a specific verb+resource. It distinguishes itself by mentioning the JSON object for options, though it does not explicitly name sibling alternatives.
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 precise control of save output, but it does not state when to use it over 'save_spreadsheet_as' or 'save_spreadsheet_as_with_scaling_mode', nor does it provide exclusions or prerequisites.
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 must disclose behavioral details. It mentions that content must be Base64-encoded, which is useful, but it omits critical behaviors such as whether existing files are overwritten, authentication requirements, return values, or how the path is determined. The path discrepancy further reduces 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 a single, front-loaded sentence with no filler. It immediately states the action and the encoding requirement, achieving maximum 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?
Despite the simple one-parameter schema, the description is incomplete. It fails to address how the path is specified, what happens on successful upload, and how this tool fits into the larger workflow (e.g., as a prerequisite for conversion tools). The missing output schema and annotations make this description insufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has only one parameter with no description, so the description carries the burden. It clarifies that file_content_b64string holds Base64 content, but it introduces a 'specified path' without a corresponding parameter or explanation, confusing the semantics. The description does not fully compensate for the 0% 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 clearly states the action (upload) and resource (file content to Aspose Cloud Storage), making the core purpose understandable. However, it references a 'specified path' that does not appear in the input schema, introducing slight ambiguity about how the path is 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 the tool is used for uploading file content to cloud storage, but it does not explicitly state when to prefer this tool over alternatives like download_file or conversion tools, nor does it provide any exclusions or prerequisites.
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 the core behavior and return value, but omits edge cases such as behavior when the delimiter is not found, whether the operation modifies the file in place, or any required permissions. The case_sensitive parameter default is also not disclosed.
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 primary action and resource. Every clause adds meaning, and there is no redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no annotations, and no schema descriptions, the description is insufficient for correct invocation. It captures the high-level purpose but lacks critical parameter semantics, usage context, and behavioral nuances needed by an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, and the description only clarifies that 'text' is the delimiter. It does not explain the meaning or expected format of _range, worksheet, case_sensitive, or file_token, leaving the agent to guess their roles.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the tool's action: removing all characters after a specified delimiter text within each cell. It also specifies the resource (worksheet range) and distinguishes it from sibling tools like remove_before_text and trim_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 explicit guidance on when to use this tool versus alternatives. There is no mention of excluded cases, alternatives, or prerequisites, so the agent must infer usage solely from the tool name and generic description.
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 does not explain side effects on the file (e.g., whether it modifies the original file), permission requirements, or error behavior. The return value is mentioned but not error cases or potential irreversibility.
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 brief, consisting of two sentences that focus on the core action and result. It is front-loaded, avoids redundancy, and every sentence provides value.
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 lack of annotations and parameter descriptions, the description is insufficient. It omits critical context such as how to specify the range, whether the operation modifies the original file, and when to use this tool over sibling trimming tools. The output schema may cover return values, but operational guidance is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain parameters beyond implying trim_text and _range. The format of _range, the meaning of worksheet, and the purpose of file_token are left to the schema, which lacks descriptions. Parameter names are somewhat self-explanatory, but the description adds no semantic detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (removes), the target (text values), the scope (specified range of a worksheet in an Excel file), and the return value (True). It effectively distinguishes itself from sibling tools like trim_text_from_leading and trim_text_from_trailing by covering both leading and trailing characters.
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 trim_text_from_leading or trim_text_from_trailing. The description does not mention any prerequisites, exclusions, or comparative scenarios, leaving the agent without direction on choosing 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?
With no annotations, the description carries the full burden, but it only states the operation and return value (True on success). It does not disclose whether the original file is modified, how missing delimiter text is handled, authentication needs, or other 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?
A single sentence front-loads the purpose and includes only essential information. No filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters and no annotations, the description is too thin. It lacks details on range defaults, target-not-found behavior, file scope, and side effects. The presence of an output schema reduces return-format burden, but the behavioral gaps remain significant.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning by mapping 'text' to the text to insert, 'select_text' to the target delimiter/selector, and 'worksheet range' to _range/worksheet. However, file_token is not explained, and optional/default semantics of _range and worksheet are absent, so the compensation for 0% schema coverage is incomplete.
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 ('Adds'), names the resource ('text cells in a worksheet range'), and specifies placement ('immediately after a target delimiter/selector text'). This clearly distinguishes it from sibling tools like add_text_before_text or add_text_at_tail.
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, no conditions, and no exclusions. It implies usage context but never states 'use this when...' or mentions when a sibling tool 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 carries the full burden. It discloses the return value (True on success) and the per-cell application, but does not mention side effects, permissions, reversibility, or whether the operation modifies the file in-place. This is a 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences clearly state the operation and return value, with no filler or repetition. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity, absence of annotations, and 0% schema coverage, the description is incomplete. It does not cover parameter semantics, operational context, or edge cases. The existence of an output schema for the boolean return helps, but the description still leaves significant gaps for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It explains 'text' and 'select_text' but leaves '_range', 'worksheet', and 'file_token' undefined. The description uses vague 'worksheet range' without mapping to the actual parameters, which is insufficient for a 5-parameter tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool adds specified text immediately before a target delimiter/selector text within worksheet cells, using a specific API. This specific verb+resource+scope distinguishes it from siblings like add_text_after_text, add_text_at_head, and remove_before_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 inserting text before a delimiter but does not explicitly state when to use this over alternatives or provide exclusions. It gives context by mentioning the target selector and worksheet range, but lacks explicit guidance on 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?
With no annotations, the description carries the transparency burden. It does disclose that the input must be a Base64 string and lists possible output formats, which is useful. However, it does not mention how the output is returned (e.g., file token, direct download), side effects, or any limitations, leaving significant behavioral 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 a single, front-loaded sentence that conveys the core function and key input requirement without unnecessary words. Every phrase contributes value, making it appropriately 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?
Given there is no output schema and no annotations, the description is incomplete. It omits what the tool returns (e.g., a file token or binary data), lacks details on exact format values, and does not clarify when to use this generic converter over the many specific siblings. This is a significant gap for a tool with only two parameters and no schema descriptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the spreadsheet parameter as 'provided as a Base64 string' and gives example values for 'format' (PDF, CSV, HTML, XPS), adding substantial meaning beyond the bare schema. It does not specify exact format string conventions or all possible values, but it is helpful.
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 converts Excel content (provided as Base64) to a specified format, with a specific verb and resource. However, it does not explicitly distinguish itself from sibling tools like convert_spreadsheet or convert_excel_to_pdf, though the Base64 input hints at a specific use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage 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 convert_excel_to_pdf or convert_excel_to_csv. The description lacks any mention of preferred scenarios or exclusions, leaving the agent to guess.
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 fully disclose behavior. It mentions 'Returns True if the operation succeeds' and 'within each text cell', but does not explain side effects, reversibility, what happens when the delimiter is absent, or how case sensitivity and range selection behave. This leaves significant behavioral 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 a single, front-loaded sentence with no filler. It states the core operation, the scope, the API, and the return value efficiently, making every word purposeful.
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 annotations, and an output schema, the description is too sparse to be complete. It does not cover parameter semantics, default behavior, or edge cases, leaving an agent to guess at critical details like which parameters define the range and how case_sensitive affects the operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only clarifies that 'text' is the delimiter text. It does not explain file_token, _range, worksheet, or case_sensitive, all of which are essential for proper invocation. The description adds minimal meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the action: removing all characters before a delimiter text within text cells in a worksheet range, and the 'to the left of' clarification disambiguates from remove_after_text. It identifies the resource and operation precisely, distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the description: use this tool when you need to strip characters preceding a delimiter in worksheet text cells. However, it does not explicitly mention alternatives or exclusion criteria, such as when to use remove_after_text or trim_text, so guidance is only implicit.
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 exact character set (ASCII 0-31 except tab, newline, CR), the scope (specified range), and returns True if successful. This provides meaningful behavioral detail beyond the schema, though it omits potential side effects or error conditions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured: two sentences that front-load the core action, include essential character details, and state the return value. No unnecessary information or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the output schema exists and the behavior is described, the missing parameter semantics and the ambiguous optionality of _range and worksheet (default null but description says 'specified range') make the tool incomplete for reliable invocation. The agent lacks guidance on how to properly specify the range and worksheet.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters. It vaguely references 'specified range' and 'worksheet' without mapping them to _range or worksheet, and does not mention file_token or their formats/types. The agent cannot infer how to populate the parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: it removes non-printing control characters (with explicit ASCII range and exceptions) and other invisible characters from text in a specified worksheet range. This specific verb+resource combination distinguishes it from sibling tools like remove_text_characters or trim_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. The description does not mention exclusions, prerequisites, or contrast with similar text-cleaning tools. The usage context is only implied by the character-removal behavior.
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 all behavioral traits. It mentions the operation and return value ('Returns True if the operation succeeds') but fails to explain whether the file is modified in place or a new token is generated, side effects, or permission requirements. This is a significant 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.
Conciseness5/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that clearly states the action and includes a brief return-value note. There is no filler or redundant content, making it 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 4 parameters, no annotations, and no schema descriptions, the description needs to provide comprehensive context. It covers the high-level behavior but lacks critical details about input formats, file modification semantics, and error handling. The brevity leaves an agent guessing on how to properly invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must fully explain parameter meanings. It mentions 'specified leading characters' (trim_text) and 'specified range of a worksheet' (_range) but does not clarify the format of _range (e.g., 'A1:B10') or the precise nature of trim_text (single character vs. set). The required file_token and worksheet parameters are not described at all.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Removes specified leading characters only (from the beginning) of text values within a specified range of a worksheet'. This specific verb+resource+scope distinguishes it from sibling tools like trim_text_from_trailing, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'only (from the beginning)' implies when to use this tool (for leading trims) but does not explicitly name alternatives or exclusion criteria. It provides implied usage guidance but lacks direct 'when to use vs. not use' statements.
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 carries the full burden of behavioral disclosure. It mentions the Base64 input encoding requirement but omits important behavioral details such as return format, error behavior, supported Excel file versions, file size limits, or whether the conversion is synchronous. This is a significant gap for a conversion 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 a single, front-loaded sentence that states the action and the key input requirement without any filler or redundancy. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given there is no output schema, the description must explain what the caller gets after conversion, but it does not. It fails to mention whether the result is a PDF file token, a download link, or another representation, which is essential for integrating this tool into a workflow. The simple scope does not fully compensate for this missing return-value information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides only a parameter name (spreadsheet_b64string) with 0% description coverage, and the description confirms that input must be a Base64 encoded string. However, this largely reiterates what the parameter name already implies and adds no extra constraints like maximum size, MIME type, or whether a data URL prefix is accepted. It is adequate but not enriching.
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 ('Convert') and clearly identifies source and target resources ('Excel file' to 'PDF'), which immediately distinguishes it from related tools like convert_excel_to_csv or convert_ods_to_pdf. It leaves no ambiguity about the tool's core function.
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 an Excel-to-PDF conversion is needed, but it does not explicitly address when to use this tool versus siblings such as convert_spreadsheet or convert_ods_to_pdf. No exclusions, prerequisites, or alternative recommendations are provided, so the guidance is only implied by the tool's purpose.
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 full disclosure burden. It states the core operation and return value ('Returns True if the operation succeeds'), but does not disclose important behavioral details such as whether the file is modified in place, what happens if 'number' exceeds text length, or the default behavior when '_range' or 'worksheet' are omitted.
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, compact sentence that front-loads the action and includes all essential operational information without unnecessary words. It is 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 lack of annotations, 0% schema parameter coverage, and the presence of optional parameters with unclear semantics, the description is incomplete for safe invocation. Critical details like range format, default behaviors, side effects on the file, and error handling are missing, making the tool under-specified 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 0%, so the description must compensate. It implicitly explains 'number' as N, '_range' as the specified range, 'worksheet' as the worksheet context, and 'file_token' as the file reference. However, it does not clarify the format of '_range', defaults for optional parameters, or how 'file_token' is obtained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action: 'Removes the last N characters from the end of each text cell within a specified range of a worksheet in an Excel file.' It includes the resource (text cells), scope (range, worksheet), and operation (removing last N characters), which distinguishes it from sibling tools like remove_first_n_characters.
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 explicit guidance on when to use this tool versus alternatives. It does not mention exclusions (e.g., 'use remove_first_n_characters for leading characters') or any context that would help an agent choose between this and the many similar remove_* tools.
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 behavioral disclosure. It discloses the core operation (converting case in a worksheet range) and the return value (True on success), implying a mutation. However, it does not explicitly state that existing cell values are overwritten, mention permissions or error handling, or clarify if the operation is reversible. This partial disclosure 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the verb and resource, followed by the case types and API context. It is efficient, but the phrase 'using Aspose.Cells Cloud API' is somewhat redundant and could be omitted. Overall, it is 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 4 parameters, no annotations, and an output schema that is likely just a boolean, the description is not complete enough for an agent to invoke the tool correctly. It lacks necessary details about range syntax, worksheet identification, and the exact accepted values for word_case_type. The description covers the high-level purpose but leaves critical invocation details to inference.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds meaning for word_case_type by listing possible values (uppercase, lowercase, etc.) and references worksheet and range. However, it does not explain the format of _range or how worksheet is specified, leaving key parameters ambiguous. The description adds some value but fails to fully document the parameters needed for correct invocation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: converting text case within a worksheet range. It lists the supported case types (uppercase, lowercase, title case, sentence case, toggle case) and explicitly differentiates it from sibling tools like trim_text or remove_* by focusing on case conversion. The verb 'Converts' and resource 'text case within a specified range' are 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 Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when text case needs changing, but does not provide explicit when-to-use or when-not-to-use guidance, nor does it name alternatives. There are no exclusions or comparisons to sibling tools, leaving the agent to infer relevance based solely on the tool's unique purpose.
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 available, the description carries the full burden of behavioral disclosure. It only states the conversion action and input format but fails to mention output behavior (e.g., return value or file token), possible limitations, or side effects. For a conversion tool, this is minimal 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 a single, concise sentence that immediately conveys the action and input format. There is no redundancy or extraneous information, making it efficiently structured and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with one parameter and no output schema, the description is mostly adequate, but it omits how the CSV result is returned (e.g., raw string, file token, or download). Given the sibling context of other converters, specifying the output mechanism would make the description more complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for the undocumented parameter. It does clarify that 'spreadsheet_b64string' refers to the Base64-encoded Excel content, adding meaning beyond the schema. However, it does not specify details like expected file extensions, encoding specifics, or constraints on the Base64 string.
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 'Convert' and clearly identifies the input format (Excel content as Base64 string) and the output format (CSV). This distinguishes it from sibling tools like convert_excel_to_pdf and convert_excel_to_json, which produce different output formats.
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 use case was converting Excel data to CSV, but it provides no explicit guidance on when to choose this tool over alternatives such as convert_excel_to_json or convert_spreadsheet. There are no stated prerequisites, exclusions, or contextual triggers 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 carries the full burden. It states the conversion behavior and return value, but fails to disclose whether the operation modifies the original file in-place or returns a new representation. The phrase 'converts numeric values to text strings' suggests a mutation, but the description does not warn about potential data loss or reversibility. It also does not mention any permissions or 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 concise, two sentences long, and front-loads the primary verb and resource. It is informative without being verbose, though it could be slightly more compact by omitting the API mention.
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?
An output schema exists, so return values need not be detailed in the description. The description covers the core functionality but lacks important context: whether the operation is in-place, how to specify the range and worksheet, and error behavior. For a relatively simple tool, it is adequate but has clear gaps that could lead to misuse.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate by explaining parameters. It mentions 'within a specified range of a worksheet', which gives some context for `_range` and `worksheet`, but it does not explain the format for `_range` (e.g., 'A1:B2') or the exact meaning of `worksheet`. The required `file_token` parameter is not mentioned at all. This is insufficient for low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the operation: converting numeric values (integers, decimals, percentages, currencies, dates, times) to text strings within a worksheet range. It distinguishes itself from sibling conversion tools by focusing on number-to-text conversion within a specific range, rather than whole-file format conversion.
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: it operates on a specified range of a worksheet in an Excel file. It implies when to use it (when you need numeric values in a range converted to text). However, it does not explicitly state alternatives or when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- 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 mentions the action and return value (True on success), but it does not specify whether the operation modifies the file in-place, whether permissions are needed, or what happens if no text cells are found. 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 a single, front-loaded sentence that conveys the core action efficiently. The inclusion of 'using Aspose.Cells Cloud API' is unnecessary and takes up space without adding value, but the rest is concise.
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 4 parameters, no annotations, and a claimed output schema (not shown to the evaluator). The description provides a basic return behavior but misses important context such as in-place modification, range syntax, and file_token meaning. Given the mutation nature, more details are needed for full completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must explain parameters. It implies the 'text' and '_range' parameters, and 'worksheet' is mentioned, but 'file_token' is not explained and the format of the range string is left ambiguous. This adds some value but does not fully compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: adds text to the beginning of each text cell in a specified range. The verb 'adds' and the resource ('text to the beginning of each text cell') clearly distinguish it from siblings like add_text_at_tail and add_text_before_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 clearly indicates when to use this tool: when text needs to be prepended to cells in a worksheet range. It does not explicitly contrast with alternatives, but the head/tail and before/after distinctions among siblings are implied by the description's use of 'beginning (head)'.
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 burden of behavioral disclosure. It specifies the replacement behavior and return value, but does not disclose whether the operation is destructive, what happens if no line breaks are found, or any side effects on the file. The disclosure 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 a single, front-loaded sentence with no redundant words. It efficiently communicates the core action and return value, making it easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 4 parameters and no annotations, the description should provide more context about required inputs and optional behaviors. It covers the main function but omits details about parameters, prerequisites, and typical use cases. An output schema exists, which helps, but the description alone is not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It mentions 'replacement text string' (matching target_text) and 'worksheet range' (ambiguous for _range and worksheet), but does not explain file_token or the roles of optional parameters. The description provides insufficient 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's function: it replaces line break characters (\n, \r\n, \r) with a specified replacement text in a worksheet range. This specific verb+resource+scope distinguishes it from sibling tools like remove_all_line_breaks or remove_extra_line_breaks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains what the tool does but does not explicitly state when to use it relative to alternatives. There is no mention of scenarios or exclusions, leaving the usage context implied rather than explicitly guided.
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 mentions the input format (Base64 encoded string), but does not disclose what happens after conversion: whether the PDF is returned as a file, Base64, or something else. There is no mention of side effects, constraints, or return behavior. This is a significant gap for a conversion 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 short sentences, front-loaded with the purpose and followed by the key input requirement. Every word earns its place; there is zero fluff 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?
While the tool is simple with only one parameter and no output schema, the description fails to explain the output or return value. The agent cannot infer what the tool returns (e.g., a PDF file path, base64 string, or success indicator). Since the output schema is absent, the description should provide this context. It also lacks any mention of prerequisites or limitations, making it incomplete for autonomous 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 0%, so the description must compensate. It explicitly states that the input must be a Base64 encoded string, giving clear meaning to the parameter ods_b64string. This goes beyond the bare schema (type: string) and tells the agent the expected format. Although it does not repeat the parameter name, the semantic mapping is clear and actionable.
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: converting an ODS file to PDF. The verb 'Convert' and resources 'ODS file' and 'PDF' are specific, and the tool name distinguishes it from siblings like convert_excel_to_pdf. There is no ambiguity about what this 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 usage: when you need to convert an ODS file to PDF. However, it does not explicitly mention when to use this tool over alternatives like convert_spreadsheet or save_spreadsheet_as, nor does it provide exclusions or alternative recommendations. The format-specific naming gives some guidance, but explicit alternatives are absent.
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 transparency burden. It discloses the exact characters removed, preservation of other characters, and return value (True on success), but does not mention side effects, permissions, or how the file is updated.
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 front-load the core operation and add only useful details about preservation and return value. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has an output schema, return values are covered, but the description omits behavior when optional parameters are absent (e.g., default range) and how file_token relates to prior upload. These gaps make it adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides no descriptions for the three parameters, and the description only hints at range and worksheet ('within a specified range of a worksheet') without explaining their format or the required file_token. This leaves the required parameter largely unexplained.
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 it removes all alphabetic characters (A-Z, a-z) from cells in a specified Excel range, which clearly differentiates it from sibling tools like remove_numeric_characters or remove_symbols. It also specifies that numbers, symbols, and whitespace are preserved.
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 stripping letters while keeping other character types, but it does not explicitly mention alternatives or when not to use it. It lacks comparative guidance against sibling removal tools.
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 that the operation returns True on success, and notes it applies to a 'specified range of a worksheet'. However, it omits details about whether the file is modified in place, permissions required, or error handling, leaving notable gaps for a mutating 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 a single focused sentence, front-loading the action and scope. The mention of 'using Aspose.Cells Cloud API' adds context but is slightly verbose; overall it is economic without unnecessary repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given four parameters, no schema descriptions, and no annotations, the description does not provide enough context. It fails to explain the range format, whether the file is modified in place or a copy is returned, and any side effects or limitations. The return value is covered, but other critical aspects are missing for reliable invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It references 'specified trailing characters' (trim_text), 'specified range' (_range), and 'worksheet', providing some meaning. But it does not explain parameter formats (e.g., range notation, worksheet name syntax) or that trim_text defaults to a space, which are important for correct usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Removes specified trailing characters only (from the end) of text values within a specified range of a worksheet in an Excel file'. It names the exact resource and operation, and distinguishes it from sibling tools like trim_text and trim_text_from_leading by emphasizing 'trailing' and 'only'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use this tool: it is for trailing characters only, implying leading characters should be handled differently. However, it does not explicitly mention alternative tools or state when not to use it, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the operation returns True on success and targets 'text cell's, but does not explain side effects like whether existing content is overwritten or appended, error behavior on failure, or any permission/authentication requirements. This adds moderate value 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 a single, front-loaded sentence that communicates the primary purpose and return value without any filler. Every phrase contributes necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's relative simplicity and the presence of an output schema, the description covers the core operation and success return. However, it lacks details about non-text cells, error handling, and prerequisites like file_token, making it adequate but not fully comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains 'text' and 'range' conceptually, but does not define parameter names, explain file_token, or clarify optional parameters like _range and worksheet. The description adds minimal semantic value beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action: 'Adds specified text to the end(tail) of each text cell within a specified range of a worksheet in an Excel file.' It uses a specific verb and resource, and the 'end(tail)' phrasing distinguishes it from sibling tools like add_text_at_head.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by describing the action and scope ('within a specified range of a worksheet'), providing clear context. It does not explicitly mention alternatives or provide 'when-not-to-use' guidance, but the straightforward nature of the tool makes the use case evident.
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 multiple line breaks are collapsed to single or removed entirely, and that the operation returns True on success. However, it omits side effects, error handling, and what 'based on configuration' actually means, creating 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 two sentences, front-loaded with action and scope, and contains no filler. It efficiently adds behavioral details and return value in the second sentence.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, scope, and success criteria. However, it leaves gaps around the 'configuration' details, file_token purpose, and range format, and does not fully anticipate all operational questions. Given a simple tool with an output schema, it is largely complete but not fully self-contained.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It adds meaning to _range and worksheet by indicating 'specified range of a worksheet', but does not explain formats, defaults, or the required file_token. The mention of 'configuration' does not correspond to any parameter in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('Removes') and specific resource ('excessive line breaks from text values within a specified range of a worksheet'), differentiating it from sibling tool remove_all_line_breaks by targeting only 'excessive' breaks rather than all breaks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for cleaning up redundant line breaks in a specified area, but it does not explicitly state when to prefer this tool over alternatives like remove_all_line_breaks, nor does it mention any exclusions or prerequisites. The context of 'excessive vs all' is implied but not directly 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?
With no annotations, the description carries the full burden. It provides useful behavioral context (preserves non-digits, returns True on success) but omits side effects such as whether the original file is modified, whether it is reversible, or if authentication is required. This is sufficient for basic use but lacks deeper safety and side-effect 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 two sentences, front-loaded with the action, and every word adds value. There is no fluff or repetition of parameter names. It efficiently conveys the operation, scope, preservation behavior, and return value.
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 core purpose and result, but lacks parameter syntax guidance and side-effect disclosure. Given the tool's simplicity and the presence of an output schema, it is minimally complete, but it does not fully equip the agent to use the tool confidently without additional assumptions.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate for parameter meaning. It mentions 'specified range' and 'worksheet' but does not explain the expected format for _range (e.g., 'A1:B2') or worksheet (e.g., sheet name vs. index). The file_token is also not elaborated beyond being a token, which is implied by context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'Removes' and clearly identifies the resource: numeric digit characters from cells in a specified worksheet range. It distinguishes itself from sibling tools like remove_symbols or remove_text_characters by explicitly focusing on digits and stating what is preserved.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states it removes digits while preserving letters, symbols, and whitespace, implying it should be used when only numbers need to be stripped. Sibling tools imply alternatives (e.g., remove_symbols for symbols), but the description does not explicitly mention when to use this tool over others, so it misses the full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It thoroughly discloses character-level behavior, listing exactly what punctuation is removed (periods, commas, brackets, etc.) and what is preserved (letters, numbers, spaces, currency symbols, math operators). It does not mention file-level effects like whether the original file is modified, but the character behavior 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 multiple sentences but every sentence adds value: it defines the action, provides the character sets, and gives use cases. No filler or repetition; it is well-structured and appropriately sized for the tool's complexity.
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 text-processing tool with an output schema, it covers the core behavior and use cases thoroughly. It lacks explicit parameter explanations and file-handling details, but given the low complexity and the existence of an output schema, these are not critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any parameters (file_token, _range, worksheet). It adds no meaning beyond the schema's property names, forcing the agent to infer the purpose of file_token and optional scope parameters from context 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?
Clearly states it removes punctuation marks from text cells while preserving alphanumeric characters and other symbols. This distinguishes it from siblings like remove_symbols or remove_numeric_characters by explicitly defining what is removed (punctuation) and what is preserved (symbols).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit use cases: 'useful for text preprocessing in NLP, removing sentence boundaries for analysis, cleaning text for word counting, or preparing data for text mining.' It implies when to use this tool but does not directly compare with alternatives or state when not to use it, so it lacks explicit exclusions.
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 must carry the behavioral burden. It explains that scaling modes can compress data onto a single page or adjust column widths, affecting page layout. But it doesn't mention output file creation details, permissions, or side effects like overwriting, leaving some behavioral aspects undisclosed.
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?
Two sentences, efficient and front-loaded, though some redundant phrasing ('perfectly addressing issues') adds little value. The structure is clear and readable.
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?
Covers core purpose and usage context well, but lacks specifics about file_token requirements, supported formats list, and return/error behavior. With no output schema and no annotations, a bit more detail would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds meaning to scaling_mode with concrete examples, and mentions target formats like PDF/images. However, file_token is left undisclosed, and with 0% schema coverage, the description only partially compensates for the missing parameter 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 tool's function: handling print scaling for spreadsheet conversions, with examples of scaling modes. It distinguishes from sibling tools like save_spreadsheet_as by focusing on scaling strategies and page layout conformity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides clear context: use for large-scale data reports to prevent content truncation or layout disorder. However, it doesn't explicitly reference alternative tools or exclusion cases, so 4.
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 that the input is a Base64 string and the output is JSON, which is helpful. However, it does not disclose how multiple sheets are handled, whether standard Excel formats are supported, or any limitations/error behavior, leaving meaningful 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 a single, front-loaded sentence that conveys the core action and input format without any filler words. Every word earns its place, making it highly 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?
For a simple one-parameter converter, the description adequately states input and output, but with no output schema it does not clarify the structure of the resulting JSON (e.g., array vs object, handling of multiple sheets). This is a notable gap, though not severe given the tool's apparent simplicity.
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 only defines the parameter as a string with no description (0% schema coverage). The description compensates by clarifying that the string must be Base64-encoded Excel content, which is essential for correct invocation. However, it does not mention file format limits or size constraints, so it is not fully comprehensive.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('Convert') and resource ('Excel content') with a clear target format ('to JSON'). The name and description clearly distinguish it from sibling tools like convert_excel_to_csv, convert_excel_to_pdf, and convert_excel by specifying the JSON output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used when Excel content needs to be converted to JSON, and notes the input must be a Base64 string. However, it provides no explicit guidance about when not to use this tool versus the many sibling conversion tools (e.g., convert_excel_to_csv, convert_excel_to_pdf).
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 burden. It discloses 'Supports case-sensitive or case-insensitive removal' and 'Returns True if the operation succeeds', giving some behavioral insight. However, it does not mention side effects, authentication, file mutation semantics, or failure behavior, so coverage is incomplete.
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, front-loaded with the core action and scope, followed by a behavioral detail. No filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a utility tool with 5 parameters and no annotations, the description covers the core operation and return value, but lacks details on parameter formats, range defaults, and edge cases. It is functional 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 0%, so the description must compensate. It maps custom_characters, _range, worksheet, and case_sensitive to their roles, but does not clarify the format for custom_characters or defaults for _range/worksheet. file_token is not mentioned, though it's a common concept. Overall, adds some meaning but has 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 verb 'removes', the target 'user-specified custom characters from text values', and the scope 'within a specified range of a worksheet in an Excel file'. It differentiates from siblings like remove_numeric_characters by emphasizing 'user-specified', making its 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 indicates it's for removing custom characters, which distinguishes it from sibling tools that remove predefined character classes. It also mentions case-sensitivity options, giving usage context. However, it does not explicitly name alternative tools or provide exclusions.
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 behavioral burden. It discloses that the tool returns contents as a Base64-encoded string, which is a key behavior. However, it does not mention potential errors, whether it is read-only, or any side effects, leaving some behavioral aspects undisclosed.
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, efficient sentence that immediately conveys the action, input, and output. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one parameter and no output schema, the description adequately covers the purpose, input, and output. It might be improved by noting file size limits or token usage, but given the tool's simplicity, the description is sufficiently 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 schema provides only the parameter 'file_token' with no description, and schema description coverage is 0%. The description adds that the token identifies the file, which gives some meaning, but it does not explain where tokens come from or their format. This is acceptable for a simple tool but could be more explicit.
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 'download' and names the resource 'file' with the identifier 'file token', clearly stating the action and distinguishing it from sibling tools like upload_file or structure-related tools. It also specifies the output format (Base64-encoded string), leaving no ambiguity about 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 Guidelines4/5Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the tool is used when you have a file token and need the file's contents. It provides the context for use but does not explicitly mention when not to use it or point to alternatives like get_structure_with_file_token, which is a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden and does well by disclosing exact characters removed (\n, \r\n, \r), the scope (specified range of a worksheet), and the return value. However, it does not mention whether the file is modified in place, overwritten, or requires prior upload.
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, front-loaded with the core action, and contains no filler or redundant details. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a moderate-complexity tool with no annotations but an output schema, the description covers the essential behavior, characters, scope, and success return. It lacks explicit mention of prerequisites (e.g., obtaining file_token via upload_file) and whether the operation is persistent, but overall it is sufficiently informative.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It adds contextual meaning by indicating 'within a specified range of a worksheet in an Excel file', which relates _range and worksheet to the operation. Yet it does not explain that _range has a default null, what format the range should take, or how worksheet/file_token interact.
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 tool removes ALL line break characters from text values in a specified worksheet range, using a specific verb and resource. It explicitly distinguishes itself from the sibling remove_extra_line_breaks by emphasizing 'ALL'.
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 all line breaks must be removed from text, but it does not explicitly mention when to avoid using it or suggest alternatives such as remove_extra_line_breaks. No clear when-not or alternative guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
- Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It clearly discloses the read-only nature of the tool and describes the return structure (Format Name, Extension, Description). It also adds useful context about the difference between load and save formats, implying potential read-only/write-only limitations. Minor gap: it doesn't mention whether the list is exhaustive or version-dependent, but overall strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections and front-loaded title. It is slightly verbose for a zero-param tool, but every section adds value (purpose, returns, usage). The bullet lists improve scannability. Minor redundancy in repeating 'load formats (Input)' vs 'save formats (Output)' but acceptable.
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 query tool with no params and no output schema, the description is complete. It explains what the tool returns (three fields), when to use it, and how it relates to sibling tools. There is no missing context needed for an agent to invoke and interpret results 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 tool has zero parameters, so the baseline is 4. The description adds no parameter-specific information because none exist, which is appropriate. It does explain the output fields, but parameter semantics are not applicable.
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: 'Use this tool to query the list of all source file formats that Aspose.Cells can read (load).' It specifies the verb 'query', the resource 'supported load formats', and explicitly distinguishes from sibling list_supported_save_formats.
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 when-to-use guidance: 'Call this tool when a user wants to upload or process a non-standard Excel file...' and lists concrete scenarios (before upload_file, when user asks about CSV). It also warns to distinguish load vs save formats, which are 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?
Without annotations, the description carries the full burden of disclosing behavior. It fully describes what the tool returns (Format Name, Extension, Description) and explains its role in the conversion workflow. This is transparent for a read-only 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.
Conciseness4/5Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with sections, bullet points, and a clear returns list. It is slightly verbose with emojis and repetitive phrasing, but every sentence provides useful information and the organization aids readability.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is fully complete for a tool with no parameters and no output schema. It explains the return values, when to use the tool, and how it relates to conversion tools (convert_file, convert_with_options). It gives enough context for an agent to select and invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 does not need to explain parameter details, and it does not add any irrelevant information. The schema coverage is 100% as there are no parameters to describe.
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: to query the list of file formats supported by Aspose.Cells for conversion. It uses a specific verb ('get') and resource ('supported file save/export formats'), and differentiates from sibling tool 'list_supported_load_formats' by focusing on save/export formats.
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 provides usage context: call this tool when a user requests a conversion and you need to verify the correct file extension or availability. It also gives a concrete recommendation to call it before using convert_file or convert_with_options if unsure about the target_format parameter, which is actionable and clear.
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/aspose-cells-cloud/Aspose.Cells-Cloud-MCP-Server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server