Provides tools for querying Couchbase travel-sample data using SQL++, including connection summary, scopes/collections listing, query execution, document retrieval, and sample queries.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@couchbase-mcp-server List the top 5 hotels by highest rating."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A production-shaped demo that connects a natural-language AI agent to Couchbase through the Model Context Protocol (MCP). It uses the OpenAI Agents SDK as the agent runtime, a stdio MCP server as the tool bridge, Couchbase travel-sample as the data source, and a Nebius-hosted OpenAI-compatible model as the LLM backend.
Live project site: https://tirth1263.github.io/couchbase-mcp-server/
LLMs are good at understanding intent, but they need trustworthy tools to answer questions grounded in private or operational data. MCP gives those tools a standard shape. This repository demonstrates that pattern end to end:
A user asks a plain-English travel question.
The OpenAI Agents SDK agent decides whether it needs database context.
The agent calls a Couchbase MCP tool over stdio.
The MCP server executes scoped SQL++ against the travel-sample.inventory data.
The agent turns the database result into a clear recommendation or answer.
Example questions:
"List out the top 5 hotels by the highest aggregate rating."
"Recommend me a flight and hotel from New York to San Francisco."
"Which airports are near San Francisco and what routes connect to them?"
Related MCP server: Couchbase MCP Server for LLMs
flowchart LR
U["User question"] --> N["main.ipynb / CLI demo"]
N --> A["OpenAI Agents SDK agent"]
A --> M["MCPServerStdio client"]
M <--> S["Couchbase MCP server"]
S --> C["Couchbase travel-sample bucket"]
A --> L["Nebius OpenAI-compatible LLM"]
C --> S --> M --> A --> R["Natural-language answer"]src/couchbase_mcp_server/mcp_server.py - the stdio MCP server.
src/couchbase_mcp_server/couchbase_client.py - Couchbase SDK wrapper and JSON serialization.
src/couchbase_mcp_server/demo_agent.py - command-line OpenAI Agents SDK demo.
main.ipynb - Jupyter notebook version of the demo.
.env.example - environment variables for Couchbase and Nebius.
docs/ - static GitHub Pages website.
tests/ - focused safety tests for SQL++ mutation detection.
Tool | Purpose |
| Shows the configured bucket, scope, host, and read/write mode without exposing secrets. |
| Lists scopes and collections in the configured Couchbase bucket. |
| Runs SQL++ in the configured bucket/scope query context. |
| Fetches a document from a named collection in the inventory scope. |
| Returns useful SQL++ examples for the travel-sample inventory data. |
By default, run_sql_plus_plus_query blocks mutations such as INSERT, UPDATE, DELETE, MERGE, CREATE, DROP, and ALTER. Set COUCHBASE_ALLOW_MUTATIONS=true only when you intentionally want write-capable tools.
Python 3.11 or newer. Python 3.12 is recommended.
Jupyter Notebook or JupyterLab for main.ipynb.
A running Couchbase Server or Couchbase Capella instance.
The travel-sample bucket loaded with the inventory scope.
A Nebius API key for an OpenAI-compatible chat model endpoint.
Clone and install:
git clone https://github.com/tirth1263/couchbase-mcp-server.git
cd couchbase-mcp-server
python -m venv .venv
source .venv/bin/activate
pip install -e ".[notebook]"On Windows PowerShell:
git clone https://github.com/tirth1263/couchbase-mcp-server.git
cd couchbase-mcp-server
python -m venv .venv
.\.venv\Scripts\Activate.ps1
pip install -e ".[notebook]"Create your environment file:
cp .env.example .envThen edit .env:
COUCHBASE_HOST=couchbases://your-capella-endpoint
COUCHBASE_BUCKET_NAME=travel-sample
COUCHBASE_SCOPE_NAME=inventory
COUCHBASE_USERNAME=your_couchbase_username
COUCHBASE_PASSWORD=your_couchbase_password
NEBIUS_API_KEY=your_nebius_api_key
NEBIUS_BASE_URL=https://api.studio.nebius.ai/v1/
NEBIUS_MODEL=meta-llama/Meta-Llama-3.1-8B-InstructYou can start the MCP server directly:
python -m couchbase_mcp_server.mcp_server --env-file .envThe server uses stdio, so it is usually launched by an MCP client rather than run interactively. Logs are written to stderr so stdout stays reserved for MCP messages.
Notebook:
jupyter lab main.ipynbCLI:
couchbase-agent-demo "List the top 5 hotels by aggregate rating."Or:
python -m couchbase_mcp_server.demo_agent \
--env-file .env \
"Recommend a flight and hotel from New York to San Francisco."The demo agent is intentionally explicit about Couchbase structure:
A Couchbase cluster contains buckets.
A bucket contains scopes.
A scope contains collections.
Collections contain JSON documents.
The target demo data lives in the inventory scope.
SQL++ queries should run in a scoped query context, so the FROM clause can use collection names like `hotel` rather than fully qualified paths.
All identifiers should be wrapped in backticks.
That last point matters because SQL++ collection and field names can collide with keywords or include characters that need quoting.
The public website is served from docs/ using GitHub Pages:
https://tirth1263.github.io/couchbase-mcp-server/
The site is a static deployment artifact, so it can also be hosted on Netlify, Vercel, Cloudflare Pages, or any static web server without a build step.
Run validation:
python scripts/validate_project.py
python -m compileall src
pytestFormat and lint if you install the dev extras:
pip install -e ".[dev,notebook]"
ruff check .
ruff format .Do not commit .env; it is intentionally ignored.
Keep COUCHBASE_ALLOW_MUTATIONS=false for demos, workshops, and public examples.
Use a least-privilege Couchbase user with access only to the demo bucket/scope.
Prefer read-only database credentials unless you are intentionally demonstrating write tools.
Treat LLM-generated SQL++ as untrusted input and keep server-side guardrails in place.
OpenAI Agents SDK: https://openai.github.io/openai-agents-python/
Agents SDK MCP integration: https://openai.github.io/openai-agents-python/mcp/
Model Context Protocol: https://modelcontextprotocol.io/
Couchbase Python SDK: https://docs.couchbase.com/python-sdk/current/hello-world/start-using-sdk.html
Couchbase travel-sample: https://docs.couchbase.com/server/current/getting-started/do-a-quick-install.html#install-sample-buckets
Return non-secret Couchbase connection settings for this MCP server.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description indicates 'non-secret' settings, implying no sensitive data returned, but does not disclose idempotency, side effects, or authentication requirements. Basic disclosure, no contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence of 9 words, no redundancy. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given zero parameters and existence of output schema, description covers essential purpose. Could mention it returns a single object, but output schema fills that gap. Complete enough for a simple info tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has zero parameters, so schema coverage is 100% trivially. Baseline per rules is 4. Description adds marginal value by specifying 'non-secret' nature.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Return non-secret Couchbase connection settings for this MCP server.' Verb 'Return' and resource 'Couchbase connection settings' are specific, and it distinguishes from siblings like 'get_document_by_id' and 'run_sql_plus_plus_query' which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Description does not specify when or when not to use this tool, nor does it mention alternatives. For a simple info retrieval tool, this omission is acceptable but missing explicit guidance lowers the score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single document by collection and document ID.
| Name | Required | Description | Default |
|---|---|---|---|
| scope_name | No | ||
| document_id | Yes | ||
| collection_name | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the full burden of behavioral disclosure. It only says 'fetch', implying a read operation, but does not specify behavior for missing documents, error responses, or any side effects. No permissions or rate limits are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-formed sentence with no redundant or extraneous information. It is concise and front-loaded with the core action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description is minimal but acceptable for a simple fetch tool, especially since an output schema exists (not shown but indicated). However, it omits details like error handling and the optional 'scope_name' parameter, which limits contextual completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description only references 'collection and document ID' but does not explain the meaning or format of any parameters, including the optional 'scope_name'. The agent gets no semantic help beyond the parameter names.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it fetches a single document using collection and document ID. It is specific about the resource and action. It does not differentiate from siblings, but sibling tools are dissimilar enough that no confusion arises.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. The description does not mention any prerequisites, when-not-to-use, or typical scenarios. This leaves the agent without context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Return SQL++ examples for the travel-sample inventory scope.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It implies a read-only operation (returning examples) but does not mention side effects, authentication needs, or any other traits. Minimal transparency beyond the basic action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the action and resource. No unnecessary words, perfectly front-loaded. Each word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no parameters and an output schema exists (which can describe return values), the description is nearly complete. It could mention that the examples are pre-defined or relate to the travel-sample dataset, but the current text is sufficient for a basic retrieval tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are no parameters in the input schema, and schema description coverage is 100% (since no params exist). The description does not need to add parameter meaning, and the baseline for no-param tools is 4. No issues.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool returns SQL++ examples for a specific scope. 'Return' is a precise verb and 'SQL++ examples for the travel-sample inventory scope' identifies the exact resource. This differentiates it from sibling tools like get_document_by_id or run_sql_plus_plus_query.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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. There is no mention of use cases, prerequisites, or exclusions. The description only states what the tool does without context for decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List scopes and collections in the configured Couchbase bucket.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral aspects. It indicates a read operation but does not explicitly state non-destructive behavior or mention prerequisites like the bucket being configured. Adequate but minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that conveys the entire purpose without any extraneous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, output schema exists), the description is sufficiently complete. It could mention that it lists all scopes and collections, but the output schema likely covers return details.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and schema description coverage is 100% (trivially). The description adds no parameter information, which is acceptable per baseline for zero parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'List' and the specific resource 'scopes and collections in the configured Couchbase bucket'. It is distinct from sibling tools like get_connection_summary or get_document_by_id, which serve different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives is provided. However, the tool is simple with no parameters, so usage is straightforward; implicit usage context suffices.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a SQL++ query in the configured bucket/scope query context.
The server is read-only by default. Set COUCHBASE_ALLOW_MUTATIONS=true to allow
write statements.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| max_rows | No | ||
| parameters | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses that the server is read-only by default and how to allow mutations. However, it does not mention other behavioral aspects like timeouts, error handling, or result format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two sentences. The first sentence front-loads the purpose, and the second adds important context. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has three parameters and an output schema, the description is minimal. It lacks parameter details and does not mention that the tool returns query results. The mutation toggle is useful but insufficient for complete understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%. The description does not explain any of the three parameters (query, max_rows, parameters). It adds no value beyond the schema's structural information.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it runs a SQL++ query in the configured bucket/scope context. It distinguishes itself from sibling tools that retrieve metadata or documents. The verb 'Run' and resource 'SQL++ query' are specific.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context on read-only default and how to enable mutations, which guides usage. It does not explicitly mention when not to use this tool, but the sibling tools are clearly different in purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0get_connection_summaryget_document_by_idget_sample_queriesget_scopes_and_collectionsrun_sql_plus_plus_queryEach tool has a clearly distinct purpose: connection info, document retrieval, sample queries, schema listing, and query execution. No overlap between tools.
All tools follow a consistent 'verb_noun' pattern, using 'get_' for four tools and 'run_' for one, which is appropriate for the action. Naming is uniform and predictable.
With 5 tools, the set is well-scoped for a read-only Couchbase MCP server. Each tool serves a clear role without superfluous additions.
The tool set covers core read operations: schema exploration, document retrieval, and querying. A minor gap is the lack of a direct list-documents tool, but that can be achieved via queries.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
Let AI agents query data and act across all your business apps via MCP.
The BigQuery remote MCP server is a fully managed service that uses the Model Context Protocol to connect AI applications and LLMs to BigQuery data sources. It provides secure, standardized tools for AI agents to list datasets and tables, retrieve schemas, generate and execute SQL queries through natural language, and analyze data—enabling direct access to enterprise analytics data without requiring manual SQL coding.
GibsonAI MCP server: manage your databases with natural language
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/tirth1263/couchbase-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
