This server enables real-time interaction with live Microsoft Excel instances on macOS, allowing AI agents to read, write, and manipulate spreadsheet data and execute macros directly — locally, with no API keys required.
List open workbooks — view all currently open Excel files, including names, paths, and sheet counts
Get sheet names — retrieve all sheet names from a specific or active workbook
Read a cell range — read a rectangular range (e.g. A1:D20) as a 2D array, with optional auto-expansion to contiguous data
Write a range — write a 2D array of data starting from a specified cell; changes appear instantly in Excel
Write a single cell — write a value, number, or formula (e.g. =SUM(A1:A10)) to one cell
Read a single cell — read the value and formula of a specific cell
Open a workbook — open an Excel file from a given path, launching Excel if needed
Save a workbook — save the active or specified workbook in place or to a new path
Run a VBA macro — execute an existing VBA macro in the active workbook, optionally passing arguments
Get current selection — retrieve the address, values, and sheet of the user's currently selected range
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@excel-live-mac read the current selection in the active sheet"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Live Excel MCP server for macOS — interact with running Excel instances in real time.
Unlike file-based tools (openpyxl) that work on saved files offline, this server talks to the live Excel app via the xlwings AppleScript bridge. Changes appear instantly in the spreadsheet you're looking at.
10 tools for reading, writing, and interacting with open Excel workbooks
Real-time updates — write data and watch it appear in Excel immediately
Formula support — write Excel formulas that calculate live
VBA macro execution — trigger existing macros from your AI agent
Selection awareness — read what the user currently has highlighted
Zero config — no API keys, no network, runs entirely local
Related MCP server: SheetForge MCP
macOS (AppleScript bridge — not available on Windows/Linux)
Microsoft Excel installed
Python 3.10+
Import from GitHub in the Kiro Powers panel:
https://github.com/dcol3/excel-live-macuvx --from git+https://github.com/dcol3/excel-live-mac excel-live-macOr add to your MCP config:
{
"mcpServers": {
"excel-live-mac": {
"command": "uvx",
"args": ["--from", "git+https://github.com/dcol3/excel-live-mac", "excel-live-mac"],
"disabled": false
}
}
}pip install excel-live-mac
excel-live-macOn first use, macOS will prompt you to allow your terminal to control Microsoft Excel.
Go to System Settings → Privacy & Security → Automation and ensure your terminal/IDE has permission to control Excel.
Tool | Description |
| List all open workbooks (name, path, sheets) |
| Get sheet names from a workbook |
| Read a cell range as a 2D array |
| Write a 2D array (appears instantly) |
| Write a value or formula to one cell |
| Read one cell's value and formula |
| Open a file in Excel |
| Save the workbook |
| Execute a VBA macro |
| Get the current selection |
Report generation — AI builds formatted spreadsheets while you watch
Financial modeling — populate budgets, forecasts, and scenario tables live
Data entry automation — read from databases, write directly into open workbooks
Interactive analysis — AI reads your current selection, computes, writes results back
This repo includes a kiro_power/ directory with POWER.md, mcp.json, and steering files for use as a Kiro Power. When installed as a Power, Kiro's agent automatically knows when and how to use these tools based on keyword activation.
MIT
Get info about the currently selected range in Excel (address, values, sheet).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It does not disclose prerequisites (e.g., Excel must be open with a selection), side effects (none expected), or behavior when no selection exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One sentence with no extraneous information. Front-loads the action and includes parenthetical detail. Every part is necessary.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read tool, the description covers the main outputs. However, it lacks details on the format of 'values' (e.g., array of arrays) and what happens if no selection or multiple selections.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters, and schema coverage is effectively 100%. The description adds value by listing the output fields (address, values, sheet) beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action (get info), resource (currently selected range), and specifies the types of info (address, values, sheet). It distinguishes from siblings like excel_read_range which requires a range parameter.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like excel_read_range or excel_get_sheet_names. It is implied but not stated that this tool is for the current selection without specifying parameters.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get all sheet names from an open workbook.
| Name | Required | Description | Default |
|---|---|---|---|
| workbook | No | Workbook name (or empty for active) |
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 it works on an 'open workbook', implying the workbook must be already opened via other tools, but does not disclose behavior for invalid workbooks or error cases. It is accurate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single sentence of 9 words that is efficient, front-loaded, and contains every word is necessary. No wasted text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description is adequate but lacks details about the return format (e.g., list of strings) or error handling when no workbook is open. More context would improve agent decision-making.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with 'Workbook name (or empty for active)' for the single parameter. The tool description adds no additional meaning beyond the schema, so a baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'Get all sheet names' and the resource 'from an open workbook', which is specific and distinguishes this tool from siblings like 'excel_get_selection' and 'excel_list_workbooks'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, such as when to use 'excel_list_workbooks' instead. The description only states what it does without any context on prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all currently open workbooks in Excel. Shows name, path, and sheet count.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It correctly indicates a read-only listing operation. However, it does not clarify what happens if no workbooks are open (empty list vs. error) or that Excel must be open, which are relevant behavioral details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that immediately conveys the action and output. Every word is functional, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description is largely complete. It covers the listing action and the data returned. However, it lacks error handling details (e.g., if Excel is not running) which would be beneficial for completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has no parameters, so the description adds value by specifying the output fields (name, path, sheet count). This provides meaning beyond the empty input schema. Baseline for zero parameters is 4, and the description meets that expectation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and resource 'workbooks', clearly stating that it lists open workbooks and shows name, path, and sheet count. This differentiates it from sibling tools like excel_get_sheet_names (lists sheets) and excel_open_workbook (opens a workbook).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when the agent needs to know which workbooks are currently open in Excel. However, it does not explicitly state when to use this tool versus alternatives, nor does it provide exclusions or prerequisites (e.g., Excel must be running).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Open a workbook file in Excel. Launches Excel if not running.
| Name | Required | Description | Default |
|---|---|---|---|
| file_path | Yes | Absolute path to .xlsx/.xlsm/.xls file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral burden. It discloses the side effect 'Launches Excel if not running,' but it fails to mention other important behaviors such as what happens if the file is already open, error handling for missing files, or whether the workbook becomes the active window.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise, consisting of two succinct sentences. It is front-loaded with the primary action and adds the key side effect in the second sentence with no unnecessary wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although the schema fully describes the parameter, the description lacks crucial context such as what the tool returns (if anything), how it relates to sibling tools (e.g., after opening, use other tools to manipulate the workbook), and error handling. This incompleteness can confuse an agent about the workflow.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage for the single parameter 'file_path' is 100%, fully describing it as an absolute path to .xlsx/.xlsm/.xls files. The tool description adds no additional meaning beyond the schema, so the baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Open a workbook file') and the resource ('workbook file'). It also mentions the side effect of launching Excel if not running. Among sibling tools like excel_read_cell and excel_save_workbook, this tool's purpose is distinct and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool versus alternatives, such as excel_list_workbooks for already opened files or excel_save_workbook for saving. There is no mention of prerequisites (e.g., ensure file exists) 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.
Read the value of a single cell.
| Name | Required | Description | Default |
|---|---|---|---|
| workbook | No | ||
| sheet | No | ||
| cell | Yes | Cell address like 'B5' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It mentions 'read' (non-mutating) but lacks specifics on return format (value, formula, error handling) and prerequisites (e.g., open workbook).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, entirely front-loaded. Every word is necessary; no extraneous content.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema and 10 sibling tools, the description is too minimal. It omits return type, error conditions, and dependency on an open workbook. A simple operation but missing useful context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 33%, with only 'cell' having a description. The description does not elaborate on 'workbook' or 'sheet' parameters, failing to compensate for the low coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Read the value of a single cell,' providing a specific verb and resource. It distinguishes from sibling excel_read_range which reads multiple cells.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like excel_read_range or excel_get_selection. Usage context is implied by the name and minimal description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read a range from an open workbook. Returns cell values as a 2D array.
| Name | Required | Description | Default |
|---|---|---|---|
| workbook | No | Workbook name (or empty for active) | |
| sheet | No | Sheet name (or empty for active sheet) | |
| range | Yes | Cell range like 'A1:D20', 'B:B', or 'A1' | |
| expand | No | Auto-expand to contiguous data region from top-left cell |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. Mentions 'open workbook' as prerequisite and that it's read-only (returns values). Discloses output format but lacks details on error handling, locks, or permissions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero wasted words. Front-loaded with action and output. Efficiently communicates core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read tool with 4 params and no output schema, description adequately covers input (range, workbook, sheet, expand) and output (2D array). Could mention that active workbook/sheet is used when empty, but that's in schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers all parameters (100%). Description adds value by specifying output format (2D array) and purpose of 'expand' parameter (auto-expand to contiguous data). Exceeds baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states action ('Read'), resource ('range from an open workbook'), and output ('Returns cell values as a 2D array'). Distinguishes from siblings like excel_read_cell (single cell) and excel_write_range (write).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when or when not to use this tool versus alternatives. Usage is implied by the tool's purpose, but no exclusions or context provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a VBA macro in the active workbook. Macro must already exist in the workbook.
| Name | Required | Description | Default |
|---|---|---|---|
| workbook | No | ||
| macro | Yes | Macro name (e.g. 'Sheet1.MyMacro' or just 'MyMacro') | |
| args | No | Arguments to pass to the macro |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses minimal behavior: it runs a macro that must exist. Missing critical context like security implications, side effects, error handling, or that it might modify the workbook.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is very short (two sentences) with no wasted words. However, it could benefit from more information without being verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, no annotations, and the complexity of running macros (which can affect workbook state and security), the description is insufficiently complete. It omits return value, error conditions, and prerequisites beyond existence.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 67%, but description adds no new meaning beyond schema. It states 'active workbook' but schema includes a 'workbook' parameter, introducing potential confusion. The description does not clarify the purpose of each parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Run' and the resource 'VBA macro in the active workbook'. It distinguishes this tool from sibling Excel tools which handle selection, reading, writing, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for running macros and includes a prerequisite ('Macro must already exist'), but provides no guidance on 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.
Save the specified (or active) workbook.
| Name | Required | Description | Default |
|---|---|---|---|
| workbook | No | Workbook name (or empty for active) | |
| path | No | Save-as path (empty = save in place) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must fully disclose behavior. It does not mention overwrite behavior, error handling, or whether the workbook is saved in place or as a copy. 'Save' implies mutation but lacks key details.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no redundant words. Front-loaded with verb and resource. Slightly more context (e.g., overwrite behavior) would not hurt conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with two optional parameters and no output schema, the description is adequate. However, it lacks behavioral hints like overwrite confirmation or file creation behavior that would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. The description adds value by clarifying that empty workbook means active and empty path means save in place. This directly addresses ambiguity in the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool saves a workbook, specifying it can be the active or named workbook. This is distinct from sibling tools which are for opening, reading, writing, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives, no prerequisites, and no conditions for using the path parameter. The description is purely functional.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Write a single value to a specific cell. Change appears immediately.
| Name | Required | Description | Default |
|---|---|---|---|
| workbook | No | ||
| sheet | No | ||
| cell | Yes | Cell address like 'B5' | |
| value | Yes | Value to write (string, number, or formula starting with =) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries full behavioral burden. It adds that the change appears immediately, which is useful, but does not disclose overwrite behavior (destructive), permissions, or undo capabilities. The schema already hints at formula support in 'value' description.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with no wasted words. The purpose and an immediate behavioral trait are front-loaded. Highly concise and efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no output schema, and no annotations, the description is minimal. It lacks details on prerequisites (e.g., workbook must be open), overwrite behavior, and return value. An agent would need to infer or guess critical usage context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 50% (only 'cell' and 'value' have descriptions). The description does not add meaning for the undocumented parameters 'workbook' and 'sheet', nor does it clarify their role or defaults. No parameter semantics beyond what schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'write' and resource 'cell', specifies 'single value', and adds 'change appears immediately.' This distinguishes it from sibling tools like excel_write_range (writes multiple cells) and excel_read_cell (reads).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use for single cell writes but does not explicitly mention when to use alternatives like excel_write_range for multiple cells or excel_read_cell for checking existing values. No '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.
Write a 2D array of data to a range in an open workbook. Changes appear immediately in Excel.
| Name | Required | Description | Default |
|---|---|---|---|
| workbook | No | Workbook name (or empty for active) | |
| sheet | No | Sheet name (or empty for active sheet) | |
| range | Yes | Top-left cell to start writing, e.g. 'A1' or 'B5' | |
| data | Yes | 2D array of values (rows of columns) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry full behavioral transparency. It only states 'Changes appear immediately in Excel.' It does not disclose destructive behavior (overwriting), error conditions (invalid range, missing workbook), or data type handling. This is insufficient for safe agent use.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is efficient with two sentences. The first sentence states purpose, the second adds a key behavioral note. No extraneous content, but could be more informative without harming conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (writing to Excel), the description is somewhat sparse. It lacks context on error states, data type expectations, and limits. However, it provides a clear core purpose and immediate effect, meeting minimum viability.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
All parameters are described in the schema (100% coverage). The tool description does not add additional meaning beyond '2D array of data to a range'. No examples or constraints are provided. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Write a 2D array of data') and the resource ('to a range in an open workbook'), with a behavioral note. It distinguishes from siblings like excel_read_range and excel_write_cell.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives. The description does not mention prerequisites, limitations, or when-not scenarios. For instance, it doesn't clarify that the workbook must already be open or when to use excel_write_cell instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0excel_get_selectionexcel_get_sheet_namesexcel_list_workbooksexcel_open_workbookexcel_read_cellexcel_read_rangeexcel_run_macroexcel_save_workbookexcel_write_cellexcel_write_rangeEach tool targets a distinct action: reading/writing cells vs ranges, listing sheets, managing workbooks, running macros. No overlapping purposes; descriptions clearly differentiate them.
All tools share the 'excel_' prefix and follow a consistent verb_noun pattern (e.g., read_cell, write_range, open_workbook), making it easy to infer functionality.
With 10 tools, the server covers essential Excel operations without being bloated or sparse. Each tool serves a clear need.
Basic CRUD on cells/ranges and workbook listing/saving are covered, but missing features like creating workbooks, managing sheets, closing workbooks, or formatting leave notable gaps for full automation.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
An MCP server that provides read access to your cloud storage providers, bank accounts and more.
Open-source MCP server for Zerodha Kite Connect. Portfolio, market data, backtesting, alerts.
Token-free MCP server for structured RevoGrid Core, Pro, and Enterprise knowledge retrieval.
MCP Server for Slima - AI Writing IDE for Novel Authors with AI Beta Reader.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/dcol3/excel-live-mac'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
