Skip to main content
Glama
seek-your-way-out

Cloudflare D1 Database MCP Server

Cloudflare SYWO MCP Server

A minimal Model Context Protocol (MCP) server that lets MCP-compatible clients query a Cloudflare D1 database. Designed for easy setup and usage.

Features

  • List tables in the target D1 database with the d1_list_tables tool.

  • Run arbitrary SQL queries using the d1_query tool.

  • Lightweight TypeScript implementation relying on Cloudflare's REST API.

  • Cross-platform support with proper Windows, macOS, and Linux compatibility.

  • Secure credential management via environment variables.

Related MCP server: SQLx MCP Server

Prerequisites

  • Node.js 18+

  • Cloudflare Account ID

  • Cloudflare D1 Database ID

  • Cloudflare D1 Database Name

  • Cloudflare API Token with D1:Edit permissions

Quick Start (5 Minutes)

  1. Install the server:

    npm install -g cloudflare-sywo-mcp-server
  2. Get your Cloudflare credentials (takes 2 minutes):

    • Account ID: Cloudflare Dashboard → Right sidebar

    • Database ID: Cloudflare Dashboard → D1 → Your database → "Database ID"

    • Database Name: The name you gave your D1 database

    • API Token: Cloudflare Dashboard → My Profile → API Tokens → Create Token → Custom token with D1:Edit permission

  3. Add to VS Code (copy-paste into settings.json):

    {
      "mcp.servers": {
        "cloudflare-d1": {
          "command": "cloudflare-sywo-mcp",
          "args": ["--stdio"],
          "env": {
            "CLOUDFLARE_ACCOUNT_ID": "your-account-id-here",
            "CLOUDFLARE_D1_DATABASE_ID": "your-database-id-here", 
            "CLOUDFLARE_D1_DATABASE_NAME": "your-database-name-here",
            "CLOUDFLARE_API_TOKEN": "your-api-token-here"
          }
        }
      }
    }
  4. Restart VS Code and you're done!

Installation

npm install -g cloudflare-sywo-mcp-server

Setup

After installing globally with npm install -g cloudflare-sywo-mcp-server, you can use it directly in your MCP configuration.

Option 2: Local Development/Custom Build

If you want to build from source or modify the server:

  1. Clone or download this repository

  2. Install dependencies:

    npm install
  3. Create a .env file (do not commit it) and provide credentials:

    CLOUDFLARE_ACCOUNT_ID=your-account-id-here
    CLOUDFLARE_D1_DATABASE_ID=your-database-id-here
    CLOUDFLARE_D1_DATABASE_NAME=your-database-name-here
    CLOUDFLARE_API_TOKEN=your-api-token-here
  4. Build the TypeScript project:

    npm run build
  5. Start the MCP server:

    npm start

    Or use the development runner:

    npm run dev

MCP Client Configuration

VS Code Setup (Step-by-Step)

For VS Code users, here's exactly what to do:

  1. Install the MCP server globally:

    npm install -g cloudflare-sywo-mcp-server
  2. Find your VS Code MCP settings file:

    • Open VS Code Command Palette (Ctrl+Shift+P or Cmd+Shift+P)

    • Type "Open User Settings (JSON)"

    • Look for or create the file: %APPDATA%\Code\User\settings.json (Windows) or ~/.config/Code/User/settings.json (Mac/Linux)

  3. Add the MCP configuration to your settings.json:

    Option A: Direct Environment Variables (Recommended)

    {
      "mcp.servers": {
        "cloudflare-d1": {
          "command": "cloudflare-sywo-mcp",
          "args": ["--stdio"],
          "env": {
            "CLOUDFLARE_ACCOUNT_ID": "your-actual-account-id",
            "CLOUDFLARE_D1_DATABASE_ID": "your-actual-database-id", 
            "CLOUDFLARE_D1_DATABASE_NAME": "your-actual-database-name",
            "CLOUDFLARE_API_TOKEN": "your-actual-api-token"
          }
        }
      }
    }

    Option B: Using .env File

    {
      "mcp.servers": {
        "cloudflare-d1": {
          "command": "cloudflare-sywo-mcp",
          "args": ["--stdio"],
          "cwd": "C:/path/to/your/project/folder"
        }
      }
    }
  4. Where to get your Cloudflare credentials:

    • Account ID: Cloudflare Dashboard → Right sidebar under "Account ID"

    • Database ID: Cloudflare Dashboard → D1 → Your database → "Database ID"

    • Database Name: The name you gave your D1 database

    • API Token: Cloudflare Dashboard → My Profile → API Tokens → Create Token → Use "Custom token" with D1:Edit permission

  5. No additional files needed! The credentials go directly in the VS Code settings.json file or in a .env file if you choose that option.

