Skip to main content
Glama
enesjakozh
madhukarkumar

SingleStore MCP Server

by madhukarkumar
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Remote

SingleStore MCP Server

A Model Context Protocol (MCP) server for interacting with SingleStore databases. This server provides tools for querying tables, describing schemas, and generating ER diagrams.

Features

  • List all tables in the database

  • Execute custom SQL queries

  • Get detailed table information including schema and sample data

  • Generate Mermaid ER diagrams of database schema

  • SSL support with automatic CA bundle fetching

  • Proper error handling and TypeScript type safety

Related MCP server: SingleStore MCP Server

Prerequisites

  • Node.js 16 or higher

  • npm or yarn

  • Access to a SingleStore database

  • SingleStore CA bundle (automatically fetched from portal)

Installation

Installing via Smithery

To install SingleStore MCP Server for Claude Desktop automatically via Smithery:

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

  1. Clone the repository:

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

  1. Install dependencies:

npm install

  1. Build the server:

npm run build

Environment Variables

Required Environment Variables

The server requires the following environment variables for database connection:

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

All these environment variables are required for the server to establish a connection to your SingleStore database. The connection uses SSL with the SingleStore CA bundle, which is automatically fetched from the SingleStore portal.

Optional Environment Variables

For SSE (Server-Sent Events) protocol support:

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)

Setting Environment Variables

  1. In Your Shell: Set the variables in your terminal before running the server:

    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. In Client Configuration Files: Add the variables to your MCP client configuration file as shown in the integration sections below.

Usage

Protocol Support

This server supports two protocols for client integration:

  1. MCP Protocol: The standard Model Context Protocol using stdio communication, used by Claude Desktop, Windsurf, and Cursor.

  2. SSE Protocol: Server-Sent Events over HTTP for web-based clients and applications that need real-time data streaming.

Both protocols expose the same tools and functionality, allowing you to choose the best integration method for your use case.

Available Tools

  1. list_tables

    • Lists all tables in the database

    • No parameters required

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

  2. query_table

    • Executes a custom SQL query

    • Parameters:

      • query: SQL query string

    use_mcp_tool({
  server_name: "singlestore",
  tool_name: "query_table",
  arguments: {
    query: "SELECT * FROM your_table LIMIT 5"
  }
})

  3. describe_table

    • Gets detailed information about a table

    • Parameters:

      • table: Table name

    use_mcp_tool({
  server_name: "singlestore",
  tool_name: "describe_table",
  arguments: {
    table: "your_table"
  }
})

  4. generate_er_diagram

    • Generates a Mermaid ER diagram of the database schema

    • No parameters required

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

  5. run_read_query

    • Executes a read-only (SELECT) query on the database

    • Parameters:

      • query: SQL SELECT query to execute

    use_mcp_tool({
  server_name: "singlestore",
  tool_name: "run_read_query",
  arguments: {
    query: "SELECT * FROM your_table LIMIT 5"
  }
})

  6. create_table

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

    • Parameters:

      • table_name: Name of the table to create

      • columns: Array of column definitions

      • table_options: Optional table configuration

    use_mcp_tool({
  server_name: "singlestore",
  tool_name: "create_table",
  arguments: {
    table_name: "new_table",
    columns: [
      {
        name: "id",
        type: "INT",
        nullable: false,
        auto_increment: true
      },
      {
        name: "name",
        type: "VARCHAR(255)",
        nullable: false
      }
    ],
    table_options: {
      shard_key: ["id"],
      sort_key: ["name"]
    }
  }
})

  7. generate_synthetic_data

    • Generate and insert synthetic data into an existing table

    • Parameters:

      • table: Name of the table to insert data into

      • count: Number of rows to generate (default: 100)

      • column_generators: Custom generators for specific columns

      • batch_size: Number of rows to insert in each batch (default: 1000)

    use_mcp_tool({
  server_name: "singlestore",
  tool_name: "generate_synthetic_data",
  arguments: {
    table: "customers",
    count: 1000,
    column_generators: {
      "customer_id": {
        "type": "sequence",
        "start": 1000
      },
      "status": {
        "type": "values",
        "values": ["active", "inactive", "pending"]
      },
      "signup_date": {
        "type": "formula",
        "formula": "NOW() - INTERVAL FLOOR(RAND() * 365) DAY"
      }
    },
    batch_size: 500
  }
})

  8. optimize_sql

    • Analyze a SQL query using PROFILE and provide optimization recommendations

    • Parameters:

      • query: SQL query to analyze and optimize

    use_mcp_tool({
  server_name: "singlestore",
  tool_name: "optimize_sql",
  arguments: {
    query: "SELECT * FROM customers JOIN orders ON customers.id = orders.customer_id WHERE region = 'west'"
  }
})

    • The response includes:

      • Original query

      • Performance profile summary (total runtime, compile time, execution time)

      • List of detected bottlenecks

      • Optimization recommendations with impact levels (high/medium/low)

      • Suggestions for indexes, joins, memory usage, and other optimizations

Running Standalone

  1. Build the server:

npm run build

  1. Run the server with MCP protocol only:

node build/index.js

  1. Run the server with both MCP and SSE protocols:

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

Using the SSE Protocol

When SSE is enabled, the server exposes the following HTTP endpoints:

  1. Root Endpoint

    GET /

    Returns server information and available endpoints.

  2. Health Check

    GET /health

    Returns status information about the server.

  3. SSE Connection

    GET /sse

    Establishes a Server-Sent Events connection for real-time updates.

  4. List Tools

    GET /tools

    Returns a list of all available tools, same as the MCP list_tools functionality.

    Also supports POST requests for MCP Inspector compatibility:

    POST /tools
