# Cloudflare MCP MCP

> Cloudflare MCP gives your agent full control over edge infrastructure. Manage serverless functions, update secrets, query databases, and monitor performance across Workers, KV, D1, and R2—all via natural language commands.

## Overview
- **Category:** ai-frontier
- **Price:** Free
- **Tags:** serverless, edge-computing, infrastructure-as-code, api-management, deployment-automation, secrets-management

## Description

This connector lets you treat Cloudflare's entire platform like a single API endpoint accessible through conversation. Instead of running complex CLI scripts or clicking through multiple dashboards to update your edge application, you simply tell your agent what needs doing. You can manage everything from deploying new worker versions and routing traffic patterns to querying internal key-value stores (KV) and executing structured SQL against D1 databases. It’s about operational control at scale; your agent handles the sequence of steps required for continuous deployment, secret rotation, and debugging. Because credentials pass through a zero-trust proxy on Vinkius, your keys never sit on a disk—they're only used in transit. This means you get deep platform access without compromising security. You’ll gain visibility into every call via Vinkius AI Analytics, knowing exactly what data flowed and how the budget is being spent.

## Tools

### create_deployment
Rolls out a specific worker version to traffic, allowing immediate or gradual percentage-based rollouts.

### create_secret
Creates or updates an encrypted environment secret, like an API key or password, for a worker.

### create_tail_session
Starts a live log stream connection to debug a running worker in production.

### create_worker_route
Assigns a specific URL pattern or domain to point traffic directly at your worker script.

### delete_secret
Removes an unused secret from a worker, revoking access to that credential.

### delete_tail_session
Ends a live log streaming session when debugging is finished.

### delete_worker
Permanently removes an entire worker script and all associated resources.

### delete_worker_route
Stops a specific URL pattern from pointing to your worker, effectively unpublishing it at that path.

### get_kv_key
Reads the raw value of a single key stored within a KV namespace.

### get_worker
Retrieves detailed configuration information about an existing worker script.

### get_worker_analytics
Pulls performance data for a worker, showing recent invocations and error rates.

### get_worker_version
Fetches detailed metadata about a specific version snapshot of a worker script.

### get_zone_analytics
Gathers aggregated traffic data for an entire DNS zone over the last 24 hours.

### list_d1_databases
Provides a list of all available SQLite databases you can run queries against.

### list_deployments
Lists every deployment attempt, including the strategy and current traffic split for a worker.

### list_kv_keys
Provides an index of key names within a KV namespace before you read any data.

### list_kv_namespaces
Lists all existing KV namespaces to determine where your configuration data is stored.

### list_r2_buckets
Shows the names and locations of all object storage buckets (R2) in your account.

### list_secrets
Lists configured secrets for a worker, showing their name and type without revealing the value.

### list_worker_routes
Shows all active URL patterns that currently point to your workers.

### list_worker_versions
Lists every historical code snapshot of a worker, allowing you to audit its deployment history.

### list_workers
Lists all active and inactive worker scripts across your account by name and status.

### list_zones
Returns a list of all DNS zones managed under your Cloudflare account ID.

### purge_cache
Forces the clearing of cached content for an entire zone, ensuring fresh data is served immediately.

### query_d1
Executes a structured SQL query against a specific D1 database instance.

## Prompt Examples

**Prompt:** 
```
List all serverless Cloudflare Workers deployed natively bound to my account.
```

**Response:** 
```
Pulling instances via `list_workers`. Extracting exactly 5 active edge-computation scripts securely operating on your endpoints mapping perfectly.
```

**Prompt:** 
```
Query the KV namespace assigned to 'production_keys' and extract the specific text mapping 'gateway_url'.
```

**Response:** 
```
Connecting KV namespaces natively... Resolved variable payload matching 'gateway_url': `api.vinkius.cloud` loaded efficiently without cache interference.
```

**Prompt:** 
```
Check error statistics on my main D1 SQLite database instance over the last 24 hours.
```

**Response:** 
```
Parsing telemetry array from metrics. The D1 metrics reveal stable instances with precisely 0% crash loops inside the isolated runtime edges.
```

## Capabilities

### Manage Deployments
Roll out worker versions with specific traffic percentages or instantly revert to previous stable states.

### Secure Credentials
Create, read, and delete encrypted runtime secrets for your edge functions.

