Skip to main content
Glama
enesjakozh
dkmaker

mcp-azure-tablestorage

by dkmaker
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Azure TableStore MCP 服务器

许可证：MIT

基于 TypeScript 的 MCP 服务器，支持通过 Cline 直接与 Azure 表存储交互。此工具允许您查询和管理 Azure 存储表中的数据。

特征

  • 使用 OData 过滤器支持查询 Azure 存储表

  • 获取表模式以了解数据结构

  • 列出存储帐户中的所有表

  • 详细的错误处理和响应信息

  • 通过连接字符串进行简单配置

Related MCP server: Azure Omni-Tool MCP Server

安装

本地开发设置

  1. 克隆存储库：

git clone https://github.com/dkmaker/mcp-azure-tablestorage.git
cd mcp-azure-tablestorage

  1. 安装依赖项：

npm install

  1. 构建服务器：

npm run build

NPM 安装

您可以通过 npm 全局安装该包：

npm install -g dkmaker-mcp-server-tablestore

或者直接用 npx 运行：

npx dkmaker-mcp-server-tablestore

注意：使用 npx 或全局安装时，您仍然需要配置 AZURE_STORAGE_CONNECTION_STRING 环境变量。

在 Cline 中安装

要将 Azure TableStore 服务器与 Cline 一起使用，您需要将其添加到 MCP 设置配置中。配置文件位于：

Windows： %APPDATA%\Code\User\globalStorage\saoudrizwan.claude-dev\settings\cline_mcp_settings.json

将以下内容添加到您的配置中：

{
  "mcpServers": {
    "tablestore": {
      "command": "node",
      "args": ["C:/path/to/your/mcp-azure-tablestorage/build/index.js"],
      "env": {
        "AZURE_STORAGE_CONNECTION_STRING": "your_connection_string_here"  // Required: Your Azure Storage connection string
      }
    }
  }
}

将C:/path/to/your/mcp-azure-tablestorage替换为您克隆存储库的实际路径。

配置

服务器需要以下环境变量：

  • AZURE_STORAGE_CONNECTION_STRING ：您的 Azure 存储帐户连接字符串

在 Cline 中的用法

⚠️重要安全提示：query_table 工具会返回有限的结果子集（默认值：5 个），以保护 LLM 的上下文窗口。除非用户明确确认，否则请勿增加此限制，因为较大的结果集可能会使上下文窗口不堪重负。

安装完成后，您可以通过 Cline 使用 Azure TableStore 服务器。以下是一些示例：

  1. 查询表：

Query the Users table where PartitionKey is 'ACTIVE'

Cline 将使用 query_table 工具：

{
  "tableName": "Users",
  "filter": "PartitionKey eq 'ACTIVE'",
  "limit": 5  // Optional: Defaults to 5 items. WARNING: Do not increase without user confirmation
}

答复将包括：

  • 符合查询条件的项目总数（无限制）

  • 为确保 LLM 安全处理，项目子集有限（默认为 5）

  • 应用极限值

例如：

{
  "totalItems": 25,
  "limit": 5,
  "items": [
    // First 5 matching items
  ]
}

这种设计使 LLM 能够在处理可管理的子集的同时理解数据的全部范围。默认限制为 5 个条目，可以防止 LLM 的上下文窗口过载——只有在用户明确确认的情况下才应增加此限制。

  1. 获取表模式：

Show me the schema for the Orders table

Cline 将使用 get_table_schema 工具：

{
  "tableName": "Orders"
}

  1. 列出表格：

List all tables in the storage account

Cline 将使用 list_tables 工具来执行以下操作：

{}

项目结构

  • src/index.ts ：具有 Azure 表存储交互逻辑的主服务器实现

  • build/ ：编译后的 JavaScript 输出

  • package.json ：项目依赖项和脚本

依赖项

  • @azure/data-tables：Azure 表存储客户端库

  • @modelcontextprotocol/sdk：MCP 服务器实现工具包

执照

