Skip to main content
Glama
enesjakozh
madhukarkumar

SingleStore MCP Server

by madhukarkumar
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

Servidor MCP de SingleStore

insignia de herrería

Un servidor de Protocolo de Contexto de Modelo (MCP) para interactuar con bases de datos SingleStore. Este servidor proporciona herramientas para consultar tablas, describir esquemas y generar diagramas ER.

Características

  • Listar todas las tablas en la base de datos

  • Ejecutar consultas SQL personalizadas

  • Obtenga información detallada de la tabla, incluido el esquema y los datos de muestra

  • Generar diagramas ER de sirena del esquema de base de datos

  • Compatibilidad con SSL con obtención automática de paquetes de CA

  • Manejo adecuado de errores y seguridad de tipos en TypeScript

Related MCP server: SingleStore MCP Server

Prerrequisitos

  • Node.js 16 o superior

  • npm o hilo

  • Acceso a una base de datos SingleStore

  • Paquete CA de SingleStore (obtenido automáticamente del portal)

Instalación

Instalación mediante herrería

Para instalar SingleStore MCP Server para Claude Desktop automáticamente a través de Smithery :

npx -y @smithery/cli install @madhukarkumar/singlestore-mcp-server --client claude

  1. Clonar el repositorio:

git clone <repository-url>
cd mcp-server-singlestore

  1. Instalar dependencias:

npm install

  1. Construir el servidor:

npm run build

Variables de entorno

Variables de entorno requeridas

El servidor requiere las siguientes variables de entorno para la conexión a la base de datos:

SINGLESTORE_HOST=your-host.singlestore.com
SINGLESTORE_PORT=3306
SINGLESTORE_USER=your-username
SINGLESTORE_PASSWORD=your-password
SINGLESTORE_DATABASE=your-database

Todas estas variables de entorno son necesarias para que el servidor establezca una conexión con su base de datos de SingleStore. La conexión utiliza SSL con el paquete de CA de SingleStore, que se obtiene automáticamente del portal de SingleStore.

Variables de entorno opcionales

Para compatibilidad con el protocolo SSE (eventos enviados por el servidor):

SSE_ENABLED=true       # Enable the SSE HTTP server (default: false if not set)
SSE_PORT=3333          # HTTP port for the SSE server (default: 3333 if not set)

Configuración de variables de entorno

  1. En su shell : configure las variables en su terminal antes de ejecutar el servidor:

    export SINGLESTORE_HOST=your-host.singlestore.com
export SINGLESTORE_PORT=3306
export SINGLESTORE_USER=your-username
export SINGLESTORE_PASSWORD=your-password
export SINGLESTORE_DATABASE=your-database

  2. En los archivos de configuración del cliente : agregue las variables a su archivo de configuración del cliente MCP como se muestra en las secciones de integración a continuación.

Uso

Soporte de protocolo

Este servidor admite dos protocolos para la integración de clientes:

  1. Protocolo MCP : el protocolo de contexto de modelo estándar que utiliza la comunicación stdio, utilizado por Claude Desktop, Windsurf y Cursor.

  2. Protocolo SSE : eventos enviados por el servidor a través de HTTP para clientes y aplicaciones basados en web que necesitan transmisión de datos en tiempo real.

Ambos protocolos exponen las mismas herramientas y funcionalidades, lo que le permite elegir el mejor método de integración para su caso de uso.

Herramientas disponibles

  1. listas_de_tablas

    • Enumera todas las tablas de la base de datos

    • No se requieren parámetros GXP8

  2. tabla de consulta

    • Ejecuta una consulta SQL personalizada

    • Parámetros:

      • consulta: cadena de consulta SQL GXP9

  3. describe_tabla

    • Obtiene información detallada sobre una tabla

    • Parámetros:

      • tabla: Nombre de la tabla GXP10

  4. generar_diagrama_er

    • Genera un diagrama ER de sirena del esquema de la base de datos

    • No se requieren parámetros GXP11

  5. ejecutar_lectura_consulta

    • Ejecuta una consulta de solo lectura (SELECT) en la base de datos

    • Parámetros:

      • consulta: consulta SQL SELECT para ejecutar GXP12

  6. crear_tabla

    • Crear una nueva tabla en la base de datos con columnas y restricciones específicas

    • Parámetros:

      • table_name: Nombre de la tabla a crear

      • columnas: Matriz de definiciones de columnas

      • table_options: Configuración de tabla opcional GXP13

  7. generar_datos_sintéticos

    • Generar e insertar datos sintéticos en una tabla existente

    • Parámetros:

      • tabla: Nombre de la tabla en la que se insertarán los datos

      • count: Número de filas a generar (predeterminado: 100)

      • column_generators: generadores personalizados para columnas específicas

      • batch_size: Número de filas a insertar en cada lote (predeterminado: 1000) GXP14

  8. optimizar_sql

    • Analizar una consulta SQL utilizando PROFILE y proporcionar recomendaciones de optimización

    • Parámetros:

      • consulta: Consulta SQL para analizar y optimizar GXP15

    • La respuesta incluye:

      • Consulta original

      • Resumen del perfil de rendimiento (tiempo total de ejecución, tiempo de compilación, tiempo de ejecución)

      • Lista de cuellos de botella detectados

      • Recomendaciones de optimización con niveles de impacto (alto/medio/bajo)

      • Sugerencias para índices, uniones, uso de memoria y otras optimizaciones