### Control Traffic Routing
Direct specific URL paths or domains to a designated worker script.

### Read/Write Key-Value Data
Access configuration settings or cached data stored in KV namespaces.

### Execute SQL Queries
Run structured SELECT, INSERT, UPDATE, and DELETE commands against your D1 database.

### Monitor Performance Metrics
Retrieve zone traffic data or specific worker invocation statistics to find bottlenecks.

## Use Cases

### Rolling out a critical fix with confidence
A developer pushes code and needs it live. They ask their agent to deploy the new version using `create_deployment` with a gradual rollout (5% traffic). The agent monitors initial error rates via `get_worker_analytics`, confirms stability, and then completes the full 100% rollout.

### Debugging a production failure
The site starts failing. Instead of guessing, they tell their agent to create a tail session (`create_tail_session`). The agent streams real-time logs back to the chat interface until the root cause is found.

### Auditing data access before migration
An SRE needs to know what's stored in a specific area. They run `list_kv_namespaces` first, then check for keys using `list_kv_keys`, allowing them to safely pull the required config via `get_kv_key`.

### Cleaning up old infrastructure
The platform has several abandoned worker scripts. The architect uses `list_workers` to find all inactive resources, then confirms their status before using `delete_worker` on the unused ones.

## Benefits

- Instead of manually checking `list_workers` to see what's running, your agent can get detailed worker information using `get_worker`, giving you a quick status check without digging through dashboards.
- When you update credentials, you don't have to remember the name; simply tell your agent to create or delete secrets, and it handles the call via `create_secret` or `delete_secret`.
- Need to roll back code? You can list versions with `list_worker_versions`, then use `get_worker_version` to pick the exact snapshot ID before calling `create_deployment`.
- Debugging complex paths is simple. Instead of guessing, you first run `list_worker_routes` and then tell your agent which specific route pattern needs a new worker assigned using `create_worker_route`.
- Data integrity checks are easier than ever. You can query available databases with `list_d1_databases`, then execute a precise data retrieval or migration command using `query_d1`.
- When you deploy content changes, remember to use the agent's ability to purge the cache via `purge_cache`. This ensures users see fresh origin data immediately.

## How It Works

The bottom line is you control complex infrastructure changes using plain English commands.

1. First, provide your AI agent with the necessary Cloudflare API tokens and account ID.
2. Next, tell the agent the goal: for example, 'Roll back Worker X to version 4' or 'Query the user record for key Y'.
3. The agent translates that request into a series of secure tool calls, executes them against the platform, and returns the result.

## Frequently Asked Questions

**How do I check if a worker is actually running with the Cloudflare MCP?**
Use `list_workers` to see all scripts deployed in your account. You can then use `get_worker_analytics` to get real-time performance data on its invocations.

**Can I query my database without writing a CLI command? (query_d1)**
Yes, you pass the exact SQL query string directly to your agent. The MCP handles connecting to the D1 database and executing the `query_d1` operation for you.

**What is the best way to audit my secrets? (list_secrets)**
Run `list_secrets`. This shows every secret name configured for a worker, letting you confirm what credentials exist without revealing their actual values.

**How do I make sure users see my changes instantly? (purge_cache)**
After deploying or updating static assets, you must use the `purge_cache` tool. This forces Cloudflare to clear old cached content for that zone and pull fresh data.

**If I need to audit general traffic spikes or CDN performance across my whole site, how do I use `get_zone_analytics`?**
You run `get_zone_analytics` to pull aggregated data for the last 24 hours. This gives you a high-level view of total traffic and overall zone health, helping identify usage spikes or regional issues.

**Before rolling out code changes, how can I use `list_deployments` to audit my rollout status?**
Use `list_deployments` to see every deployment ID and version ID. This shows the current strategy (immediate or gradual) and exactly what percentage of traffic is hitting which worker version.

**I need to know all available key-value data containers before writing data, so how do I use `list_kv_namespaces`?**
Call `list_kv_namespaces` first. It returns the IDs and titles of every key-value store in your account, letting you map out all the storage areas before attempting to read or write any keys.

**How do I use `list_worker_routes` to audit which URLs currently trigger my Cloudflare Workers?**
Run `list_worker_routes` to see every route pattern and its associated script name. This is critical for knowing exactly what URLs are hitting your workers before you change or remove any paths.