Skip to main content
Glama
enesjakozh
dkmaker

mcp-azure-tablestorage

by dkmaker
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Servidor MCP de Azure TableStore

Licencia: MIT

Un servidor MCP basado en TypeScript que permite la interacción con Azure Table Storage directamente a través de Cline. Esta herramienta permite consultar y administrar datos en tablas de Azure Storage.

Características

  • Consultar tablas de Azure Storage con compatibilidad con filtros OData

  • Obtenga esquemas de tablas para comprender la estructura de datos

  • Enumere todas las tablas en la cuenta de almacenamiento

  • Información detallada sobre el manejo de errores y respuestas

  • Configuración sencilla a través de cadena de conexión

Related MCP server: Azure Omni-Tool MCP Server

Instalación

Configuración de desarrollo local

  1. Clonar el repositorio:

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

  1. Instalar dependencias:

npm install

  1. Construir el servidor:

npm run build

Instalación de NPM

Puede instalar el paquete globalmente a través de npm:

npm install -g dkmaker-mcp-server-tablestore

O ejecútelo directamente con npx:

npx dkmaker-mcp-server-tablestore

Nota: Al utilizar npx o una instalación global, aún deberá configurar la variable de entorno AZURE_STORAGE_CONNECTION_STRING.

Instalación en Cline

Para usar el servidor Azure TableStore con Cline, debe agregarlo a la configuración de MCP. El archivo de configuración se encuentra en:

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

Añade lo siguiente a tu configuración:

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

Reemplace C:/path/to/your/mcp-azure-tablestorage con la ruta real donde clonó el repositorio.

Configuración

El servidor requiere la siguiente variable de entorno:

  • AZURE_STORAGE_CONNECTION_STRING : cadena de conexión de su cuenta de Azure Storage

Uso en Cline

⚠️ NOTA IMPORTANTE DE SEGURIDAD : La herramienta query_table devuelve un subconjunto limitado de resultados (predeterminado: 5 elementos) para proteger la ventana de contexto del LLM. NO aumente este límite a menos que el usuario lo confirme explícitamente, ya que conjuntos de resultados mayores pueden saturar la ventana de contexto.

Una vez instalado, puede usar el servidor Azure TableStore a través de Cline. A continuación, se muestran algunos ejemplos:

  1. Consultar una tabla:

Query the Users table where PartitionKey is 'ACTIVE'

Cline utilizará la herramienta query_table con:

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

La respuesta incluirá:

  • Número total de elementos que coinciden con la consulta (sin límite)

  • Subconjunto limitado de elementos (predeterminado 5) para un procesamiento LLM seguro

  • Valor límite aplicado

Por ejemplo:

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

Este diseño permite al LLM comprender el alcance completo de los datos mientras trabaja con un subconjunto manejable. El límite predeterminado de 5 elementos evita que se sature la ventana de contexto del LLM; este límite solo debe aumentarse con la confirmación explícita del usuario.

  1. Obtener el esquema de la tabla:

Show me the schema for the Orders table

Cline utilizará la herramienta get_table_schema con:

{
  "tableName": "Orders"
}

  1. Tablas de listado:

List all tables in the storage account

Cline utilizará la herramienta list_tables con:

{}

Estructura del proyecto

  • src/index.ts : Implementación del servidor principal con lógica de interacción de Azure Table Storage

  • build/ : Salida de JavaScript compilada

  • package.json : Dependencias y scripts del proyecto

Dependencias

  • @azure/data-tables: biblioteca cliente de Azure Table Storage

  • @modelcontextprotocol/sdk: Kit de herramientas de implementación del servidor MCP

Licencia

Este proyecto está licenciado bajo la Licencia MIT (consulte el archivo de LICENCIA para obtener más información). Esto significa que puede usar, modificar, distribuir y sublicenciar el código libremente, siempre que incluya el aviso de derechos de autor y los términos de la licencia originales.

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