Ejecución independiente

  1. Construir el servidor:

npm run build

  1. Ejecute el servidor solo con el protocolo MCP:

node build/index.js

  1. Ejecute el servidor con los protocolos MCP y SSE:

SSE_ENABLED=true SSE_PORT=3333 node build/index.js

Uso del protocolo SSE

Cuando SSE está habilitado, el servidor expone los siguientes puntos finales HTTP:

  1. Punto final raíz

    GET /

    Devuelve información del servidor y los puntos finales disponibles.

  2. Chequeo de salud

    GET /health

    Devuelve información de estado sobre el servidor.

  3. Conexión SSE

    GET /sse

    Establece una conexión de eventos enviados por el servidor para actualizaciones en tiempo real.

  4. Herramientas de lista

    GET /tools

    Devuelve una lista de todas las herramientas disponibles, igual que la funcionalidad list_tools de MCP.

    También admite solicitudes POST para compatibilidad con MCP Inspector:

    POST /tools
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": "request-id",
  "method": "mcp.list_tools",
  "params": {}
}

  5. Herramienta de llamada

    POST /call-tool
Content-Type: application/json

{
  "name": "tool_name",
  "arguments": {
    "param1": "value1",
    "param2": "value2"
  },
  "client_id": "optional_sse_client_id_for_streaming_response"
}

    Ejecuta una herramienta con los argumentos proporcionados.

    • Si se proporciona client_id , la respuesta se transmite a ese cliente SSE.

    • Si se omite client_id , la respuesta se devuelve directamente en la respuesta HTTP.

    También admite el formato MCP estándar para compatibilidad con MCP Inspector:

    POST /call-tool
Content-Type: application/json

{
  "jsonrpc": "2.0",
  "id": "request-id",
  "method": "mcp.call_tool",
  "params": {
    "name": "tool_name",
    "arguments": {
      "param1": "value1",
      "param2": "value2"
    },
    "_meta": {
      "client_id": "optional_sse_client_id_for_streaming_response"
    }
  }
}

Tipos de eventos de SSE

Al utilizar conexiones SSE, el servidor envía los siguientes tipos de eventos:

  1. mensaje (evento sin nombre): se envía cuando se establece correctamente una conexión SSE.

  2. abierto : Evento de conexión adicional establecida.

  3. mensaje : se utiliza para todos los mensajes del protocolo MCP, incluidos eventos de inicio de herramienta, resultado y error.

Todos los eventos siguen el formato JSON-RPC 2.0 del protocolo MCP. El sistema utiliza el tipo de evento message estándar para garantizar la compatibilidad con el Inspector de MCP y la mayoría de las bibliotecas cliente de SSE.

Ejemplo de cliente JavaScript

// Connect to SSE endpoint
const eventSource = new EventSource('http://localhost:3333/sse');
let clientId = null;

// Handle connection establishment via unnamed event
eventSource.onmessage = (event) => {
  const data = JSON.parse(event.data);
  if (data.type === 'connection_established') {
    clientId = data.clientId;
    console.log(`Connected with client ID: ${clientId}`);
  }
};

// Handle open event
eventSource.addEventListener('open', (event) => {
  console.log('SSE connection opened via open event');
});

