Excel Analytics MCP Server

by blakethom8

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.1.3
Disambiguation3/5
The tools have some clear distinctions, but there is notable overlap between create_tool, save_analysis, and edit_tool, which all involve managing custom tools or analyses, potentially causing confusion. Other tools like describe_dataset and summarize serve distinct purposes, but the tool management cluster lacks clear boundaries.
Naming Consistency4/5
Most tools follow a consistent verb_noun pattern (e.g., create_tool, delete_tool, list_datasets), with only minor deviations like 'query' and 'summarize' being single words. Overall, the naming is readable and predictable, though not perfectly uniform.
Tool Count5/5
With 10 tools, the count is well-scoped for an Excel analytics server, covering data exploration, querying, and custom tool management. Each tool appears to serve a specific role without obvious bloat or redundancy.
Completeness4/5
The toolset covers core analytics workflows: data inspection (list_datasets, describe_dataset, summarize), querying (query), and custom tool lifecycle (create, edit, delete, test, list). A minor gap is the lack of data manipulation tools (e.g., update or insert), but this is reasonable for a read-focused analytics server.
Average 3.2/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.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, so the description carries the full burden of behavioral disclosure. While 'Update' implies a mutation operation, the description doesn't specify required permissions, whether changes are reversible, potential side effects, or response format. For a mutation tool with zero annotation coverage, this leaves significant gaps in understanding its behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse quickly. Every word earns its place by conveying essential information.
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 complexity (mutation tool with 6 parameters), lack of annotations, and 0% schema description coverage, the description is insufficiently complete. While an output schema exists (which helps with return values), the description doesn't address behavioral aspects, parameter meanings, or usage context needed for proper tool invocation.
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%, meaning none of the 6 parameters have descriptions in the schema. The tool description doesn't add any parameter-specific information beyond what's implied by the action ('Update'), failing to compensate for the lack of schema documentation. Parameters like 'sql_template' and 'python_code' remain unexplained in both schema and description.
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 ('Update') and the resource ('an existing saved analysis or custom tool'), providing a specific verb+resource combination. However, it doesn't explicitly distinguish this from sibling tools like 'create_tool' or 'test_tool', which would require mentioning creation vs. modification or testing vs. editing.
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 doesn't mention prerequisites (e.g., needing an existing tool ID), exclusions (e.g., not for creating new tools), or direct comparisons to siblings like 'create_tool' or 'delete_tool'. Usage is implied but not explicitly stated.
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 full burden but only mentions sandboxed execution. It doesn't disclose important behavioral aspects like permissions needed, whether the tool is idempotent, error handling, rate limits, or what happens when creating duplicate tools. The sandbox hint is useful but 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?
Two sentences that are reasonably efficient. The first sentence states the core purpose and key requirements. The second provides specific format guidance for the parameters field. Could be slightly more front-loaded but wastes no 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 this is a creation tool with 4 parameters, 0% schema coverage, no annotations, but has an output schema, the description is minimally adequate. It covers the basic what and how-to-format parameters, but lacks important context about permissions, error conditions, and relationship to sibling tools. The output schema existence helps but doesn't compensate for missing behavioral 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?
Schema description coverage is 0%, so the description must compensate. It explains the parameters field format with a JSON string example showing structure, but doesn't clarify the purpose of name, description, or python_code parameters beyond what the schema titles suggest. The example adds some value but doesn't fully explain all 4 parameters.
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 custom Python tool with sandboxed execution, specifying the required run() function signature. It distinguishes from siblings like delete_tool or edit_tool by focusing on creation, though it doesn't explicitly contrast with test_tool or list_my_tools.
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 edit_tool or test_tool. The description mentions the code structure but doesn't provide context about prerequisites, typical use cases, or when other tools might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions saving as reusable, implying a write operation, but fails to detail permissions, side effects, error handling, or response behavior. This is inadequate for a tool that likely modifies state, as it lacks critical operational context.
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 brief but front-loaded with the main purpose. The second sentence provides a parameter example, which is useful but could be more integrated. It avoids redundancy but feels slightly fragmented, with room for improvement in flow and efficiency.
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 parameters with 0% schema coverage and no annotations, the description partially compensates with parameter guidance but lacks behavioral details. The presence of an output schema reduces the need to explain return values, but overall completeness is moderate due to gaps in usage and transparency for a state-modifying tool.
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 compensate. It provides an example for the 'parameters' field, clarifying it should be a JSON string with specific structure, which adds value beyond the bare schema. However, it does not explain the semantics of 'name', 'description', or 'sql_template', leaving three parameters partially undocumented.
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 ('Save a SQL template') and the outcome ('as a reusable named tool'), which is specific and understandable. It distinguishes from siblings like 'create_tool' by specifying SQL templates, though not explicitly contrasting with other tools. However, it's not tautological and provides a clear purpose.
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 offers no guidance on when to use this tool versus alternatives like 'create_tool' or 'edit_tool', nor does it mention prerequisites or exclusions. It implies usage for saving SQL templates but lacks explicit context or comparisons, leaving the agent to infer usage 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?
With no annotations provided, the description carries full burden for behavioral disclosure. While 'Quick statistical summary' implies a read-only operation, it doesn't specify what statistics are included, whether it handles missing data, what format the output takes, or any performance considerations. The description is too vague about the actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise at 8 words with zero wasted language. It's front-loaded with the core functionality ('Quick statistical summary') and efficiently specifies the scope ('of a table or a specific column'). Every word earns its place.
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 an output schema (which will document return values) and relatively simple parameters, the description is minimally adequate. However, for a statistical summary tool with no annotations, it should provide more context about what statistics are computed, handling of different data types, or sample output format to complement the output schema.
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?
With 0% schema description coverage for both parameters, the description must compensate but provides minimal help. It mentions 'table or a specific column' which hints at the two parameters' purposes, but doesn't explain the relationship between them, what happens when column is empty vs specified, or what constitutes valid table/column values.
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's purpose with specific verbs ('statistical summary') and resources ('table or a specific column'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'describe_dataset' or 'query', which might also provide summary-like functionality.
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. With siblings like 'describe_dataset' and 'query' that might offer overlapping functionality, there's no indication of when this specific summary tool is preferred or what distinguishes it from other analysis options.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action is 'Remove,' implying a destructive mutation, but doesn't specify if deletion is permanent, reversible, requires specific permissions, or has side effects (e.g., affecting saved analyses). This leaves critical behavioral traits unclear for a destructive operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero wasted words. It's front-loaded with the core action and target, making it easy to parse. Every word earns its place by conveying essential purpose without redundancy or fluff.
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 destructive nature, no annotations, and an output schema (which handles return values), the description is minimally complete. It states what the tool does but lacks context on permissions, irreversibility, or error conditions. For a delete operation, this leaves gaps that could lead to misuse, though the output schema mitigates some uncertainty.
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 adds no parameter information beyond what the schema provides. With 0% schema description coverage and 1 parameter ('tool_id'), the schema alone documents it as a required string. The description doesn't explain what a 'tool_id' is, how to obtain it, or its format. However, since there's only one parameter and the baseline is 3 when schema coverage is high, this minimal case scores adequately but not informatively.
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 ('Remove') and target ('a user-created tool'), making the purpose immediately understandable. It distinguishes itself from siblings like 'create_tool' and 'edit_tool' by specifying deletion. However, it doesn't explicitly mention what 'user-created' means or differentiate from other deletion-like operations that might exist.
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 doesn't mention prerequisites (e.g., needing the tool_id from 'list_my_tools'), exclusions (e.g., cannot delete system tools), or related workflows (e.g., use 'create_tool' to make new ones). The agent must infer usage from the name and sibling tools alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions that the tool 'return results', which hints at a read operation, but doesn't specify if it's read-only, has side effects, requires permissions, or handles errors. For a tool that runs other tools, this lack of detail on behavior 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded, consisting of two sentences that directly state the tool's purpose and parameter format. There is no wasted text, and every sentence earns its place by providing essential information efficiently.
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 (running other tools with parameters), the lack of annotations, and the presence of an output schema, the description is minimally adequate. It covers the basic purpose and parameter format, but doesn't address behavioral aspects like side effects or error handling. The output schema likely handles return values, so the description doesn't need to explain those, but it should do more to guide usage and transparency.
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 adds some meaning beyond the input schema by explaining that 'params should be a JSON string of the parameters to pass.' This clarifies the format and purpose of the 'params' parameter, which the schema only labels as 'Params' with a default. However, with 0% schema description coverage and 2 parameters, it doesn't fully compensate for the lack of schema details, such as what 'tool_id' represents or example usage.
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's purpose: 'Run a tool with given parameters and return results.' This specifies the verb ('Run') and resource ('a tool'), making it understandable. However, it doesn't distinguish this from sibling tools like 'create_tool' or 'edit_tool', which might also involve tool operations, so it's not fully differentiated.
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 doesn't mention any context, prerequisites, or exclusions, such as how it differs from direct tool invocation or other sibling tools like 'query' or 'save_analysis'. This leaves the agent without clear usage instructions.
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 implies a read-only operation by describing data, but doesn't disclose behavioral traits such as permissions needed, rate limits, error handling, or whether it's safe for large tables. This is a significant gap for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded in a single, efficient sentence. Every word contributes to explaining the tool's purpose without waste, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter) and the presence of an output schema, the description is reasonably complete. It outlines what the tool returns (column names, types, etc.), and the output schema can handle details, though more behavioral context would improve it for a tool with no annotations.
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 doesn't add meaning beyond the input schema, which has 0% description coverage for the single parameter 'table'. However, the parameter is straightforward (a table name), and with only one parameter, the baseline is 3 as the description doesn't compensate but the simplicity mitigates the impact.
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 what the tool does: provides column names, types, sample values, and basic stats for a table. It uses specific verbs ('describe') and resources ('table'), though it doesn't explicitly distinguish from siblings like 'list_datasets' or 'summarize' which might have overlapping functionality.
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. The description doesn't mention prerequisites, context, or exclusions, and with siblings like 'list_datasets', 'summarize', and 'query', the agent lacks direction on selecting this specific tool for dataset description tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'shows' tools, implying a read-only operation, but doesn't mention permissions, pagination, sorting, or what the output includes (e.g., tool metadata). This leaves gaps for a tool with output schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's function without unnecessary words. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 an output schema and no parameters, the description covers the basic purpose adequately. However, with no annotations and sibling tools present, it lacks context on usage scenarios and behavioral details, making it minimally viable but incomplete for optimal agent guidance.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description appropriately doesn't discuss parameters, focusing on the tool's purpose instead, which aligns with the baseline for zero parameters.
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 verb 'Show' and the resource 'all user-created tools', specifying they include 'saved analyses and custom tools'. It distinguishes from generic listing by focusing on user-created content, though it doesn't explicitly differentiate from sibling tools like 'list_datasets'.
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 'list_datasets' or 'describe_dataset'. The description implies it's for viewing user-created tools but offers no context about prerequisites, timing, or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It mentions the tool shows row/column counts, which adds some behavioral context, but lacks details on permissions needed, whether it's read-only (implied but not stated), response format, or any limitations (e.g., pagination).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose ('Show all loaded tables') and adds useful detail ('with row/column counts') without any wasted words. Every part earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 0 parameters, 100% schema coverage, and an output schema exists (so return values are documented elsewhere), the description is reasonably complete. It covers the basic purpose and output metadata, though it could benefit from more behavioral context (e.g., read-only nature) since annotations are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add parameter info, which is appropriate, earning a baseline 4 for adequately handling the lack of parameters.
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 ('Show all loaded tables') and the resource ('tables'), making the purpose evident. It distinguishes from siblings like 'describe_dataset' (detailed info on one table) and 'query' (executing queries), but doesn't explicitly contrast with 'list_my_tools' (which lists tools, not datasets).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for viewing loaded datasets with basic metadata, but provides no explicit guidance on when to use this versus alternatives like 'describe_dataset' (for detailed info on a specific dataset) or 'query' (for data exploration). No exclusions or prerequisites are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behavioral traits: the operation is read-only (implying no data modification), restricts query types to SELECT (preventing mutations), and implies database interaction. However, it doesn't mention potential limitations like query timeouts, result size limits, or authentication requirements.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place: the first states the core purpose, the second adds critical restriction. It's front-loaded with essential information and contains zero wasted words.
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 moderate complexity (SQL execution), no annotations, and the presence of an output schema (which handles return values), the description is reasonably complete. It covers the core purpose, restrictions, and basic usage context. However, for a database query tool, additional context about result formats, error handling, or connection details would be helpful.
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 schema provides no parameter documentation. The description adds some context by implying the 'sql' parameter should contain a SELECT query, but doesn't specify syntax requirements, supported SQL dialects, or parameterization options. This provides basic meaning but leaves significant gaps.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verb ('run') and resource ('SQL query against the database'), and distinguishes it from siblings by specifying 'read-only' and 'Only SELECT queries allowed', which differentiates it from mutation tools like create_tool or delete_tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('run a read-only SQL query') and when not to use it ('Only SELECT queries allowed'), providing clear alternatives for other operations (e.g., use create_tool for INSERT, delete_tool for DELETE). This gives the agent precise guidance on tool selection.
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:

[![excel-mcp MCP server](https://glama.ai/mcp/servers/blakethom8/excel-mcp/badges/card.svg)](https://glama.ai/mcp/servers/blakethom8/excel-mcp)

Score Badge

Copy to your README.md:

[![excel-mcp MCP server](https://glama.ai/mcp/servers/blakethom8/excel-mcp/badges/score.svg)](https://glama.ai/mcp/servers/blakethom8/excel-mcp)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/blakethom8/excel-mcp'

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