xlwings Excel MCP Server

by fastmcp-me

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: v1.0.4
Disambiguation4/5
Tools are mostly distinct with clear purposes, though there is minor ambiguity between close_workbook and force_close_workbook_by_path_tool, and between various range operations. Descriptions generally help disambiguate.
Naming Consistency3/5
Most tools follow a verb_noun pattern, but the verbs vary (create, insert, delete, validate, etc.) and there is an outlier (force_close_workbook_by_path_tool). Inconsistent use of 'read_' vs 'get_' also detracts from consistency.
Tool Count5/5
29 tools cover a broad range of Excel operations without being overwhelming. The count is appropriate for a comprehensive Excel MCP server.
Completeness3/5
Core operations like workbook/sheet management, data read/write, formatting, charts, and pivots are covered. However, missing common features like sorting, filtering, row/column sizing, and dedicated conditional formatting tools limit completeness.
Average 3.4/5 across 29 of 29 tools scored. Lowest: 2.8/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- No commit activity data available
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
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?
No annotations are provided, and the description does not disclose behavioral traits such as whether it copies formatting, validation rules, or data behavior. For a mutation tool, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness2/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Although short, the description redundantly lists parameters that are already defined in the input schema, wasting valuable description space that could provide additional context.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 3 required parameters and no annotations, the description omits crucial details like expected return values, behavior on name conflicts, and whether the target sheet must exist or is created.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description adds no meaning beyond parameter names (e.g., 'Name of the source worksheet'). No constraints, formats, or required formats are specified.
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 'Copy worksheet within workbook' using a specific verb and resource, distinguishing it from sibling tools like rename_worksheet or delete_worksheet.
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 on when to use this tool versus alternatives, nor any prerequisites or exclusions. The description merely lists parameters without contextual usage advice.
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 only states it creates a worksheet, but omits any side effects, constraints (e.g., duplicate sheet names), or return value details. The existence of an output schema is not utilized in the description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and front-loaded with the purpose. The args are listed concisely. While there is some redundancy (the 'Args' section repeats parameter names), it is still efficient and easily parsed.
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?
Given the tool's simplicity and the presence of an output schema (not shown but known), the description is adequate but not fully complete. It does not cover error cases (e.g., invalid session, duplicate sheet name) or confirm what is returned, leaving some gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, but the description adds brief explanations for both parameters: session_id is 'Session ID from open_workbook' and sheet_name is 'Name of the new worksheet'. This adds some value beyond the schema's type and title, though it remains minimal.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool creates a new worksheet in a workbook, which is distinct from sibling tools like rename_worksheet or delete_worksheet. However, it does not explicitly differentiate from create_workbook, but contextually the session_id parameter implies an existing workbook.
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 on when to use this tool versus alternatives is provided. The description mentions session_id from open_workbook implicitly, but does not state prerequisites or scenarios where this tool should be used or avoided.
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 exist, so the description must fully disclose behavior. It does not mention what happens when validation fails, whether the tool is read-only, or any side effects. The output schema exists but the description does not explain the return value.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and well-structured with an Args list and a note. However, the Args list largely repeats the schema, so it could be more concise by focusing on additional context.
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?
Given the tool has 5 parameters and no annotations, the description lacks details on validation criteria and behavior. The output schema exists, so return value details are not required, but contextual completeness suffers from missing edge-case information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It lists parameters but only adds minimal value beyond names: specifying that session_id is preferred and filepath is deprecated. This is helpful but insufficient for full clarity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Validate if a range exists and is properly formatted', which is a specific verb+resource. It is distinct from sibling tools like write_data_to_excel or read_data_from_excel, though no explicit differentiation is given.
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 like validate_formula_syntax or read_data_from_excel. The note about preferring session_id over filepath is about parameter choice, not tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only says 'create chart' without mentioning side effects (e.g., overwriting existing charts), permission needs, or error states. This is insufficient for a creation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct with a clear first sentence followed by a parameter list. No unnecessary information. It could be more structured (e.g., grouping optional params), but it's acceptably concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters and the presence of an output schema, the description is incomplete. It does not explain return values, prerequisites (e.g., workbook must be open), or error handling. The output schema exists but is unmentioned.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description adds meaning by labeling each parameter (e.g., 'Name of worksheet'). However, the descriptions are very brief and lack validation details, types, or examples. Baseline 3 due to low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Create chart in worksheet' with a verb and resource. It distinguishes from siblings (no other chart creation tool) and lists parameters. However, it does not elaborate on different chart types or variations.
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 advises using session_id for better performance and notes filepath is deprecated. However, it provides no guidance on when to choose this tool over other tools (e.g., create_pivot_table, create_table) or context for chart creation.
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 behavioral traits. The description mentions deletion and deprecation of filepath, but does not specify the precise effect on the spreadsheet (e.g., columns shift left), whether the action is irreversible, performance implications, or required permissions. This leaves significant gaps in understanding the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, using a single paragraph with a bullet-like list to enumerates parameters. The purpose is front-loaded in the first sentence. Minor improvement could be to separate purpose and parameter details more clearly, but overall it is efficient and to the point.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema, the description does not mention return values or error conditions (e.g., invalid sheet name, out-of-range column). Given the tool is destructive and has 5 parameters with no annotations, the description should cover potential issues and expected outputs to be complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaningful context by listing parameters with brief explanations and noting that session_id is preferred over filepath. However, it does not clarify key details like whether start_col is 0-indexed or 1-indexed, or the exact effect of the count parameter on which columns are deleted.
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 ('Delete one or more columns') and the resource ('columns starting at the specified column'), making the purpose unambiguous. It effectively distinguishes this from sibling tools like delete_sheet_rows, which operate on rows instead.
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?
The description lacks guidance on when to use this tool versus other deletion tools (e.g., delete_range, delete_sheet_rows). It only hints at preferring session_id over filepath, but does not specify prerequisites, such as requiring an open workbook, or when alternatives 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?
No annotations are provided. The description states it deletes a worksheet, implying a destructive action, but does not disclose whether the deletion is permanent, if it requires special permissions, or what the return value indicates (e.g., success/failure).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences for the main purpose and two bullet points for parameters. The structure is efficient, though the parameter descriptions could be integrated more smoothly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a deletion tool with no annotations and a present output schema, the description lacks completeness. It does not explain the output, error handling, or behavior when the worksheet does not exist, leaving the agent with insufficient context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description adds meaning: it clarifies session_id as obtained from open_workbook and sheet_name as the worksheet name. However, it does not specify formats or constraints (e.g., sheet_name must exist).
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 ('Delete worksheet') and the resource ('workbook'), with a specific verb that distinguishes it from sibling tools like copy_worksheet or rename_worksheet.
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 (e.g., delete_range, clear contents). There is no mention of prerequisites, such as the worksheet being empty or not protected.
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 should fully disclose behavioral traits. It fails to mention side effects (e.g., cell content handling), constraints (e.g., adjacent cells only), or return values for this mutation 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/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences, and the parameters are listed in a structured args block. The note about session_id is efficient, but the overall structure could be more front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, schema descriptions, and a true output schema (not provided), the description misses crucial context: prerequisites, error conditions, and return value info for a transformation tool modifying workbook state.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description compensates with basic parameter semantics (e.g., 'Name of worksheet', 'Starting cell'). However, it lacks detail on formats (e.g., 'A1' notation) and does not explain all parameters beyond the args list.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool merges a range of cells, with a specific verb and resource. However, it does not differentiate from sibling tools like unmerge_cells or format_range, which could also involve cell merging.
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 provides guidance on parameter preference (session_id over filepath) and deprecation, but lacks context on when to use this tool vs alternatives like unmerge_cells or prerequisites (e.g., requiring an open workbook).
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 deprecation of filepath and performance preference for session_id, but does not state that the operation is destructive, irreversible, or requires an open workbook. Missing key behavioral details for a deletion 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: a single sentence for purpose, bulleted args, and a note. No wasted words, well-organized, and front-loaded. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness2/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema (missing details), the description omits prerequisites (open workbook), side effects (persistence), and distinguishes from siblings. For a deletion tool with 5 parameters and no annotations, this is incomplete for reliable agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description provides the only parameter documentation. Each parameter has a brief description (e.g., 'Name of worksheet', 'Row number to start deleting from'). Adds context like 'preferred' and 'deprecated' for session_id and filepath. Adequate but not rich.
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 'Delete one or more rows starting at the specified row.' It uses a specific verb (delete) and resource (rows), making the purpose unambiguous. It naturally distinguishes from sibling tools like delete_sheet_columns by specifying 'rows'.
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 explicit guidance on when to use this tool versus alternatives like delete_sheet_columns or delete_range. The note about preferring session_id over filepath is internal tool guidance, not selection guidance among siblings. The agent must infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description mentions 'create a session' but does not explain what a session entails (e.g., duration, locking, concurrency limits). No annotations are provided, so the description carries the full burden but fails to disclose key behavioral traits like mutability 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear docstring format (Args, Returns). The first sentence effectively summarizes the tool. Minor repetition of default values already in the schema.
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?
Given no annotations and an output schema that documents return values, the description covers basics but misses important context like session management, concurrency issues, and error handling. It is adequate but not comprehensive.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description compensates by explaining each parameter's purpose (filepath, visible, read_only) beyond type/default. However, it lacks details like acceptable file path formats or implications of read_only on editing.
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 it opens an Excel workbook and creates a session, distinguishing it from sibling tools like create_workbook (creates new) and close_workbook (closes). The verb+resource is specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does 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 such as create_workbook or read_data_from_excel. It does not mention prerequisites, file state (e.g., already open), or conditions for optimal 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, and the description does not disclose behavioral traits such as whether the rename is reversible, if it triggers any side effects, or if specific permissions are needed. It simply states 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and to the point, but includes an Args section that is somewhat verbose for a tool description. Could be more concise by integrating parameter details inline.
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?
Given the presence of an output schema (not detailed here), the description adequately covers the basics but lacks usage context and differentiation from similar tools. It is minimally complete for a simple rename operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description adds minimal meaning by explaining session_id as 'from open_workbook (required)' and naming the other parameters. However, it lacks details like valid name formats or constraints.
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 'Rename worksheet in workbook', which is a specific verb and resource. It distinguishes itself from sibling tools like copy_worksheet or delete_worksheet.
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 on when to use this tool versus alternatives, or any prerequisites beyond the session_id being from open_workbook. Does not mention that the worksheet must exist or that old_name must match exactly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description only states the action without disclosing behavioral details. Without annotations, the agent is not informed about potential side effects (e.g., overwriting cell content), error behavior, or whether the formula is immediately evaluated. The output schema exists but the description does not mention what is returned.
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: a one-line verb phrase followed by a clear parameter list. Every sentence earns its place, and the structure is front-loaded with the purpose. No unnecessary words.
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?
Given 4 required parameters and an output schema, the description covers the basic function but lacks completeness. It does not explain the relationship between this tool and siblings (e.g., when to use apply_formula vs write_data_to_excel), nor does it mention error handling or the need for a valid session. The output schema is present but not leveraged in the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes parameter explanations (e.g., 'session_id: Session ID from open_workbook') that add meaning beyond the input schema's type and title. However, the formula parameter is described vaguely as 'Excel formula to apply', missing details like supported syntax or escape rules. With 0% schema description coverage, the description partially compensates but could be more specific.
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 'Apply Excel formula to cell' is a specific verb+resource that clearly states what the tool does. It distinguishes itself from sibling tools like 'validate_formula_syntax' and 'write_data_to_excel' by focusing on formula application. No ambiguity.
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?
The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., an active session from open_workbook) or context where other tools like 'write_data_to_excel' might be more appropriate. This lack of usage direction leaves the agent uninformed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full burden. It mentions applying formatting but does not disclose whether it overwrites existing formatting, whether the operation is reversible, or any side effects. For a tool with many parameters, more behavioral context is needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose statement, but the bulk is a repetitive parameter list that largely mirrors the schema. The note at the end is concise. It could be more streamlined by grouping similar parameters, but it is not excessively verbose.
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?
Given the tool's complexity (19 parameters, no annotations, but an output schema exists), the description covers all parameters and includes a useful deprecation note. However, it lacks guidance on when to use this tool versus siblings like merge_cells, and does not describe return values or behavioral impacts. It is adequate but not comprehensive.
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's 'Args' section lists all 19 parameters with brief explanations (e.g., 'bold: Apply bold formatting'), adding semantics beyond the schema's property titles. The deprecation note for filepath is also helpful. However, some explanations are minimal (e.g., 'alignment: Text alignment' without allowed values).
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 'Apply formatting to a range of cells', using a specific verb ('Apply formatting') and resource ('range'). This distinguishes it from siblings that perform other operations like deleting ranges or merging cells.
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?
The description includes a note advising to use 'session_id for better performance' and marks 'filepath' as deprecated, but it does not provide guidance on when to use this tool versus alternative formatting or range tools, such as merge_cells or delete_range.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It does not disclose behavioral traits such as whether inserting columns shifts existing data, what happens with merged cells, or any side effects. The note about deprecation is helpful but insufficient for a data-modifying 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 concise with a clear opening sentence, structured Args list, and a brief note. Every sentence adds value without redundancy. It front-loads the core purpose.
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?
Given the 5 parameters, no annotations, and 0% schema coverage, the description covers the purpose and highlights the preferred parameter. However, it lacks explanation of the output schema and potential error conditions, leaving some gaps for a complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description includes an Args section that lists and explains each parameter (sheet_name, start_col, session_id, filepath, count), adding value over the schema which has 0% description coverage. However, it lacks specifics like indexing (1-based vs 0-based) or constraints on count.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states 'Insert one or more columns starting at the specified column', which clearly identifies the action and resource. However, it does not differentiate from sibling tools like 'insert_rows' or 'delete_sheet_columns', leaving ambiguity about when to use this specific tool.
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 note about preferring session_id over deprecated filepath provides parameter guidance, but no explicit direction on when to use this tool versus alternatives like 'insert_rows'. The usage context is implied but not fully articulated.
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 exist, so the description must carry the full burden. It does not disclose whether the tool overwrites existing files, requires specific permissions, or has side effects like saving to disk. The note about session_id hints at session association but lacks clarity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences for purpose and two lines for parameters. It is front-loaded with the core purpose, but could be more structured (e.g., separate usage and notes sections). Still, no redundancy.
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?
Given the tool's simplicity and the presence of an output schema, the description is partially complete. It lacks details on error conditions, prerequisites (e.g., need for an open session), and what the output contains. For a creation tool, this is a moderate gap.
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?
With 0% schema description coverage, the description adds meaningful context: session_id is for existing sessions, filepath is deprecated. This goes beyond mere type information, though more detail (e.g., format of session_id) would be helpful.
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 'Create new Excel workbook' clearly states the verb and resource, distinguishing it from siblings like open_workbook (opens existing) and create_worksheet (creates sheet within workbook).
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?
The description provides almost no guidance on when to use this tool versus alternatives. It mentions a deprecation note for filepath and recommends session_id, but does not discuss selection criteria among sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the tool writes 'without any verification,' which is a behavioral trait. However, it lacks details on overwriting behavior, error handling, or performance. With no annotations, more transparency is expected.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise with a clear first sentence. The 'Args:' section is redundant but not verbose. Each sentence adds information without excess.
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 parameters but lacks context about return values, error conditions, and prerequisites beyond what is implied by parameters. An output schema exists but its content is not considered.
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 adds meaning beyond the schema: explains session_id as 'from open_workbook', data as 'list of lists with sublists as rows', and start_cell as 'optional, auto-finds appropriate location'. Schema coverage is 0%, so this adds significant value.
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 data to') and the resource ('Excel worksheet'). It distinguishes from siblings like read_data_from_excel and create_workbook.
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 explicit guidance on when to use this tool vs alternatives. The description implies writing data but does not mention prerequisites (e.g., must have an open workbook) or scenarios where other tools are preferred.
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?
Without annotations, the description bears full responsibility. It states the deletion and shifting effect, but does not disclose whether the workbook must be open, if the operation is reversible, or any side effects. The deprecated filepath note is insufficient.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is succinct, with a one-line overview followed by a bullet-style parameter list. No redundant information, and the deprecated note is appropriately placed.
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 existence of an output schema, the absence of return value description is acceptable. The param explanations are thorough, but the description could mention the required prerequisite of an open workbook session.
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 explain parameters. It provides clear explanations for all six parameters, including acceptable values for shift_direction ('up' or 'left'), and notes about session_id preference and filepath deprecation. This adds significant value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Delete a range of cells' and the resource 'range of cells'. It is specific enough to distinguish from row/column deletion siblings, though it does not explicitly differentiate.
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 on when to use this tool versus alternatives like delete_sheet_rows or delete_sheet_columns. The note about session_id is parameter guidance, not usage context. No prerequisites or exclusions mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It does not disclose whether the tool is read-only, its side effects (likely none), error behavior, or any prerequisites beyond the session_id. The limited behavioral information is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very short and uses a clear list for arguments. Every sentence is meaningful, though the structure could be improved by separating the purpose statement from the arguments more formally.
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 (2 params, no nested objects) and the presence of an output schema (which documents return values), the description is sufficient. It covers the tool's purpose and parameters, leaving details about return structure to the output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/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 add meaning. It explains session_id as 'Session ID from open_workbook (required)' and include_ranges as 'Whether to include range information', adding context beyond the schema fields. However, it does not specify what range information entails or the format required for session_id.
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 gets workbook metadata including sheets and ranges, using specific verb 'Get' and resource 'workbook metadata'. It distinguishes itself from sibling tools (e.g., read_data_from_excel, validate_excel_range) by focusing on overall workbook structure.
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 by requiring a session_id from open_workbook, but it does not explicitly state when to use this tool versus alternatives, nor does it provide 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.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description lacks details on behavioral traits such as what happens if cells are not merged, whether it modifies the workbook, or required permissions. Minimal disclosure beyond 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?
Extremely concise: one-line purpose, parameter list, and a note. No redundant text. Front-loaded with the action.
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?
Covers purpose and parameter purposes, but lacks behavioral context, error conditions, or what happens on success. Output schema exists but not detailed in description. Adequate for a simple mutation tool.
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?
Adds meaning beyond the schema by listing parameters with brief explanations and a note about preferring session_id. However, does not specify cell reference format (e.g., 'A1' style). Schema coverage is 0%, so description compensates well.
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?
Description clearly states 'Unmerge a range of cells', providing a specific verb and resource. It naturally distinguishes from sibling tool '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 Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives. Only provides parameter preference advice (session_id over filepath), not tool selection context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist. The description focuses on parameters but does not disclose behavioral traits such as whether the tool modifies the workbook, error handling, or performance implications. It only mentions deprecation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, with the main purpose front-loaded. The parameter list and note are clear, though a more structured format could improve readability.
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?
An output schema exists, so return values need not be described. However, the description lacks behavioral context (e.g., what happens on invalid range or missing sheet) and does not cover all aspects for a creation tool.
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?
With 0% schema description coverage, the description adds meaning by explaining each parameter (e.g., 'Name of worksheet', 'Range of data to create table from'). It notes session_id is preferred and filepath deprecated, adding value beyond 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 verb 'Creates' and the resource 'native Excel table from a specified range of data.' It distinguishes from sibling tools like create_chart or create_pivot_table.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides parameter context and notes session_id as preferred over deprecated filepath, but does not explicitly state when to use this tool versus 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?
No annotations exist, so the description must fully disclose behavior. It mentions 'force close' and 'without saving', but does not explicitly warn that unsaved changes will be lost. For a simple tool, this is adequate but not thorough.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is very concise with a single core sentence and structured Args/Returns. The Args line is redundant given the schema, but overall it is well-structured and 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 one-parameter tool with an output schema, the description covers the essential purpose, parameter, and return. It lacks guidance on when to use this over 'close_workbook' and a warning about data loss, but is largely complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description says 'Path to the workbook to force close', which adds minimal meaning beyond the schema's type 'string'. With 0% schema description coverage, more detail (e.g., format, requirement that workbook is open) would be expected.
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 verb 'force close', the resource 'workbook', and the key qualifier 'by file path (without saving)'. This distinguishes it from sibling 'close_workbook' which likely saves changes.
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 when you want to discard changes by saying 'without saving', but it does not explicitly contrast with 'close_workbook' or provide when-not-to-use guidance. No alternatives are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must disclose all behavioral traits. It only states that the tool returns a JSON string of validation rules, but does not mention side effects (e.g., read-only, no modifications), required permissions, or error conditions. This leaves significant gaps for a read operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is reasonably concise, but the Args section redundantly lists parameters already in the schema. The core purpose is front-loaded. Some words could be trimmed without loss.
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 (3 parameters, output schema exists), the description covers the essential purpose and key parameter guidance. The return type is stated, though the output schema itself provides more detail. Missing behavioral transparency is the main gap.
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 adds value by noting that session_id is preferred for better performance and filepath is deprecated, which goes beyond the schema's type information. However, it does not describe the format of sheet_name or any constraints.
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 'Get all data validation rules in a worksheet' with additional context about identifying ranges and validation types. This verb+resource combination is specific and distinct from sibling tools like validate_excel_range.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage by explaining what the tool does, but does not explicitly state when to use it over alternatives like validate_excel_range or validate_formula_syntax. No exclusions or context for when-not-to-use are provided.
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 provided, and description omits behavioral details such as side effects of closure, behavior on invalid session ID, or whether the operation is reversible.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is short and efficient, using a single line for purpose and separate lines for args and returns 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?
Adequate for a simple close operation given an output schema exists, but lacks guidance on error handling or prerequisites for use.
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?
With 0% schema description coverage, description clarifies each parameter: session_id is 'Session ID from open_workbook' and save is 'Whether to save changes (default: True)', adding essential 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?
Description clearly states 'Close a workbook session', specifying the verb 'close' and resource 'workbook session', which is distinct from siblings like 'open_workbook' or 'force_close_workbook_by_path_tool'.
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?
Implies usage after open_workbook, but does not explicitly mention prerequisites or contrast with alternatives like force_close for handling stalled sessions.
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 full behavioral transparency. It does not state side effects like shifting existing rows, impact on merged cells or formatting, or any performance considerations. The agent lacks key behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with a clear purpose sentence, a list of arguments, and a brief note. Every sentence adds value with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers purpose and parameters adequately, but lacks behavioral context (see transparency) and usage guidelines. With an output schema existing, return values are not needed, but the tool's impact is insufficiently described.
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?
Despite 0% schema coverage, the description explains each parameter's role (e.g., 'Number of rows to insert' for count) and notes deprecation of filepath. This adds significant meaning beyond the schema types.
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 'Insert one or more rows starting at the specified row.' This uses a specific verb and resource, and distinguishes the tool from siblings like insert_columns or delete_sheet_rows.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description recommends using session_id over filepath for better performance, but does not provide explicit when-to-use or when-not-to-use guidance relative to other tools. No exclusions or alternatives 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?
With no annotations, the description must carry the full burden. It states the core behavior (validate without applying) and mentions parameter preferences, but does not disclose what happens on invalid syntax (e.g., error or return value) or whether the tool modifies anything (it doesn't, but that's implied).
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 with a front-loaded main sentence and a well-structured parameter list using clear labels and a note. Every sentence adds value, and there is no wasted text.
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?
Given the tool complexity (5 parameters, sibling tools, and an output schema exists), the description covers the purpose and parameters adequately but misses context like prerequisites (e.g., workbook must be open) or edge-case behavior. It is minimally complete but not rich.
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 schema has no parameter descriptions (0% coverage), but the description adds meaningful context: sheet_name is a worksheet name, cell is an address like 'A1', formula is to validate, session_id from open_workbook is preferred, and filepath is deprecated. This compensates well for the schema gap.
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 'Validate Excel formula syntax without applying it,' which clearly identifies a specific verb (validate) and resource (Excel formula syntax). It also distinguishes itself from sibling tools like 'apply_formula' by noting it does not apply the formula.
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?
The description provides no guidance on when to use this tool versus alternatives, such as when to validate syntax vs. apply a formula or other operations. The note about session_id vs filepath is about parameter preference, not tool selection.
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 fails to mention what happens on overwrite, formatting preservation, or side effects, focusing only on parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured with a purpose line, Args list, and note, though the note could be integrated for brevity.
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?
Given the tool's complexity and the presence of an output schema, the description covers parameters adequately but misses prerequisites (e.g., workbook must be open) and edge cases.
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 coverage is 0%, but the description provides brief explanations for each parameter (e.g., 'Name of source worksheet'), adding meaning beyond the schema titles.
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 ('Copy a range of cells to another location') with a specific verb and resource, distinguishing it from sibling tools like delete_range or format_range.
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 includes a note on preferring session_id over deprecated filepath, providing context for parameter choice, but does not explicitly state when to use this tool versus alternatives or exclude scenarios.
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 it lists open sessions, with no mention of behavioral traits like permissions, side effects, or performance implications. For a read-only list operation, this is minimal but not harmful.
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 with two sentences, no redundant information, and the key action is stated first. Every sentence adds value.
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 tool with no parameters and an output schema, the description sufficiently explains the purpose and return type. No additional context is needed.
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?
There are zero parameters, so the description need not add parameter details. The baseline score of 4 is appropriate as there is nothing missing.
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 it lists all open workbook sessions, using a specific verb ('list') and resource ('open workbook sessions'). It distinguishes from other sibling tools that create, close, or modify workbooks.
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?
No explicit guidance on when or when not to use this tool versus alternatives. However, since it's the only list tool among siblings, the usage is implied. A score of 3 reflects the lack of explicit context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It implies a read-only operation ('Get') but does not explicitly confirm no side effects, mention permissions, or error cases. The parameter note adds some context but overall transparency is limited.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with a clear first sentence stating purpose, followed by parameter explanations in a list. The note is relevant and placed at the end. Slightly more could be trimmed, but overall efficient.
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?
Given the output schema exists (not shown), description need not detail return values. However, it lacks prerequisites such as requiring an open workbook or valid worksheet name. For a simple getter with three parameters, the description is adequate but could be more complete about tool usage context.
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 adds significant meaning by explaining each parameter's purpose: sheet_name as worksheet name, session_id as preferred from open_workbook, and filepath as legacy deprecated. This goes beyond the schema's name and type.
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?
Description clearly states 'Get merged cells in a worksheet' with specific verb and resource. It distinguishes from siblings like 'merge_cells' and 'unmerge_cells' which perform different actions.
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 guidance on parameter usage, recommending session_id over the deprecated filepath. However, it does not explicitly state when to use this tool versus alternatives, though the purpose is clear enough for a simple getter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool reads data without mutation, but lacks details on side effects, concurrency behavior, or performance implications. Basic transparency is present but incomplete.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two introductory sentences and a well-structured parameter list. No redundant information, and each part contributes to understanding the tool's usage.
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 has an output schema, the description does not need to detail return values. However, it could be more complete by explaining what cell metadata includes or how preview_only affects the output. Overall, it sufficiently covers the main aspects.
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 coverage is 0%, so the description adds value by explaining each parameter's role, including defaults (start_cell=A1), auto-expansion for end_cell, and the preview_only boolean. This goes beyond the schema's type-only information.
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 data from an Excel worksheet with cell metadata including validation rules. This distinguishes it from sibling tools like get_data_validation_info or validate_excel_range by focusing on data reading with metadata.
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 parameter descriptions but does not explicitly state when to use this tool versus alternatives like validate_excel_range or get_workbook_metadata. No exclusion criteria or when-not-to-use guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the behavioral disclosure burden. It notes that session_id is preferred over filepath (deprecated), explains auto-creation of target_sheet, auto-finding of target_cell, and auto-generation of pivot_name. However, it does not explicitly state that this operation modifies the workbook or require permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured as a clear bullet list with each parameter explained in one line. It is concise without fluff, though the 'Args:' prefix is slightly redundant. Still well-organized and 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 11 parameters, 4 required, no annotations, and an output schema exists, the description covers all parameter behaviors adequately. It does not explain return values, but that is mitigated by the output schema presence.
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 explains each parameter's meaning, including optionality, defaults, deprecation of filepath, and examples for data_range. This is critical value-added 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 explicitly states 'Create pivot table in worksheet', a specific verb-resource combination. It distinguishes from sibling tools like create_chart and create_table by focusing on pivot table creation.
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 provides parameter explanations but no explicit guidance on when to use this tool versus alternatives like create_table or apply_formula. Usage context is implied by the parameter list, but no when-not-to-use or prerequisite conditions are mentioned.
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:

[![xlwings-mcp-server MCP server](https://glama.ai/mcp/servers/fastmcp-me/xlwings-mcp-server/badges/card.svg)](https://glama.ai/mcp/servers/fastmcp-me/xlwings-mcp-server)

Score Badge

Copy to your README.md:

[![xlwings-mcp-server MCP server](https://glama.ai/mcp/servers/fastmcp-me/xlwings-mcp-server/badges/score.svg)](https://glama.ai/mcp/servers/fastmcp-me/xlwings-mcp-server)

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/fastmcp-me/xlwings-mcp-server'

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