// Handle all MCP messages
eventSource.addEventListener('message', (event) => {
  const data = JSON.parse(event.data);
  
  if (data.jsonrpc === '2.0') {
    if (data.result) {
      console.log('Tool result:', data.result);
    } else if (data.error) {
      console.error('Tool error:', data.error);
    } else if (data.method === 'mcp.call_tool.update') {
      console.log('Tool update:', data.params);
    }
  }
});

// Call a tool with streaming response (custom format)
async function callTool(name, args) {
  const response = await fetch('http://localhost:3333/call-tool', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      name: name,
      arguments: args,
      client_id: clientId
    })
  });
  return response.json();
}

// Call a tool with streaming response (MCP format)
async function callToolMcp(name, args) {
  const response = await fetch('http://localhost:3333/call-tool', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({
      jsonrpc: '2.0',
      id: 'request-' + Date.now(),
      method: 'mcp.call_tool',
      params: {
        name: name,
        arguments: args,
        _meta: {
          client_id: clientId
        }
      }
    })
  });
  return response.json();
}

// Example usage
callTool('list_tables', {})
  .then(response => console.log('Request accepted:', response));

Uso con MCP Inspector

El Inspector MCP es una herramienta basada en navegador para probar y depurar servidores MCP. Para usarlo con este servidor:

  1. Inicie el servidor y el inspector MCP con un solo comando:

    npm run inspector

    O iniciar solo el servidor con:

    npm run start:inspector

  2. Para instalar y ejecutar MCP Inspector por separado:

    npx @modelcontextprotocol/inspector

    El inspector se abrirá en su navegador predeterminado.

  3. Cuando se abre el Inspector MCP:

    a. Introduzca la URL en el campo de conexión:

    http://localhost:8081

    Nota: El puerto real puede variar según la configuración. Consulte los registros de inicio del servidor para conocer el puerto utilizado. El servidor mostrará:

    MCP SingleStore SSE server listening on port XXXX

    b. Asegúrese de que "SSE" esté seleccionado como tipo de transporte.

    c. Haga clic en "Conectar".

  4. Si tiene problemas de conexión, pruebe estas alternativas:

    a. Intente conectarse a un punto final específico:

    http://localhost:8081/stream

    b. Intente usar la dirección IP real de su máquina:

    http://192.168.1.x:8081

    c. Si se ejecuta en Docker:

    http://host.docker.internal:8081

  5. Depuración de problemas de conexión :

    a. Verifique que el servidor esté en funcionamiento visitando http://localhost:8081 en su navegador.

    b. Verifique los registros del servidor para ver si hay intentos de conexión.

    c. Intente reiniciar tanto el servidor como el inspector.

    d. Asegúrese de que ningún otro servicio esté utilizando el puerto 8081

    e. Pruebe la conexión SSE con el script proporcionado:

    npm run test:sse

    O manualmente con curl:

    curl -N http://localhost:8081/sse

    f. Verifique que la configuración de su firewall permita conexiones al puerto 8081

  6. Una vez conectado, el inspector mostrará todas las herramientas disponibles y le permitirá probarlas de forma interactiva.

⚠️ Nota : Al utilizar el Inspector MCP, debe utilizar la URL completa, incluido el prefijo http:// .

Integración de clientes MCP

Instalación en Claude Desktop

  1. Agregue la configuración del servidor a su archivo de configuración de Claude Desktop ubicado en:

    • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • Ventanas: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "singlestore": {
      "command": "node",
      "args": ["path/to/mcp-server-singlestore/build/index.js"],
      "env": {
        "SINGLESTORE_HOST": "your-host.singlestore.com",
        "SINGLESTORE_PORT": "3306",
        "SINGLESTORE_USER": "your-username",
        "SINGLESTORE_PASSWORD": "your-password",
        "SINGLESTORE_DATABASE": "your-database",
        "SSE_ENABLED": "true",
        "SSE_PORT": "3333"
      }
    }
  }
}

Las variables SSE_ENABLED y SSE_PORT son opcionales. Inclúyalas si desea habilitar el servidor HTTP con compatibilidad con SSE junto con el protocolo MCP estándar.

  1. Reiniciar la aplicación de escritorio Claude

  2. En tu conversación con Claude, ahora puedes usar el servidor SingleStore MCP con:

use_mcp_tool({
  server_name: "singlestore",
  tool_name: "list_tables",
  arguments: {}
})

Instalación en Windsurf

  1. Agregue la configuración del servidor a su archivo de configuración de Windsurf ubicado en:

    • macOS: ~/Library/Application Support/Windsurf/config.json

    • Ventanas: %APPDATA%\Windsurf\config.json

