Skip to main content
Glama
enesjakozh
dkmaker

mcp-azure-tablestorage

by dkmaker
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

Azure TableStore MCP Server

License: MIT

A TypeScript-based MCP server that enables interaction with Azure Table Storage directly through Cline. This tool allows you to query and manage data in Azure Storage Tables.

Features

  • Query Azure Storage Tables with OData filter support

  • Get table schemas to understand data structure

  • List all tables in the storage account

  • Detailed error handling and response information

  • Simple configuration through connection string

Related MCP server: Azure Omni-Tool MCP Server

Installation

Local Development Setup

  1. Clone the repository:

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

  1. Install dependencies:

npm install

  1. Build the server:

npm run build

NPM Installation

You can install the package globally via npm:

npm install -g dkmaker-mcp-server-tablestore

Or run it directly with npx:

npx dkmaker-mcp-server-tablestore

Note: When using npx or global installation, you'll still need to configure the AZURE_STORAGE_CONNECTION_STRING environment variable.

Installing in Cline

To use the Azure TableStore server with Cline, you need to add it to your MCP settings configuration. The configuration file is located at:

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

Add the following to your configuration:

{
  "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
      }
    }
  }
}

Replace C:/path/to/your/mcp-azure-tablestorage with the actual path where you cloned the repository.

Configuration

The server requires the following environment variable:

  • AZURE_STORAGE_CONNECTION_STRING: Your Azure Storage account connection string

Usage in Cline

⚠️ IMPORTANT SAFETY NOTE: The query_table 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, as larger result sets can overwhelm the context window.

Once installed, you can use the Azure TableStore server through Cline. Here are some examples:

  1. Querying a table:

Query the Users table where PartitionKey is 'ACTIVE'

Cline will use the query_table tool with:

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

The response will include:

  • Total number of items that match the query (without limit)

  • Limited subset of items (default 5) for safe LLM processing

  • Applied limit value

For example:

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

This design allows the LLM to understand the full scope of the data while working with a manageable subset. The default limit of 5 items protects against overwhelming the LLM's context window - this limit should only be increased when explicitly confirmed by the user.

  1. Getting table schema:

Show me the schema for the Orders table

Cline will use the get_table_schema tool with:

{
  "tableName": "Orders"
}

  1. Listing tables:

List all tables in the storage account

Cline will use the list_tables tool with:

{}

Project Structure

  • src/index.ts: Main server implementation with Azure Table Storage interaction logic

  • build/: Compiled JavaScript output

  • package.json: Project dependencies and scripts

Dependencies

  • @azure/data-tables: Azure Table Storage client library

  • @modelcontextprotocol/sdk: MCP server implementation toolkit

License

This project is licensed under the MIT License - see the LICENSE file for details. This means you can use, modify, distribute, and sublicense the code freely, provided you include the original copyright notice and license terms.

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. Dates show when Glama detected each change.

  1. 3 tool updatesv1.0.0
    • First observedget_table_schema
    • First observedlist_tables
    • First observedquery_table
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

B3.4/5.0
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
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

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

Latest Blog Posts

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/dkmaker/mcp-azure-tablestorage'

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