xlsx-tools-mcp

by ruriazz

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation4/5
Most tools are clearly distinct, but list_sheets and get_workbook_info both describe sheet listings with different levels of detail, which could cause an agent to pick the wrong one. The remaining tools each target a unique operation (merge, style, search, aggregate, etc.) with minimal ambiguity.
Naming Consistency5/5
All 20 tool names follow a consistent verb_noun pattern in snake_case (e.g., merge_cells, list_sheets, delete_rows). Verbs clearly describe the action and nouns identify the object, making the set predictable and easy to navigate.
Tool Count4/5
20 tools is on the heavier side but appropriate for a comprehensive xlsx manipulation server. Each tool covers a distinct aspect (workbook, sheet, cell, row, column, formatting, search, aggregation), so the count is justified despite exceeding the ideal range.
Completeness4/5
The surface provides solid CRUD coverage for workbooks, sheets, rows, columns, and cells, along with search, aggregation, and recalculation. Minor gaps exist such as no copy/rename sheet or comment editing, but these are edge cases that don't break core workflows.
Average 4.2/5 across 20 of 20 tools scored. Lowest: 3.5/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 11 commits in the last 12 weeks
- Last stable release on August 16, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
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.json to 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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral implications. It does not state whether existing formatting is overwritten or merged, whether the file is automatically saved, or if special permissions are needed. This is a mutation tool and should clarify side effects and state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise: a one-sentence summary followed by a focused parameter list. No redundant information or padding. Each line adds value, and the structure is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description provides good parameter coverage but lacks behavioral context (e.g., save behavior, style replacement semantics). Since an output schema is present, return-value details are not required, but the absence of side-effect disclosure leaves the tool partially incomplete for a mutation operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description compensates for 0% schema coverage by explaining all parameters, especially the 'style' object with an enumerated list of valid keys (bold, italic, font_size, etc.) and the 'path' parameter's optional behavior. However, some values (e.g., allowed alignment strings) are left vague, so it does not fully exhaust the parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Apply formatting to a range of cells', which uses a specific verb ('apply') and clear resource ('range of cells'). This clearly differentiates it from sibling tools like merge_cells, write_cells, or read_sheet.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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. It does not mention, for example, that cell values should be written with write_cells, or any distinctions from formatting-related operations. The description only states what it does, not when it is 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?
No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the operation is a merge but does not mention side effects such as how data in merged cells is handled (e.g., only the top-left value is kept), whether the file is modified in place, or if the operation is reversible. This lack of detail leaves significant behavioral ambiguity for an agent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, using a one-sentence purpose statement followed by a clean Args list. Every sentence earns its place, and the structure is front-loaded with the core action. No wasted words or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is relatively simple, and the description covers the basic operation and parameters. However, it lacks important context about the behavior on cell contents during a merge, which is a common nuance. Since there is an output schema (not shown), return values are covered, but the description still leaves gaps about the operational side effects and constraints, making it only minimally complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It provides meaningful explanations for all three parameters: path (file or preloaded, omit if one file), sheet (name), and cell_range (A1-style with an example). This adds context beyond the bare schema titles, making the parameters clearer and reducing ambiguity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action: "Merge a rectangular range of cells into one." This clearly distinguishes it from siblings like unmerge_cells (the inverse operation) and set_cell_style (styling). The verb 'merge' and the resource 'cells' 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/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage: you use it when you want to merge cells into one, with an example range provided. However, it does not explicitly mention when not to use it or discuss alternatives like unmerge_cells for reversing the operation. There is no guidance on selecting this over other cell manipulation tools, so it only meets the 'implied usage' level.
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?
There are no annotations, and the description does not disclose behavioral traits such as side effects, error conditions, whether the file is modified in place, or what happens if the range is not merged. 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and uses a clear structured Args list. Every sentence earns its place without unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose and parameters but lacks behavioral transparency, error handling, and explicit usage guidance. For a tool of this complexity, it is adequate but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that explains each parameter, adding meaning beyond the bare schema titles. Path is well explained, and cell_range specifies it is A1-style and previously merged, though more format detail could be given.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Undo a merge on a range of cells.' This is a specific verb+resource and distinguishes the tool from its sibling merge_cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage on previously merged ranges and provides guidance on omitting path when one file is configured, but it does not explicitly discuss when to use this tool vs alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral disclosure. It only states the primary action and does not mention what happens if the sheet name already exists, how index bounds are handled, whether changes are persisted, or error conditions. This is a significant transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, with a clear action statement followed by a straightforward parameter list. No word is wasted; every sentence contributes functional information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all three parameters and the core operation, making it minimally viable for a low-complexity tool. However, it omits common edge cases like duplicate sheet names, invalid index ranges, and file-save behavior, which would help the agent anticipate errors or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description fully compensates by explaining each parameter's meaning and default behavior. For instance, it clarifies that 'index' is zero-based and omitting it appends to the end, and 'path' can reference a preloaded file.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Add a new empty sheet') and the target resource ('existing workbook'). This distinguishes it from siblings like create_workbook and delete_sheet, leaving no ambiguity about its purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'existing workbook' provides clear context that this tool is for adding sheets to already-created files, implying it is not for creating new workbooks. However, it does not explicitly name alternatives or list exclusion criteria, 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.
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 does state a key failure condition ('Fails if it is the only sheet left') and the path behavior, but it does not mention whether the deletion is permanent, how saving works, or any side effects on formulas or references. This is somewhat transparent but leaves important gaps for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is ultra-compact: one sentence stating the action and a two-item Args list. Every word earns its place, and the most important information (the action and the failure condition) is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no annotations, the description covers the essential behavior: what it does, the main failure mode, and parameter usage. It doesn't explain the return value, but an output schema exists and the operation is straightforward. It's complete enough for the agent to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the Args section is the primary source of parameter meaning. It provides meaningful semantics for 'path' (path to file or preloaded file, omit if only one file) and clarifies 'sheet' (name to delete). The description adds value beyond the bare schema titles, especially for 'path'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Delete' with the resource 'sheet from a workbook', clearly distinguishing this from sibling tools like delete_rows or delete_columns. The additional constraint 'Fails if it is the only sheet left' further clarifies the operation's scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (to delete a sheet) but does not explicitly contrast with alternatives like deleting rows or columns. The note about omitting 'path' when only one file is configured gives some usage context, but there's no direct 'when to use vs. other tools' 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 provided, the description carries the full burden. It states the operation (group/aggregate) but does not explicitly mention that it is read-only, what side effects occur (likely none), or any permission requirements. The arg details add some context but not full behavioral transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single opening sentence followed by a compact, well-organized Args list. Every line adds value, no fluff, and the main purpose is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 params, nested objects) and the existing output schema, the description covers the operation and all parameters adequately. It could be slightly more complete by explicitly noting the operation's read-only nature and return value, but the output schema covers the return and the description is otherwise thorough.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description thoroughly explains all six parameters: path, sheet, group_by, agg, cell_range, and has_header. This fully compensates for the lack of schema descriptions, providing clear meaning and examples.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Group and aggregate sheet data with pandas' with a concrete example ('sum sales by region'). This is a specific verb+resource that distinguishes it from siblings like read_sheet or write_cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage through its name and purpose, and provides parameter-level guidance (e.g., 'Omit if only one file is configured') but does not explicitly explain when to choose this tool over alternatives or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It explains the 'real path' requirement and the overwrite behavior, but does not clarify what happens if the file exists and overwrite is False, nor whether parent directories are created. These are significant behavioral gaps 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded with the purpose, followed by a clean Args list. Every sentence adds value, with no redundant or vague text. The structure is easy to scan and understand.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity and the presence of an output schema, the description covers most essential aspects: purpose, parameters, and key constraints. Minor omissions like error behavior on existing files without overwrite prevent a perfect score. Overall, it is nearly complete for a create operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description thoroughly explains each parameter beyond the schema: path must be real, sheets defaults to 'Sheet1', and overwrite controls replacement. Since the schema has no descriptions, this is essential and well-executed. It provides clear semantics for all three parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Create a new .xlsx workbook', which clearly identifies the verb and resource. This differentiates it from sibling tools like create_sheet, which likely operates on an existing workbook. The mention of '.xlsx' also specifies the file format.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new workbook but does not explicitly mention when to use it over create_sheet or other file-related tools. It does provide contextual clues ('New files aren't preloaded') but lacks direct alternatives or exclusions. Thus, usage guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the transparency burden. It discloses the data fields returned, but it does not explicitly state that the operation is read-only or describe error behavior (e.g., missing file or invalid cell reference). The verb 'get' implies no mutation, but more explicit disclosure would improve 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct and well-structured. The first sentence states the purpose, followed by a clean Args list with explanations. There is no filler or redundant information, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get tool with three parameters and no annotations, the description covers the essential aspects: what it does, parameter semantics, and expected return fields. It does not address alternative tool selection or edge-case behavior, but given the simplicity, it is largely complete. The presence of an output schema also reduces the need to detail return values, though the description still lists them.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides detailed explanations for all three parameters in the Args section, including path semantics (preloaded file or default), sheet name, and cell reference with an example. This fully compensates for the 0% schema description coverage, adding meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Get full detail for a single cell' and enumerates the specific aspects (value, formula, number format, font, fill, merge, comment). This distinguishes it from sibling tools like read_sheet or write_cells, which handle ranges or modifications.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving detailed cell information, but it does not explicitly mention when to prefer this tool over alternatives (e.g., read_sheet for ranges) or provide exclusions. The context of 'single cell' is clear, but no specific guidance is offered.
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 transparency burden. It adds detail about being approximate and covering every sheet, but does not explicitly state read-only behavior, hidden sheet inclusion, or ordering. This is adequate but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences plus a parameter block, front-loading the main purpose. No filler words; every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple listing tool with an output schema and one optional parameter, the description covers purpose, parameter, and output content. No crucial gaps; however, it could mention whether hidden sheets are included or if there are prerequisites, but these are minor.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has zero description coverage, but the description fully explains the path parameter: path to .xlsx or preloaded file, and when to omit. This adds significant semantic value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists every sheet in a workbook with approximate row/column counts. The verb 'list' and resource 'sheets' distinguish it from sibling tools like read_sheet or get_workbook_info.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly compare this tool to alternatives or state when to prefer it. It gives context about omitting the path when only one file is configured, which implies usage conditions but does not address tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral burden. It reveals that the operation is headless and reports errors, but it does not disclose whether the workbook file is modified/saved, runtime implications, or any prerequisites. This is a meaningful gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise: two sentences plus a compact Args list. It is front-loaded with the action and outcome, and every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and an output schema, this description covers the operation and parameter semantics adequately. However, it omits explicit guidance on when to invoke the tool and the potential side effects of recalculation. These are minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 0% description coverage, the Args section thoroughly explains the 'path' parameter, including handling of preloaded files and the omit-if-only-one-file behavior. This fully compensates for the schema's lack of detail.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Force') and resource ('LibreOffice headless recalculation pass') and states the outcome ('report any formula errors found'). It clearly distinguishes from sibling tools, none of which perform recalculation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The usage is implied: you would call this when you want to recalculate formulas and check for errors. However, no explicit when-to-use or alternative guidance is provided, and no exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The verb 'Get' implies a read-only operation, but with no annotations, the description doesn't explicitly state that no modifications are made or discuss file access permissions. It adds value by listing the metadata returned, but does not fully disclose behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is highly concise: a single sentence states the purpose, followed by a brief Args section for the only parameter. Every word earns its place, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one optional parameter and an output schema, the description covers the purpose, the metadata scope, and the path semantics. It provides sufficient context for an agent to know when and how to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema only provides the parameter name 'path', type (string/null), and a default. The description compensates fully by explaining that path can be an .xlsx path or preloaded file name and when to omit it, significantly adding meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb ('Get') and resource ('workbook-level metadata'), and enumerates concrete items (sheets, dimensions, active sheet, defined names). This distinguishes it from sibling tools like read_sheet or list_sheets.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving workbook metadata but does not explicitly state when to prefer this tool over alternatives or provide exclusions. The note about omitting the path when only one file is configured gives some situational guidance, but no direct comparison to related 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 burden of behavioral disclosure. It reveals that existing columns shift right and that recalculate triggers a LibreOffice recompute pass that can be skipped. However, it does not mention file save semantics, potential data loss, or error behavior, leaving some ambiguity 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is tightly structured: a bold first sentence states the core action, one sentence adds a practical nuance, and the Args block is compact and scannable. Every sentence earns its place without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (5 parameters, no annotations), the description covers all parameters and the key side effect (shifting columns), and an output schema exists to handle return details. It is missing alternatives and file-modification semantics, but remains largely complete for practical use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args block that explains all five parameters, including the 1-based indexing of start_column and the purpose of recalculate. This adds meaning beyond the bare schema, though some parameters (path, sheet) are only minimally explained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with 'Insert blank columns, shifting existing columns right,' which is a specific verb+resource+behavior statement that clearly distinguishes this tool from siblings like insert_rows and delete_columns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when the tool is appropriate (inserting columns) and includes a targeted guideline for setting recalculate=False with a concrete example (structurally complex workbooks). It does not explicitly mention alternatives or exclusions, but the context is unambiguous.
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 return format (2D array), absolute addressing from A1, the default behavior of reading the full used area, and the max_rows cap. It does not mention error cases or auth requirements, but for a read operation this is reasonably transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loaded with the main purpose, and each parameter explanation adds value. No redundant or filler content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description need not explain return values. It covers core behavior, common parameter combinations, and the max_rows guard against large responses. Minor gaps remain around error handling and behavior when path is ambiguous, but overall it is complete for this tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All four parameters receive meaningful explanation beyond the schema: path is described as a file path or preloaded file with an omission rule, cell_range is given with an A1-style example and default behavior, and max_rows is explained as a response-size bound. This fully compensates for the 0% schema description coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool reads cell values from a sheet as a 2D array with absolute A1 addressing. It distinguishes this from sibling tools like get_cell by specifying the bulk/2D array behavior.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives useful guidance for when to omit path, cell_range, and max_rows, but it does not explicitly explain when to use this tool over alternatives such as get_cell, aggregate_sheet, or search_workbook. No exclusionary or alternative-tool 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 provided, the description carries the full burden. It clearly states the mutation (inserting rows, shifting existing rows down) and discloses the LibreOffice recompute behavior with the recalculate parameter. This adds meaningful transparency beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-organized: a one-sentence purpose, a practical tip about recalculate, and a clear Args list. Every sentence earns its place without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 5-parameter tool with no annotations and a relatively simple action, the description covers all essential context: file path options, sheet, row insertion index, count, and recalculation behavior. The existing output schema likely covers return values, so no further explanation is needed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Although the schema has 0% description coverage, the description's Args section explains every parameter in detail, including path's preloaded-file behavior, start_row's 1-based indexing, count's default, and recalculate's purpose. This fully compensates for the schema's lack of descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: "Insert blank rows, shifting existing rows down." This clearly distinguishes the tool from siblings like insert_columns (columns), delete_rows (removal), and append_rows (adding at end).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage (insert when you need blank rows at a given position) but does not explicitly mention alternatives or when not to use. It does provide a conditional guideline about setting recalculate=False for complex workbooks, but this is a parameter-level tip rather than tool-selection guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the leftward shift behavior and the LibreOffice recompute pass, including a rationale for skipping it. It does not mention irreversibility or side effects on formulas, but the delete operation's permanence is implied and the provided context is substantial.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured. The opening sentence states the core action, followed by a targeted optimization note, and a clean bulleted Args list. Every sentence provides value, with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully covers the tool's behavior, side effects, and all parameters. Since an output schema exists, return values need not be described. The complexity of a destructive column-deletion operation is handled with clear explanation of column shifting and recalculate behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description compensates fully via the Args section. It explains all 5 parameters: path (file or preloaded name), sheet, start_column (1-based), count, and recalculate. This adds meaning beyond the raw schema fields.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action: 'Delete columns', and specifies the effect: 'shifting the columns to their right leftward'. This distinguishes it from sibling tools like delete_rows (row removal) and insert_columns (opposite operation).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use the tool (to delete columns) and includes a specific usage hint about setting recalculate=False for structurally complex workbooks. However, it does not explicitly mention alternatives or when-not-to-use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since annotations are absent, the description carries the burden. It discloses that rows below the deletion shift upward and explains the recalculate behavior (a LibreOffice recompute pass after saving). This adds meaningful behavioral context beyond the tool name and schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is compact and well-structured: a one-line summary, a practical tip about recalculate, and a clean bullet-style Args list. Every sentence provides useful information with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, omitting return-value details is appropriate. The description covers all parameters, explains the row-shifting consequence, and includes a note about file saving and LibreOffice recalc, making it complete for this moderately complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description includes an Args section that explains all five parameters (path, sheet, start_row, count, recalculate) in plain language. This fully compensates for the schema's lack of descriptive text.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool deletes rows and explicitly notes that rows below shift upward. This distinguishes it from sibling tools like delete_columns and delete_sheet, which operate on different elements.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives concrete guidance on when to set recalculate=False (structurally complex workbooks that shouldn't be round-tripped through LibreOffice). It doesn't explicitly contrast with alternative deletion tools, but the operation is self-explanatory and the sibling set is broad enough that no such guidance is essential.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full transparency burden. It discloses the substring matching behavior, the ability to search one or all sheets, the case-sensitive option, and the limit to bound response size. It does not explicitly state that the operation is read-only, but 'Search' strongly implies non-mutating behavior, making this a solid, though not exhaustive, disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise: a single-sentence summary followed by a compact Args list. Each parameter gets exactly one line with clear intent and no redundant information. Every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema (which handles return values), the description covers all necessary input semantics, usage context, and behavioral details. It explains how to handle multiple files, sheet restriction, case matching, and response size, making it complete for this search tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does 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 each parameter. The Args section provides meaningful semantics for all five parameters: path (file or preloaded name), query (substring), sheet (restriction or all), match_case (case sensitivity), and limit (response size bound). This goes well beyond the schema's titles and defaults.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with 'Search cell values across one or all sheets for a substring match,' which uses a specific verb (Search), resource (cell values across sheets), and scope (substring match). It clearly distinguishes from sibling tools like read_sheet or get_cell by emphasizing search semantics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context on when to use the tool: whenever substring search across sheets is needed. It explains how to restrict to one sheet ('Restrict the search to one sheet; omit to search every sheet') and mentions omitting path when only one file is configured. No explicit alternatives are listed, but the search-focused purpose inherently guides the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses the recalculation step, the possibility of errors_found from recalculation, and the create_sheet_if_missing behavior. It stops short of explicitly stating that existing cell contents are overwritten, but that is implied by the action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description follows a clean docstring format: a one-sentence summary, a practical usage note, an Args list explaining each parameter, and a Returns line. Every sentence adds value with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers all 5 parameters, the return value including errors_found, and a key behavioral caveat about avoiding recalculation in complex workbooks. It is fully adequate for an agent to select and invoke this tool correctly, especially with an output schema also available.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains every parameter clearly and defines the structure of the cells list as objects with cell/value or cell/formula, which the schema leaves as additionalProperties. This is essential for correct use.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Write values and/or formulas into specific cells, then recalculate the workbook.' It also distinguishes itself from sibling tools like merge_cells and set_cell_style by focusing on cell content writing rather than structure or formatting.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides explicit guidance on when to set recalculate=False ('for structurally complex workbooks you don't want round-tripped') and clarifies the path parameter ('Omit if only one file is configured'). However, it does not explicitly name alternative tools for when not to use this one, so it stops short of a full 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full burden. It discloses the data source (XLSX_MCP_FILES env var), startup behavior, and that no filesystem search is needed. It stops short of explicitly stating the tool is read-only, but 'List' makes this obvious enough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two crisp sentences with the verb and core purpose front-loaded. Every clause earns its place—no wasted words, yet it conveys usage context and cross-tool integration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters and an output schema exists, so the description only needs to cover purpose and usage context. It fully explains when to call it and how its output feeds into other tools, making it complete for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters and schema coverage is 100%, so the baseline for this dimension is 4. The description adds useful context by explaining how the returned file names integrate with other tools' `path` parameter, but since there are no parameters to describe, it cannot go higher.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'List files preloaded at server startup' with a specific verb and resource, and distinguishes this tool from all sibling tools (which operate on sheets/cells, not file inventory).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly instructs 'Call this first if unsure which files are available' and explains how the result relates to every other tool's `path` argument, including the optional omission behavior. Provides clear when-to-use guidance with no ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It explicitly states the default recalculate behavior, the ability to skip it via `recalculate=False`, and the rationale (avoiding round-tripping complex workbooks). It also documents the `create_sheet_if_missing` side effect. This goes beyond a simple 'appends rows' statement and warns of potential file modifications.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core action, followed by a focused note on the recalculate flag, then a structured Args list. Every sentence earns its place: the first sentence states purpose, the second explains a key option, and the list documents parameters. No unnecessary verbosity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists, the description doesn't need to explain return values. It covers the full parameter set, the primary behavior, and a conditional edge case (recalculate=False). The path handling note ('Omit if only one file is configured') addresses multi-file contexts, making the description complete for a tool with five parameters and no annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates by explaining all five parameters: path, sheet, rows, create_sheet_if_missing, and recalculate. It gives format guidance for rows ('each a list of cell values in column order') and default behavior for recalculate, adding significant meaning beyond the raw schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: 'Append rows after the last used row of a sheet, then recalculate the workbook.' This clearly states what the tool does and distinguishes it from sibling tools like insert_rows (which insert at a specific position) and write_cells (which overwrite cells).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by defining the append position ('after the last used row') and provides a conditional alternative with `recalculate=False` for structurally complex workbooks. It does not explicitly name sibling tools as alternatives or state when not to use it, but the context is clear enough for an agent to infer appropriate use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

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:

[![xlsx-tools-mcp MCP server](https://glama.ai/mcp/servers/ruriazz/xlsx-tools-mcp/badges/card.svg)](https://glama.ai/mcp/servers/ruriazz/xlsx-tools-mcp)

Score Badge

Copy to your README.md:

[![xlsx-tools-mcp MCP server](https://glama.ai/mcp/servers/ruriazz/xlsx-tools-mcp/badges/score.svg)](https://glama.ai/mcp/servers/ruriazz/xlsx-tools-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/ruriazz/xlsx-tools-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server