{
  "mcpServers": {
    "singlestore": {
      "command": "node",
      "args": ["path/to/mcp-server-singlestore/build/index.js"],
      "env": {
        "SINGLESTORE_HOST": "your-host.singlestore.com",
        "SINGLESTORE_PORT": "3306",
        "SINGLESTORE_USER": "your-username",
        "SINGLESTORE_PASSWORD": "your-password",
        "SINGLESTORE_DATABASE": "your-database",
        "SSE_ENABLED": "true",
        "SSE_PORT": "3333"
      }
    }
  }
}

Las variables SSE_ENABLED y SSE_PORT son opcionales, pero habilitan funcionalidad adicional a través del servidor HTTP SSE.

  1. Reiniciar Windsurf

  2. En su conversación con Claude en Windsurf, las herramientas MCP de SingleStore estarán disponibles automáticamente cuando Claude necesite acceder a la información de la base de datos.

Instalación en Cursor

  1. Añade la configuración del servidor a la configuración del cursor:

    • Cursor abierto

    • Vaya a Configuración (icono de engranaje) > Extensiones > Claude AI > Servidores MCP

    • Agregue un nuevo servidor MCP con la siguiente configuración:

{
  "singlestore": {
    "command": "node",
    "args": ["path/to/mcp-server-singlestore/build/index.js"],
    "env": {
      "SINGLESTORE_HOST": "your-host.singlestore.com",
      "SINGLESTORE_PORT": "3306",
      "SINGLESTORE_USER": "your-username",
      "SINGLESTORE_PASSWORD": "your-password",
      "SINGLESTORE_DATABASE": "your-database",
      "SSE_ENABLED": "true",
      "SSE_PORT": "3333"
    }
  }
}

Las variables SSE_ENABLED y SSE_PORT permiten que las aplicaciones web se conecten al servidor a través de HTTP y reciban actualizaciones en tiempo real a través de eventos enviados por el servidor.

  1. Reiniciar cursor

  2. Al utilizar Claude AI dentro de Cursor, las herramientas SingleStore MCP estarán disponibles para las operaciones de la base de datos.

Consideraciones de seguridad

  1. Nunca envíe credenciales al control de versiones

  2. Utilice variables de entorno o gestión de configuración segura

  3. Considere utilizar un mecanismo de agrupación de conexiones para uso en producción

  4. Implementar controles de acceso y permisos de usuario adecuados en SingleStore

  5. Mantenga actualizado el paquete SingleStore CA

Desarrollo

Estructura del proyecto

mcp-server-singlestore/
├── src/
│   └── index.ts      # Main server implementation
├── package.json
├── tsconfig.json
├── README.md
└── CHANGELOG.md

Edificio

npm run build

Pruebas

npm test

Solución de problemas

  1. Problemas de conexión

    • Verifique las credenciales y la información del host en sus variables de entorno

    • Comprobar la configuración de SSL

    • Asegúrese de que la base de datos sea accesible desde su red

    • Verifique la configuración de su firewall para permitir conexiones salientes a su base de datos SingleStore

  2. Problemas de compilación

    • Borrar node_modules y reinstalar las dependencias

    • Verificar la configuración de TypeScript

    • Comprobar la compatibilidad de la versión de Node.js (debe ser 16+)

  3. Problemas de integración de MCP

    • Verifique que la ruta al archivo build/index.js del servidor sea correcta en la configuración de su cliente

    • Compruebe que todas las variables de entorno estén configuradas correctamente en la configuración de su cliente

    • Reinicie su aplicación cliente después de realizar cambios de configuración

    • Verifique los registros del cliente para ver si hay mensajes de error relacionados con el servidor MCP

    • Intente ejecutar primero el servidor de forma independiente para validar que funciona fuera del cliente

Contribuyendo

  1. Bifurcar el repositorio

  2. Crear una rama de características

  3. Confirme sus cambios

  4. Empujar hacia la rama

  5. Crear una solicitud de extracción

Licencia

Licencia MIT: consulte el archivo de LICENCIA para obtener más detalles

Available Tools

8 tools
create_tableC

Create a new table in the database with specified columns and constraints

