The official Convex MCP server, built into the Convex CLI, that lets AI agents introspect and query a Convex deployment — listing tables, paginating data, running deployed functions and read-only one-off queries, reading logs and function specs, and managing environment variables — with production deployments blocked by default as a safety measure.
Production deployments are blocked by default; accessing them requires the explicit `--dangerously-enable-production-deployments` flag, which then allows reading and modifying live production data., The `run` tool executes deployed Convex functions (including mutations) and the env tools (`envSet`, `envRemove`) change deployment configuration, so these can modify a deployment., The `runOneoffQuery` tool runs sandboxed JavaScript that is read-only and cannot modify data, but `data`/`tables` can read arbitrary documents from the deployment., Per the docs, setting `--project-dir` does not stop an agent from passing a custom `projectDir` in the status tool or acting on deployments of other projects; restrict access accordingly., Use `--disable-tools` (e.g. `data,run,envSet`) to narrow what the server can do, and keep it pointed at a development deployment when an agent acts autonomously.
Privacy notes
The server connects to your Convex deployment using your local CLI credentials; table listings, documents, logs, and function specs it returns are passed to the LLM/MCP client., Document data can include sensitive or PII fields stored in your tables, and log output can contain request data., Environment-variable tools (`envGet`, `envList`) can read deployment configuration, which may include secrets; treat that output as sensitive., The server reads your local Convex project directory to resolve deployments; keep credentials and any custom `--env-file` out of version control.
Author
get-convex
Submitted by
davion-knight
Claim status
unclaimed
Last verified
2026-07-08
Decision playbook
Review trust signals before you adopt
Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.
Compare context
Selected
0
Current score
78
Baseline
—
Delta
No baseline selected
No major trust-signal divergence detected in the current selection.
Source and provenance checks
Complete
Confirm ownership and provenance before trusting install instructions.
Source link availableRequired
Open the canonical repository and verify ownership.
Done
Source provenance statusRequired
Marked as source-backed.
Done
Metadata reviewed
Registry metadata indicates a reviewed listing.
Done
Safety and privacy checks
Complete
Validate risk disclosures before installation or API wiring.
Safety notes presentRequired
Review the listed safety guidance before running commands.
Done
Privacy notes presentRequired
Review data handling notes before connecting accounts or secrets.
Done
Trust level risk gateRequired
Trust level does not block evaluation.
Done
Package and install checks
Needs review
Check package metadata and artifact integrity signals.
Install payload available
Install or copy payload is available for review.
Done
Package verification flag
No package verification flag provided.
Pending
Checksum metadata
No checksum provided for downloaded artifact.
Pending
Compare-driven decision checks
Needs review
Use compare context to validate trade-offs before adoption.
Compare tray has multiple entries
Add at least one more entry to compare trust differences.
Pending
Baseline comparison available
No baseline peer selected yet.
Pending
Diverging trust signals identified
No major trust-signal divergence found.
Pending
Adoption plan
Balanced adoption plan
Current risk score 16/100. Use staged verification before broader rollout.
Risk 16
Pre-adoption checks
Validate source and review signals before any execution.
Confirm source provenanceRequired
Source URL/provenance metadata is present.
Done
Confirm metadata review state
Listing has review metadata.
Done
Verify install payload
Install/config payload exists and can be inspected.
Done
Security checks
Confirm safety, privacy, and package integrity signals.
Review safety notesRequired
Safety notes are present.
Done
Review privacy notesRequired
Privacy notes are present.
Done
Verify package integrity metadata
No package verification/checksum metadata.
Pending
Rollout
Adopt in controlled steps based on the selected plan.
Run in isolated sandbox firstRequired
Use a constrained sandbox and observe behavior across multiple tasks.
Pending
Roll out graduallyRequired
Roll out to a small cohort before wider usage.
Pending
Set monitoring and fallback
Define rollback path and monitor errors after adoption.
Pending
Evidence readiness
Evidence readiness matrix · balanced
Required evidence gates are covered (5/6 signals complete).
Risk 15
Source provenance
Present
Source repository/provenance is listed.
Required in this preset
Metadata review
Present
Review metadata is present.
Required in this preset
Safety notes
Present
Safety notes are present.
Required in this preset
Privacy notes
Present
Privacy notes are present.
Optional in this preset
Package integrity
Missing
Package integrity metadata is missing.
Optional in this preset
Install payload
Present
Install payload is available.
Required in this preset
Required evidence gates are covered for this preset.
Decision timeline
Decision timeline · balanced
5/6 steps complete with no blocking gaps for this preset.
Risk 14
triage
Confirm source provenanceRequired
Source/provenance metadata is available.
Done
triage
Check metadata review statusRequired
Review metadata is available.
Done
verify
Review safety notesRequired
Safety notes are available.
Done
verify
Review privacy notes
Privacy notes are available.
Done
verify
Validate package integrity metadata
Package integrity metadata is missing.
Pending
rollout
Verify install payload and commandsRequired
Install payload is available.
Done
No required blockers for this timeline preset.
Safety notes
Production deployments are blocked by default; accessing them requires the explicit `--dangerously-enable-production-deployments` flag, which then allows reading and modifying live production data.
The `run` tool executes deployed Convex functions (including mutations) and the env tools (`envSet`, `envRemove`) change deployment configuration, so these can modify a deployment.
The `runOneoffQuery` tool runs sandboxed JavaScript that is read-only and cannot modify data, but `data`/`tables` can read arbitrary documents from the deployment.
Per the docs, setting `--project-dir` does not stop an agent from passing a custom `projectDir` in the status tool or acting on deployments of other projects; restrict access accordingly.
Use `--disable-tools` (e.g. `data,run,envSet`) to narrow what the server can do, and keep it pointed at a development deployment when an agent acts autonomously.
Privacy notes
The server connects to your Convex deployment using your local CLI credentials; table listings, documents, logs, and function specs it returns are passed to the LLM/MCP client.
Document data can include sensitive or PII fields stored in your tables, and log output can contain request data.
Environment-variable tools (`envGet`, `envList`) can read deployment configuration, which may include secrets; treat that output as sensitive.
The server reads your local Convex project directory to resolve deployments; keep credentials and any custom `--env-file` out of version control.
Prerequisites
Node.js and npm (the server runs via `npx -y convex@latest mcp start`)
A Convex project and account; the CLI uses your existing Convex login for deployment access
A Convex deployment to target (the dev deployment is used by default; production is opt-in)
An MCP-compatible client (Claude Desktop, Cursor, VS Code, Windsurf, etc.)
The Convex MCP Server is the official Model Context Protocol server from
Convex, built directly into the Convex CLI. It gives LLMs and
agentic clients introspection and query access to a Convex deployment — listing tables,
paginating data, running deployed functions and read-only one-off queries, reading
logs and function specs, surfacing query insights, and managing environment
variables.
The server ships in the convex npm package (v1.42.1,
Apache-2.0) and runs with npx -y convex@latest mcp start over stdio. It connects to your Convex
deployment using your existing CLI login, targets the development deployment by default, and
blocks production deployments unless you explicitly opt in — a deliberate safety measure. Full
documentation lives in the Convex MCP docs.
Source Review
The following real sources were fetched and reviewed for this entry:
Convex MCP docs — the mcp start command, deployment-selection flags (--prod, --preview-name, --deployment-name, --env-file, --project-dir), the production-deployment safety gate, --disable-tools, and the full tool list.
npm: convex — package name and version (1.42.1) and Apache-2.0 license; the mcp subcommand ships in this package.
Repository facts confirmed at review time: official get-convex organization, not archived, actively
maintained, with the MCP server distributed via the convex CLI package v1.42.1 on npm.
Features
Deployment selection — status finds available deployments and returns a selector used by the other tools; flags choose dev, preview, named, or (opt-in) production deployments.
Table & data introspection — tables lists tables and metadata; data paginates documents in a table.
Read-only queries — runOneoffQuery runs sandboxed, read-only JavaScript queries against the deployment's data.
Function tools — run executes deployed Convex functions and functionSpec returns function metadata.
--project-dir /path/to/project — resolve deployments from a specific project directory.
--deployment-name <name> / --preview-name <name> — target a specific or preview deployment.
--prod with --dangerously-enable-production-deployments — target production (use with care).
--disable-tools data,run,envSet — restrict which tools are exposed.
Use Cases
Schema and data exploration — let an agent enumerate tables and page through documents to understand a deployment.
Read-only analytics — run sandboxed one-off queries to answer questions without mutating data.
Function debugging — inspect function specs, run functions, and read logs during development.
Query optimization — use insights to surface slow or problematic query patterns.
Environment management — review and update deployment environment variables from an agentic workflow.
Safety and Privacy
Production is opt-in. The server refuses production deployments unless --dangerously-enable-production-deployments is set; enabling it allows reading and modifying live data.
Some tools mutate.run can invoke mutations and envSet/envRemove change configuration; runOneoffQuery is read-only by design.
Scope with flags. Use --disable-tools and keep the server on a development deployment when an agent acts autonomously; note --project-dir does not fully prevent access to other projects.
Data flows to the model. Tables, documents, logs, and function specs are returned to the LLM/MCP client and can include PII; env-var tools can reveal secrets.
Credential hygiene. The server uses your local Convex CLI login and project directory — keep credentials and any custom --env-file out of version control.
Duplicate Check
No existing entry in the directory matches this server. A search of all directory entries for
"convex" across slugs, titles, repository URLs, and install commands returned no results, and there
is no prior entry pointing at github.com/get-convex/convex-backend or the Convex CLI mcp
subcommand. This is therefore a net-new, non-duplicate entry.
Show that Convex MCP Server is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.
[](https://heyclau.de/entry/mcp/convex-mcp-server)
How it compares
Convex MCP Server side by side with 3 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.
1 trust signal differ across this comparison (Submitter).
The official Convex MCP server, built into the Convex CLI, that lets AI agents introspect and query a Convex deployment — listing tables, paginating data, running deployed functions and read-only one-off queries, reading logs and function specs, and managing environment variables — with production deployments blocked by default as a safety measure.
The official InfluxData MCP server for InfluxDB 3 (Core, Enterprise, Cloud Dedicated, Clustered, and Cloud Serverless). It lets LLMs run SQL queries, write line-protocol data, inspect databases and measurement schemas, manage databases and tokens, and check cluster health over the Model Context Protocol.
The official OpenSearch Project MCP server (opensearch-mcp-server-py) that lets AI assistants query and operate OpenSearch clusters — listing indices, reading mappings, running Query DSL and PPL searches, inspecting shards and cluster health — over stdio or streaming transports, with basic-auth, AWS IAM, and header-based authentication.
An MCP server from the official Couchbase-Ecosystem org that lets LLMs interact directly with Couchbase clusters — running SQL++/N1QL queries, performing document CRUD, discovering schema and data models, and analyzing query performance, with a read-only mode enabled by default.
✓Production deployments are blocked by default; accessing them requires the explicit `--dangerously-enable-production-deployments` flag, which then allows reading and modifying live production data.
The `run` tool executes deployed Convex functions (including mutations) and the env tools (`envSet`, `envRemove`) change deployment configuration, so these can modify a deployment.
The `runOneoffQuery` tool runs sandboxed JavaScript that is read-only and cannot modify data, but `data`/`tables` can read arbitrary documents from the deployment.
Per the docs, setting `--project-dir` does not stop an agent from passing a custom `projectDir` in the status tool or acting on deployments of other projects; restrict access accordingly.
Use `--disable-tools` (e.g. `data,run,envSet`) to narrow what the server can do, and keep it pointed at a development deployment when an agent acts autonomously.
✓The server exposes write and delete tools — `write_line_protocol` ingests data, `create_database`/`update_database` change database config, and `delete_database` permanently removes a database (the README marks it irreversible).
On Core/Enterprise it can mint and revoke credentials via `create_admin_token` (full permissions), `create_resource_token`, and `delete_token`; `regenerate_operator_token` is flagged dangerous/irreversible and rotates the operator token.
The `execute_query` tool runs arbitrary SQL against the target database with the supplied token's permissions, so scope the token to least privilege rather than relying on tool naming.
Cloud Dedicated/Clustered token tools (`cloud_create_database_token`, `cloud_update_database_token`, `cloud_delete_database_token`) manage real database access grants on the cluster.
Point the server at a non-production instance or a tightly scoped token when letting an agent act autonomously; token permissions are the authoritative boundary, not the tool list.
✓Core tools are read/query-oriented, but the default-enabled GenericOpenSearchApiTool can call ANY OpenSearch API endpoint with a custom path, method, and body — including write and delete operations within the credential's permissions.
Opt-in categories add mutating tools; for example the memory and agentic-memory tools can create and delete stored memories (including delete-by-query), and search-relevance tools can create and delete configurations, query sets, judgments, and experiments.
Access is bounded by the OpenSearch credential and cluster RBAC, not by tool naming — scope the user/role to least privilege and prefer a non-production cluster when an agent acts autonomously.
Dynamic connection parameters let an agent pass `opensearch_url` and auth values per tool call, so a single running server can be pointed at multiple clusters; restrict which endpoints and credentials are available to the agent.
In streaming (SSE/Streamable HTTP) mode the server listens on a network port; do not expose it on a public interface without authentication in front of it.
✓Read-only mode is ON by default (`CB_MCP_READ_ONLY_MODE=true`), which disables all KV write tools (upsert, insert, replace, delete) and blocks SQL++ modification queries.
Setting `CB_MCP_READ_ONLY_MODE=false` exposes write tools that can insert, replace, upsert, and delete documents — and SQL++ statements can run arbitrary mutations within the user's permissions.
SQL++/N1QL is a full query language; a sufficiently privileged connection can read, modify, or drop data, so scope database RBAC roles tightly to what the agent should touch.
Tool gating via `CB_MCP_DISABLED_TOOLS` / `CB_MCP_CONFIRMATION_REQUIRED_TOOLS` is, per the README, an additional layer to guide LLM behavior and reduce attack surface — not the sole security control. Database RBAC is the authoritative boundary.
In HTTP/SSE transport modes the server listens on a network port (default `127.0.0.1:8000`); avoid binding it to a public interface without authentication in front of it.
Privacy notes
✓The server connects to your Convex deployment using your local CLI credentials; table listings, documents, logs, and function specs it returns are passed to the LLM/MCP client.
Document data can include sensitive or PII fields stored in your tables, and log output can contain request data.
Environment-variable tools (`envGet`, `envList`) can read deployment configuration, which may include secrets; treat that output as sensitive.
The server reads your local Convex project directory to resolve deployments; keep credentials and any custom `--env-file` out of version control.
✓The server connects to your live InfluxDB 3 instance with the token you supply; query results, measurement schemas, and database listings it returns are passed to the LLM/MCP client.
Time-series records and tags can contain sensitive or identifying data (device IDs, user IDs, locations, metrics), and query/schema tools can surface those fields to the model.
Token-management tools can list and reveal token metadata; treat created tokens and their scopes as secrets.
Credentials (`INFLUX_DB_TOKEN`, instance URL, cluster ID) are provided through environment variables in your MCP client config — keep that config out of version control and restrict access to it.
✓The server connects to your OpenSearch cluster with the credentials you supply; index documents, mappings, and search results it returns are passed to the LLM/MCP client and can include sensitive or PII fields stored in your indices.
Cluster-introspection tools (shards, nodes, cluster state/health, allocation, hot threads, tasks) can expose infrastructure metadata such as node hosts, system metrics, and index settings.
Credentials are provided via environment variables or per-call parameters — basic-auth passwords, AWS IAM role ARNs, and AWS profiles/keys — so keep client config out of version control and restrict access to it.
Memory and agentic-memory tools persist agent-authored statements into OpenSearch; treat that stored content and any semantic enrichment as retained data.
✓The server connects to your live Couchbase cluster with the credentials you supply; any document data, schema, and query results it returns are passed to the LLM/MCP client.
Schema-discovery and CRUD tools can surface real records, including any sensitive or PII fields stored in your buckets, scopes, and collections.
Performance-analysis tools read from the query monitoring catalog (e.g. completed/running queries), which can expose query text and parameters processed by the cluster.
Credentials (connection string, username/password, or cert/key paths) are provided via environment variables in your MCP client config — store that config securely and avoid committing it.
Prerequisites
Node.js and npm (the server runs via `npx -y convex@latest mcp start`)
A Convex project and account; the CLI uses your existing Convex login for deployment access
A Convex deployment to target (the dev deployment is used by default; production is opt-in)
An MCP-compatible client (Claude Desktop, Cursor, VS Code, Windsurf, etc.)
Node.js 20.11 or newer and npm 9 or newer (for the npm/npx runtime), or Docker as an alternative
A reachable InfluxDB 3 instance — Core, Enterprise, Cloud Serverless, Cloud Dedicated, or Clustered
An InfluxDB token (and, for Cloud Dedicated, the cluster ID) with the permissions you want the agent to have
The correct `INFLUX_DB_PRODUCT_TYPE` for your deployment (`core`, `enterprise`, `cloud-serverless`, `cloud-dedicated`, or `clustered`)
Python 3.10 or newer and the `uv`/`uvx` package manager (or `pip install opensearch-mcp-server-py`)
A reachable OpenSearch cluster — self-managed, Amazon OpenSearch Service, or OpenSearch Serverless
Credentials for the chosen auth method — basic auth (username/password), AWS IAM role/profile, or header-based auth
An MCP-compatible client (Claude Desktop, Claude Code, Cursor, Kiro, VS Code, etc.)
Python 3.10+ (the package supports >=3.10,<3.15)
The `uv`/`uvx` package manager (or Docker as an alternative runtime)
A running Couchbase cluster (self-managed or Couchbase Capella, including the free tier)
Cluster credentials — either username/password or an mTLS client certificate and key