本项目采用 MIT 许可证 - 详情请参阅LICENSE文件。这意味着您可以自由使用、修改、分发和再授权代码，前提是您包含原始版权声明和许可条款。

Available Tools

3 tools
get_table_schemaC

Get property names and types from a table

ParametersJSON Schema
NameRequiredDescriptionDefault
tableNameYesName of the table to analyze

TDQS

C2.9/5.0
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 a read operation ('Get'), implying it is likely non-destructive, but does not address permissions, rate limits, error handling, or output format. This leaves significant gaps in understanding how the tool behaves beyond its basic function.

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 is 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.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of annotations and output schema, the description is incomplete for a tool that retrieves schema information. It does not explain what the output looks like (e.g., a list of properties with types), potential errors, or dependencies, leaving the agent with insufficient context for effective 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?

The input schema has 100% description coverage, with 'tableName' clearly documented. The description adds no additional parameter details beyond what the schema provides, such as examples or constraints. Since the schema does the heavy lifting, 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.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get' and the resource 'property names and types from a table', making the purpose specific and understandable. However, it does not explicitly differentiate from sibling tools like 'list_tables' (which likely lists table names) or 'query_table' (which likely queries table data), leaving room for ambiguity in tool selection.

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 like 'list_tables' or 'query_table'. It lacks context such as prerequisites, typical use cases, or exclusions, leaving the agent to infer usage based on tool names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tablesC

List all tables in the storage account

ParametersJSON Schema
NameRequiredDescriptionDefault
prefixNoOptional prefix to filter table names

TDQS

C2.9/5.0
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. It states the tool lists tables but doesn't mention any behavioral traits such as pagination, rate limits, authentication requirements, or what happens if no tables exist. This leaves significant gaps in understanding how the tool behaves operationally.

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 for an agent to parse quickly.

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 lack of annotations and output schema, the description is incomplete for a tool that interacts with storage resources. It doesn't address behavioral aspects like return format, error handling, or operational constraints, which are important for an agent to use the tool effectively in real scenarios.

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 100%, so the input schema already documents the optional 'prefix' parameter. The description doesn't add any additional meaning about parameters beyond what's in the schema, such as format examples or usage context. The baseline score of 3 reflects adequate but minimal value added.

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 ('List') and target resource ('all tables in the storage account'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like 'get_table_schema' or 'query_table', which prevents a perfect score.

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 like 'get_table_schema' or 'query_table'. There's no mention of use cases, prerequisites, or exclusions, leaving the agent with minimal contextual direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

query_tableA

⚠️ WARNING: This tool returns a limited subset of results (default: 5 items) to protect the LLM's context window. DO NOT increase this limit unless explicitly confirmed by the user.

Query data from an Azure Storage Table with optional filters.

Supported OData Filter Examples:

  1. Simple equality: filter: "PartitionKey eq 'COURSE'" filter: "email eq 'user@example.com'"

  2. Compound conditions: filter: "PartitionKey eq 'USER' and email eq 'user@example.com'" filter: "PartitionKey eq 'COURSE' and title eq 'GDPR Training'"

  3. Numeric comparisons: filter: "age gt 25" filter: "costPrice le 100"

  4. Date comparisons (ISO 8601 format): filter: "createdDate gt datetime'2023-01-01T00:00:00Z'" filter: "timestamp lt datetime'2024-12-31T23:59:59Z'"

Supported Operators:

  • eq: Equal

  • ne: Not equal

  • gt: Greater than

  • ge: Greater than or equal

  • lt: Less than

  • le: Less than or equal

  • and: Logical and

  • or: Logical or

  • not: Logical not

ParametersJSON Schema
NameRequiredDescriptionDefault
filterNoOData filter string. See description for examples.
limitNoMaximum number of items to return in response (default: 5). Note: Full query is still executed to get total count.
selectNoArray of property names to select. Example: ["email", "username", "createdDate"]
tableNameYesName of the table to query

TDQS

A4.5/5.0
Behavior5/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 excels at this by: 1) Warning about the default 5-item limit to protect context window, 2) Explaining that the full query executes to get total count despite the limit, 3) Providing extensive OData filter examples and supported operators, 4) Clarifying this is a query operation (not mutation). This goes well beyond what the input schema provides about behavioral characteristics.

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 appropriately sized and front-loaded with the most critical information (warning and core purpose). Every sentence earns its place by providing essential guidance, examples, or operational details. The only minor issue is the extensive OData examples could be slightly condensed, but they serve an important educational purpose for this query tool.

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 4 parameters, no annotations, and no output schema, the description does an excellent job of providing context. It covers the tool's purpose, behavioral constraints (limit warning), parameter usage (extensive filter examples), and distinguishes from siblings. The only gap is lack of information about return format or error handling, which would be helpful since there's no output schema.

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 100%, so the baseline is 3. The description adds significant value beyond the schema by: 1) Providing concrete OData filter examples with syntax, 2) Listing all supported operators with explanations, 3) Clarifying the 'limit' parameter's purpose and default behavior. However, it doesn't explain the 'select' parameter's semantics beyond what the schema already states, keeping it from a perfect score.

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: 'Query data from an Azure Storage Table with optional filters.' This is a specific verb ('query') + resource ('Azure Storage Table') combination that distinguishes it from sibling tools like 'get_table_schema' (schema retrieval) and 'list_tables' (table enumeration). The description establishes this as a data querying tool with filtering capabilities.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context about when to use this tool: for querying table data with OData filters. It distinguishes from siblings by focusing on data retrieval rather than schema or table listing. However, it doesn't explicitly state when NOT to use this tool or mention specific alternatives beyond the sibling names. The warning about the default limit provides operational guidance but not comparative usage advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 3 tool updatesv1.0.0
    • First observedget_table_schema
    • First observedlist_tables
    • First observedquery_table
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