ParametersJSON Schema
NameRequiredDescriptionDefault
columnsYesList of columns to create
table_nameYesName of the table to create
table_optionsNo

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 this is a creation operation but doesn't mention important behavioral aspects: whether this requires specific database permissions, if it's a destructive operation that might overwrite existing tables, what happens on success/failure, or any rate limits. The description is minimal and doesn't compensate for the lack of annotations.

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 ('Create a new table in the database') and adds necessary qualification ('with specified columns and constraints'). Every word serves a purpose with zero waste or redundancy. It's appropriately sized for a creation operation with moderate complexity.

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?

For a database mutation tool with no annotations, no output schema, and moderate parameter complexity (3 parameters including nested objects), the description is insufficient. It doesn't address critical context: what permissions are needed, whether the operation is idempotent, what happens if a table already exists, what the return value looks like, or error conditions. The agent lacks necessary operational context for safe and 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 description mentions 'columns and constraints' which aligns with the 'columns' and 'table_options' parameters in the schema, providing some semantic context beyond the schema's technical descriptions. However, with 67% schema description coverage (2 of 3 parameters have descriptions), the description doesn't fully compensate for the coverage gap - it doesn't explain what 'table_options' encompasses or provide examples of constraint types. The baseline is appropriate given partial schema coverage.

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 ('Create a new table') and the resource ('in the database'), with additional context about what gets created ('with specified columns and constraints'). It distinguishes from siblings like 'list_tables' or 'describe_table' by being a creation operation rather than querying existing tables. However, it doesn't explicitly differentiate from other potential table-related operations that might exist in other contexts.

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., database permissions, existing schema), when not to use it (e.g., for temporary tables vs permanent), or refer to sibling tools like 'generate_er_diagram' for design planning or 'optimize_sql' for performance considerations. The agent must infer usage from the tool name alone.

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

describe_tableC

Get detailed information about a table

ParametersJSON Schema
NameRequiredDescriptionDefault
tableYesName of the table to describe

TDQS

C2.9/5.0
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 states the action ('Get detailed information') but doesn't describe what 'detailed information' includes (e.g., schema, columns, constraints), whether it requires specific permissions, or how errors are handled. For a tool with no annotations, 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 with zero waste. It's front-loaded with the core purpose ('Get detailed information about a table'), making it easy to parse quickly. Every word earns its place, and there's no unnecessary elaboration.

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 no annotations and no output schema, the description is incomplete for a tool that likely returns complex metadata. It doesn't explain what 'detailed information' entails (e.g., column types, indexes), leaving the agent uncertain about the return value. For a tool with such contextual gaps, more detail is needed to be fully 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?

The input schema has 100% description coverage, with the 'table' parameter clearly documented as 'Name of the table to describe'. The description doesn't add any meaning beyond this, such as format examples or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the schema does the heavy lifting.

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 resource ('detailed information about a table'), making the purpose immediately understandable. It distinguishes from siblings like 'list_tables' (which lists tables) and 'query_table' (which queries data), though it doesn't explicitly differentiate them. The description is specific but lacks explicit sibling differentiation for 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. It doesn't mention when to use 'describe_table' instead of 'list_tables' (for metadata vs. listing) or 'query_table' (for data vs. structure), nor does it specify prerequisites like needing an existing table. Usage is implied from the name 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.

generate_er_diagramB

Generate a Mermaid ER diagram of the database schema

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.2/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 the action but does not reveal any behavioral traits such as whether it requires database permissions, if it's read-only or mutative, potential rate limits, or what the output format entails beyond 'Mermaid ER diagram'. This leaves significant gaps for an agent to understand how to invoke it safely and effectively.

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 with zero waste. It is front-loaded and appropriately sized for a tool with no parameters, making it easy for an agent to parse and understand 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 no parameters, no annotations, and no output schema, the description is minimally adequate by stating what it does. However, it lacks details on output format (e.g., Mermaid syntax specifics), behavioral context, or usage compared to siblings, which are important for a tool that generates diagrams. This makes it complete enough for basic understanding but with clear gaps in practical 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 tool has 0 parameters, and the schema description coverage is 100%, so there is no need for parameter details in the description. The baseline for such cases is 4, as the description appropriately focuses on the tool's purpose without redundant parameter information, though it could slightly improve by noting the lack of parameters explicitly.

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 'Generate' and the resource 'Mermaid ER diagram of the database schema', making the purpose specific and actionable. However, it does not explicitly differentiate from sibling tools like 'describe_table' or 'list_tables', which might also provide schema information, so it falls short of 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 such as 'describe_table' for detailed table info or 'list_tables' for a simple overview. It lacks explicit context, prerequisites, or exclusions, leaving the agent to infer usage based on the tool name alone.

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