Content-Type: application/json

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

  5. Call Tool

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

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

    Executes a tool with the provided arguments.

    • If client_id is provided, the response is streamed to that SSE client.

    • If client_id is omitted, the response is returned directly in the HTTP response.

    Also supports standard MCP format for MCP Inspector compatibility:

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

SSE Event Types

When using SSE connections, the server sends the following event types:

  1. message (unnamed event): Sent when an SSE connection is successfully established.

  2. open: Additional connection established event.

  3. message: Used for all MCP protocol messages including tool start, result, and error events.

All events follow the JSON-RPC 2.0 format used by the MCP protocol. The system uses the standard message event type for compatibility with the MCP Inspector and most SSE client libraries.

Example JavaScript Client

// 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));

Using with MCP Inspector

The MCP Inspector is a browser-based tool for testing and debugging MCP servers. To use it with this server:

  1. Start both the server and MCP inspector in one command:

    npm run inspector

    Or start just the server with:

    npm run start:inspector

  2. To install and run the MCP Inspector separately:

    npx @modelcontextprotocol/inspector

    The inspector will open in your default browser.

  3. When the MCP Inspector opens:

    a. Enter the URL in the connection field:

    http://localhost:8081

    Note: The actual port may vary depending on your configuration. Check the server startup logs for the actual port being used. The server will output:

    MCP SingleStore SSE server listening on port XXXX

    b. Make sure "SSE" is selected as the transport type

    c. Click "Connect"

  4. If you encounter connection issues, try these alternatives:

    a. Try connecting to a specific endpoint:

    http://localhost:8081/stream

    b. Try using your machine's actual IP address:

    http://192.168.1.x:8081

    c. If running in Docker:

    http://host.docker.internal:8081

  5. Debugging connection issues:

    a. Verify the server is running by visiting http://localhost:8081 in your browser

    b. Check the server logs for connection attempts

    c. Try restarting both the server and inspector

    d. Make sure no other service is using port 8081

    e. Test SSE connection with the provided script:

    npm run test:sse

    Or manually with curl:

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

    f. Verify your firewall settings allow connections to port 8081

  6. Once connected, the inspector will show all available tools and allow you to test them interactively.

⚠️ Note: When using the MCP Inspector, you must use the full URL, including the http:// prefix.

MCP Client Integration

Installing in Claude Desktop

  1. Add the server configuration to your Claude Desktop config file located at:

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

    • Windows: %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"
      }
    }
  }
}

The SSE_ENABLED and SSE_PORT variables are optional. Include them if you want to enable the HTTP server with SSE support alongside the standard MCP protocol.

  1. Restart the Claude Desktop App

  2. In your conversation with Claude, you can now use the SingleStore MCP server with:

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

Installing in Windsurf

  1. Add the server configuration to your Windsurf config file located at:

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

    • Windows: %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"
      }
    }
  }
}

The SSE_ENABLED and SSE_PORT variables are optional, but enable additional functionality through the SSE HTTP server.

  1. Restart Windsurf

  2. In your conversation with Claude in Windsurf, the SingleStore MCP tools will be available automatically when Claude needs to access database information.

Installing in Cursor

  1. Add the server configuration to your Cursor settings:

    • Open Cursor

    • Go to Settings (gear icon) > Extensions > Claude AI > MCP Servers

    • Add a new MCP server with the following configuration:

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

The SSE_ENABLED and SSE_PORT variables allow web applications to connect to the server via HTTP and receive real-time updates through Server-Sent Events.

  1. Restart Cursor

  2. When using Claude AI within Cursor, the SingleStore MCP tools will be available for database operations.

Security Considerations

  1. Never commit credentials to version control

  2. Use environment variables or secure configuration management

  3. Consider using a connection pooling mechanism for production use

  4. Implement appropriate access controls and user permissions in SingleStore

  5. Keep the SingleStore CA bundle up to date

Development

Project Structure

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

Building

npm run build

Testing

npm test

Troubleshooting

  1. Connection Issues

    • Verify credentials and host information in your environment variables

    • Check SSL configuration

    • Ensure database is accessible from your network

    • Check your firewall settings to allow outbound connections to your SingleStore database

  2. Build Issues

    • Clear node_modules and reinstall dependencies

    • Verify TypeScript configuration

    • Check Node.js version compatibility (should be 16+)

  3. MCP Integration Issues

    • Verify the path to the server's build/index.js file is correct in your client configuration

    • Check that all environment variables are properly set in your client configuration

    • Restart your client application after making configuration changes

    • Check client logs for any error messages related to the MCP server

    • Try running the server standalone first to validate it works outside the client

Contributing

  1. Fork the repository

  2. Create a feature branch

  3. Commit your changes

  4. Push to the branch

  5. Create a Pull Request

License

MIT License - see LICENSE file for details

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.2/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 but doesn't describe traits like whether it requires permissions, returns paginated results, includes system tables, or has rate limits. For a tool with zero annotation coverage, 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 directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, making it easy to parse 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's simplicity (0 parameters, no output schema), the description is minimally adequate but lacks details on behavioral traits due to no annotations. It covers the basic purpose but doesn't address potential complexities like result format or usage context, leaving room for improvement in completeness.

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 schema description coverage is 100%, so no parameter documentation is needed. The description doesn't add param info beyond the schema, but with no params, this is acceptable, earning a baseline score above 3 for adequate 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 ('List') and resource ('tables in the database'), making the purpose immediately understandable. It doesn't distinguish from siblings like 'describe_table' or 'query_table', which would require more specificity about what 'list' entails versus those alternatives.

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 'query_table' (for querying table contents). It lacks explicit when/when-not instructions or named alternatives, leaving usage context implied at best.

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

  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
Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

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

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

  • 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
    30
    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.
    17
    MIT

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/madhukarkumar/singlestore-mcp-server'

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