Skip to main content
Glama
enesjakozh
dkmaker

mcp-azure-tablestorage

by dkmaker
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Azure TableStore MCP サーバー

ライセンス: MIT

Cline を介して Azure Table Storage と直接やり取りできる TypeScript ベースの MCP サーバーです。このツールを使用すると、Azure Storage テーブル内のデータのクエリと管理が可能になります。

特徴

  • 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へのインストール

Cline で Azure TableStore サーバーを使用するには、MCP 設定に Azure TableStore サーバーを追加する必要があります。設定ファイルは次の場所にあります。

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ツールは、LLMのコンテキストウィンドウを保護するため、結果のサブセット（デフォルト：5件）を制限して返します。ユーザーが明示的に確認しない限り、この制限を増やさないでください。結果セットが大きくなると、コンテキストウィンドウが過負荷になる可能性があります。

インストールが完了すると、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 Table Storage の相互作用ロジックを備えたメイン サーバーの実装

  • 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