generate_synthetic_dataC

Generate and insert synthetic data into an existing table

ParametersJSON Schema
NameRequiredDescriptionDefault
batch_sizeNoNumber of rows to insert in each batch
column_generatorsNoCustom generators for specific columns (optional)
countNoNumber of rows to generate and insert
tableYesName of the table to insert data into

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 mentions 'insert' implying a write operation, but lacks details on permissions needed, whether data overwrites existing rows, transaction behavior, or error handling. This is inadequate for a mutation tool with zero 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.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single, efficient sentence that front-loads the core action. It wastes no words, though it could be slightly more informative given the tool's complexity.

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?

For a mutation tool with no annotations and no output schema, the description is incomplete. It doesn't explain what happens after insertion (e.g., success confirmation, row count returned), error conditions, or dependencies on existing table structure, leaving significant gaps for agent understanding.

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 schema fully documents all parameters. The description adds no additional meaning beyond implying data generation and insertion, which is already clear from the tool name. Baseline 3 is appropriate when the schema does all the work.

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 ('Generate and insert synthetic data') and the target resource ('into an existing table'), which distinguishes it from siblings like create_table or query_table. However, it doesn't explicitly differentiate from all siblings (e.g., run_read_query might also involve data manipulation).

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., table must exist), when not to use it (e.g., for production data), or refer to sibling tools like create_table for table creation first.

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

list_tablesB

List all tables in the database

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

There are no annotations, so the description must fully disclose behavior. It merely states 'List all tables', which implies a read operation, but omits details on permissions, output format, or performance implications.

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 a single, efficient sentence with no unnecessary words. It is appropriately front-loaded but lacks any structural enhancement like bullet points that could aid readability.

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 no output schema or annotations, the description should explain what 'list' returns (e.g., table names, schemas). Without this, an agent may not know how to use the result. Sibling tools like 'describe_table' suggest additional context might be needed.

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 no parameters, so the description cannot add parameter meaning. Baseline for zero parameters is 4, and the description is sufficient for the parameterless case.

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 lists all tables in the database. While it distinguishes from 'describe_table' by listing instead of describing, it does not explicitly differentiate from potential siblings like 'query' or 'execute'.

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 its siblings (describe_table, execute, query). It is implied that it retrieves table names, but no context on prerequisites or alternatives.

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

optimize_sqlB

Analyze a SQL query using PROFILE and provide optimization recommendations

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSQL query to analyze and optimize

TDQS

B3.3/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 mentions the tool uses 'PROFILE' (implying a profiling mechanism) and provides recommendations, but doesn't specify whether this is a read-only analysis, if it requires specific permissions, what the output format looks like, or any rate limits. For a tool with zero annotation coverage, this leaves significant behavioral gaps.

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 functionality ('analyze a SQL query') and adds key details ('using PROFILE and provide optimization recommendations') without any wasted words. Every part of the sentence contributes directly to understanding the tool's purpose.

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 moderate complexity (analysis with optimization recommendations), no annotations, no output schema, and a single well-documented parameter, the description is adequate but incomplete. It covers the basic purpose but lacks details on behavioral traits, output format, and usage context relative to siblings, which are needed for a more complete understanding.

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%, with the single parameter 'query' well-documented in the schema ('SQL query to analyze and optimize'). The description adds minimal value beyond this, only reiterating that it analyzes and optimizes the query. 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 tool's purpose with specific verbs ('analyze' and 'provide optimization recommendations') and identifies the resource ('SQL query'). It distinguishes from siblings like 'query_table' or 'run_read_query' by focusing on analysis rather than execution. However, it doesn't explicitly differentiate from all siblings (e.g., 'describe_table' might also analyze queries).

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 context ('analyze a SQL query... and provide optimization recommendations'), suggesting it's for performance tuning rather than data retrieval or schema operations. However, it lacks explicit guidance on when to use this tool versus alternatives like 'run_read_query' for execution or 'describe_table' for schema analysis, and doesn't mention prerequisites or exclusions.

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

query_tableC

Execute a query on a table

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSQL query to execute

TDQS