Cursor / Trae Configuration

Add this to your MCP configuration file:

{
  "mcpServers": {
    "cloudflare-d1": {
      "command": "cloudflare-sywo-mcp",
      "args": ["--stdio"],
      "env": {
        "CLOUDFLARE_ACCOUNT_ID": "your-account-id-here",
        "CLOUDFLARE_D1_DATABASE_ID": "your-database-id-here",
        "CLOUDFLARE_D1_DATABASE_NAME": "your-database-name-here",
        "CLOUDFLARE_API_TOKEN": "your-api-token-here"
      }
    }
  }
}

Windows Command Line Configuration

For Windows users, you may need to use the full command path or cmd syntax:

{
  "mcpServers": {
    "cloudflare-d1": {
      "command": "cmd",
      "args": ["/c", "set CLOUDFLARE_ACCOUNT_ID=your-account-id-here && set CLOUDFLARE_D1_DATABASE_ID=your-database-id-here && set CLOUDFLARE_D1_DATABASE_NAME=your-database-name-here && set CLOUDFLARE_API_TOKEN=your-api-token-here && cloudflare-sywo-mcp --stdio"]
    }
  }
}

Alternative: Using .env File

You can also use a .env file in your project directory:

{
  "mcpServers": {
    "cloudflare-d1": {
      "command": "cloudflare-sywo-mcp",
      "args": ["--stdio"],
      "cwd": "/path/to/your/project"
    }
  }
}

Make sure to keep your API token secret and rotate immediately if it is ever exposed.

Credential Management Options

Put credentials directly in your MCP configuration file. This is the simplest approach.

Option 2: .env File (Good for Development)

Create a .env file in your project directory:

CLOUDFLARE_ACCOUNT_ID=your-account-id-here
CLOUDFLARE_D1_DATABASE_ID=your-database-id-here
CLOUDFLARE_D1_DATABASE_NAME=your-database-name-here
CLOUDFLARE_API_TOKEN=your-api-token-here

Then reference the directory in your MCP config:

{
  "mcpServers": {
    "cloudflare-d1": {
      "command": "cloudflare-sywo-mcp",
      "args": ["--stdio"],
      "cwd": "/path/to/your/project"
    }
  }
}

Option 3: System Environment Variables (Advanced)

Set the variables in your system environment, then use a minimal MCP config:

{
  "mcpServers": {
    "cloudflare-d1": {
      "command": "cloudflare-sywo-mcp",
      "args": ["--stdio"]
    }
  }
}

Windows: Set via System Properties → Environment Variables macOS/Linux: Add to ~/.bashrc or ~/.zshrc:

export CLOUDFLARE_ACCOUNT_ID="your-account-id-here"
export CLOUDFLARE_D1_DATABASE_ID="your-database-id-here"
export CLOUDFLARE_D1_DATABASE_NAME="your-database-name-here"
export CLOUDFLARE_API_TOKEN="your-api-token-here"

Tools Summary

  • d1_list_tables: Returns an array of table names from the database.

  • d1_query: Executes a SQL query and returns the raw D1 response payload.

Troubleshooting

Connection Issues

If you encounter "Connection closed" errors:

  1. Ensure all required environment variables are set correctly

  2. Check that your Cloudflare API token has the necessary permissions (D1:Edit)

  3. Verify your account ID, database ID, and database name are correct

Windows-Specific Issues

If you see "Syntax Error" from Windows Script Host or "how do I want to open this" popups:

  • Make sure you're using version 1.0.7 or later (we fixed Windows compatibility issues)

  • Use the Windows command line configuration shown above

  • Ensure Node.js is properly installed and in your PATH

JSON Parsing Errors

If you see "Unexpected token" JSON parsing errors:

  • Update to the latest version (1.0.7+) which suppresses debug output

  • Check that no other processes are writing to stdout/stderr

Security Note

Never commit API tokens to source control. If a token becomes exposed, revoke it in the Cloudflare dashboard and create a fresh one.

Available Tools

2 tools
d1_list_tablesB