B3.4/5.0

Scored across 3 tools

Disambiguation5/5

Each tool has a clearly distinct purpose with no overlap: get_table_schema retrieves metadata about table structure, list_tables enumerates available tables, and query_table fetches actual data from tables. The descriptions clearly differentiate these operations, making tool selection unambiguous for an agent.

Naming Consistency5/5

All three tools follow a consistent verb_noun naming pattern (get_table_schema, list_tables, query_table) with perfect consistency in style and structure. The naming convention is predictable and follows the same grammatical pattern throughout the tool set.

Tool Count3/5

With only 3 tools, this server feels somewhat thin for Azure Table Storage operations. While the tools cover basic read operations, the absence of create, update, or delete operations for tables or entities makes the surface incomplete for typical database workflows. The count is borderline minimal for the domain.

Completeness2/5

The tool set has significant gaps for a database/storage system. There are no tools for creating tables, inserting entities, updating entities, or deleting tables/entities - only read operations exist. While the query capabilities are well-documented, the lack of write operations creates dead ends for agents trying to perform complete data management workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • Azure Omni-Tool MCP Server

    vedantparmar12
    A
    license
    B
    quality
    D
    maintenance
    Enables intelligent interaction with Azure resources through natural language by translating requests into safe, auditable Azure CLI commands with plan/review workflows and direct access to 8 Azure services including Storage, Cosmos DB, Key Vault, and more.
    3
    1
    MIT

  • Azure Storage MCP Apps Demo

    tw3lveparsecs
    F
    license
    Not graded
    quality
    D
    maintenance
    Provides an interactive dashboard within VS Code Copilot to manage Azure Storage accounts, containers, and blobs through a rich UI. It enables users to visualize storage resources, perform CRUD operations, and generate SAS tokens using the Model Context Protocol.
    2
    -

  • Azure SQL MCP Server

    lostspace003
    F
    license
    Not graded
    quality
    C
    maintenance
    Connects Microsoft Copilot Studio to Azure SQL Databases, enabling natural language interactions for data querying, record management, and schema inspection. It features 12 specialized tools for performing CRUD operations, executing SQL queries, and generating data visualizations like charts.
    -

Appeared in Searches