C2.7/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden but only states the action without disclosing behavioral traits such as whether it's read-only or destructive, permission requirements, rate limits, or response format. It lacks critical context for safe and effective use.

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 with zero waste, appropriately sized and front-loaded. It directly states the tool's function without unnecessary elaboration, earning full marks for conciseness.

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 tool's complexity (executing queries, potentially with side effects), no annotations, no output schema, and incomplete behavioral disclosure, the description is inadequate. It fails to provide enough context for the agent to understand risks, results, or proper application.

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 schema already documents the 'query' parameter as 'SQL query to execute'. The description adds no additional meaning beyond this, such as query syntax examples or constraints, resulting in a baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

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

The description 'Execute a query on a table' states a general purpose (verb+resource) but is vague about what type of query (read/write, SQL specifics) and doesn't distinguish from sibling 'run_read_query' or 'optimize_sql'. It minimally meets the requirement but lacks specificity for differentiation.

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 'run_read_query' or 'optimize_sql'. The description implies a general query execution but doesn't specify context, exclusions, or prerequisites, leaving the agent with no usage direction.

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

run_read_queryB

Execute a read-only (SELECT) query on the database

ParametersJSON Schema
NameRequiredDescriptionDefault
queryYesSQL SELECT query to execute

TDQS

B3.2/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 'read-only (SELECT)' which implies non-destructive and safe operations, but fails to address critical aspects like permissions needed, rate limits, error handling, or what the output looks like (e.g., result format, pagination). This leaves significant gaps for an agent to understand the tool's 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 front-loads key information ('Execute a read-only (SELECT) query'). There is no wasted verbiage or redundancy, making it highly concise and well-structured for quick comprehension.

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?

For a database query tool with no annotations and no output schema, the description is incomplete. It lacks details on behavioral traits (e.g., security, performance), output format, and usage guidelines compared to siblings. While concise, it does not provide enough context for an agent to reliably use the tool without additional assumptions or trial-and-error.

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 the 'query' parameter clearly documented as 'SQL SELECT query to execute'. The description adds no additional semantic details beyond this, such as syntax examples, supported SQL features, or constraints. Given the high schema coverage, a baseline score of 3 is appropriate as the schema does the heavy lifting.

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 ('Execute') and resource ('read-only (SELECT) query on the database'), making the purpose immediately understandable. It distinguishes from siblings like 'create_table' or 'optimize_sql' by specifying read-only SELECT operations, though it doesn't explicitly contrast with 'query_table' 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 Guidelines3/5

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

The description implies usage for executing SELECT queries, but provides no explicit guidance on when to use this tool versus alternatives like 'query_table' or 'optimize_sql'. It mentions 'read-only' which suggests safety, but lacks details on prerequisites, limitations, or specific scenarios where this tool is preferred.

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. 8 tool updatesv1.0.0
    • First observedcreate_table
    • First observeddescribe_table
    • First observedgenerate_er_diagram
    • First observedgenerate_synthetic_data
    • First observedlist_tables
    • First observedoptimize_sql
    • First observedquery_table
    • First observedrun_read_query
Deploy Server
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

TDQS

B3.4/5.0

Scored across 8 tools

Disambiguation4/5

Most tools have distinct purposes, but query_table and run_read_query overlap significantly as both execute SELECT queries, which could cause confusion. The other tools target clear, separate operations like table management, schema visualization, and query optimization.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using snake_case, such as create_table, list_tables, and optimize_sql. This predictability makes it easy for agents to understand and navigate the tool set without confusion.

Tool Count5/5

With 8 tools, this server is well-scoped for database operations, covering essential tasks like table management, query execution, and schema analysis. Each tool serves a clear purpose, and the count is neither too sparse nor overwhelming for the domain.

Completeness4/5

The tool set provides strong coverage for core database workflows, including CRUD-like operations (create, list, describe, query) and utilities like optimization and data generation. A minor gap is the lack of update or delete operations, which agents might need to work around, but the surface is largely complete for the stated purpose.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

  • PostgreSQL MCP Server

    cesarvarela
    A
    license
    B
    quality
    D
    maintenance
    A TypeScript-based Model Context Protocol server that enables AI assistants to perform secure database operations on PostgreSQL databases through structured tool interfaces.
    8
    10 npm
    MIT

  • sql-mcp

    NakiriYuuzu
    A
    license
    Not graded
    quality
    C
    maintenance
    A Model Context Protocol server for interacting with MSSQL and PostgreSQL databases, offering tools for schema exploration and SQL execution. It features configurable query modes for safety and supports advanced authentication methods like Windows Auth and SSL.
    9 npm
    MIT

Appeared in Searches