List tables available in the Cloudflare D1 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 does not describe traits like whether it's read-only, requires authentication, has rate limits, or what the output format might be. This leaves significant gaps in understanding how the tool behaves beyond its basic function.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

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

The description is a single, clear sentence that directly states the tool's purpose without any fluff or redundant information. It is front-loaded and appropriately sized for a simple tool with no parameters.

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, no annotations), the description is minimally adequate but lacks depth. It covers the basic action but does not provide context on behavioral traits or output, which could be important for an agent to use it effectively in a broader workflow.

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 input schema has 100% description coverage (though empty). The description does not need to add parameter details, so it appropriately avoids redundancy. A baseline score of 4 is given as it efficiently handles the lack of parameters without unnecessary information.

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 ('List') and resource ('tables available in the Cloudflare D1 database'), making the purpose immediately understandable. However, it does not explicitly differentiate from its sibling tool 'd1_query', which might also involve table operations, 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 the sibling 'd1_query'. It lacks any mention of prerequisites, context, or exclusions, leaving the agent to infer usage based solely on the tool name and description.

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

d1_queryC

Run a SQL query against the configured Cloudflare D1 database.

ParametersJSON Schema
NameRequiredDescriptionDefault
sqlYesThe SQL statement to execute.
bindingsNoOptional positional bindings for the SQL statement.

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 tool runs SQL queries but doesn't cover critical aspects like whether it's read-only or can perform mutations, authentication requirements, rate limits, error handling, or output format. For a database query tool with zero annotation coverage, this is a significant gap.

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 and avoids unnecessary elaboration, making it easy for an agent to parse quickly.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a database query tool with no annotations and no output schema, the description is incomplete. It lacks information on behavioral traits (e.g., read/write permissions, safety), output structure, or error conditions. This leaves the agent under-informed for effective tool invocation.

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 both parameters ('sql' and 'bindings') adequately. The description doesn't add any parameter-specific details beyond what the schema provides, such as SQL dialect constraints or binding usage examples. Baseline 3 is appropriate when 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 ('Run a SQL query') and target resource ('configured Cloudflare D1 database'), making the purpose unambiguous. It distinguishes from the sibling tool 'd1_list_tables' by focusing on query execution rather than metadata listing. However, it doesn't explicitly contrast with the sibling, so it's not a perfect 5.

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 the sibling tool 'd1_list_tables' or any other potential tools, nor does it specify use cases, prerequisites, or exclusions. This leaves the agent with minimal context for tool selection.

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. 1 tool updatev1.0.0
    • Changedd1_list_tables1 field changed
      • addedInput schema / additionalProperties
        Added value: +false
  2. 2 tool updates
    • First observedd1_list_tables
    • First observedd1_query

TDQS

B3.1/5.0

Scored across 2 tools

Disambiguation5/5

The two tools have completely distinct purposes: one lists tables (metadata operation) and the other executes SQL queries (data operation). There is no overlap or ambiguity between these functions, making it impossible for an agent to confuse them.

Naming Consistency5/5

Both tools follow a consistent 'd1_verb_noun' naming pattern with clear, descriptive names. The prefix 'd1_' identifies the domain, and the verb-noun structure (list_tables, query) is uniformly applied across all tools.

Tool Count2/5

With only 2 tools, this server feels severely under-scoped for a database management system. While the tools cover basic operations, typical database interfaces require more functionality (e.g., create/delete tables, schema management, transaction support) to be practically useful for agents.

Completeness2/5

The toolset is significantly incomplete for database operations. While listing tables and running queries are foundational, there are major gaps: no table creation/deletion, no schema modification, no transaction control, and no specialized query helpers. This will cause agent failures for common database workflows.

Maintenance

ActivityInactive
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    Not graded
    quality
    D
    maintenance
    Provides access to database schema information generated by tbls and enables secure SQL query execution on MySQL and SQLite databases. Allows users to explore database structures, table relationships, and execute SELECT queries through natural language interactions.
    -
  • A
    license
    Not graded
    quality
    C
    maintenance
    Provides comprehensive database management tools for PostgreSQL, MySQL, and SQLite databases. Enables querying table structures, executing read-only and write queries, exporting DDL statements, and managing database metadata through natural language.
    7 npm
    MIT
  • A
    license
    Not graded
    quality
    C
    maintenance
    Enables exploring and querying SQLite databases through natural language, with tools to list tables, describe table structures, and run SELECT queries.
    MIT