Get the names of all the accessible buckets in the cluster.

Get the server status and configuration without establishing connection. This tool can be used to verify if the server is running and check the configuration.

Test the connection to Couchbase cluster and optionally to a bucket. This tool verifies the connection to the Couchbase cluster and bucket by establishing the connection if it is not already established. If bucket name is not provided, it will not try to connect to the bucket specified in the MCP server settings. Returns connection status and basic cluster information.

Get the names of all scopes and collections in the bucket. Returns a dictionary with scope names as keys and lists of collection names as values.

Get the names of all collections in the given scope and bucket.

Get the names of all scopes in the given bucket.

Check whether the cluster is reachable right now, and where it's broken.

This actively pings (see caveat below) the cluster's services and reports, per service:

• Whether it responded and how long it took (latency)

• Which node/endpoint answered, and any error if it didn't

Scope: cluster-level vs bucket-level ping

• If bucket_name is omitted, this pings at the cluster level. This covers more services in one call, but whether the key-value (KV) service is included depends on the Couchbase Server version — it may be silently skipped.

• If bucket_name is provided, this pings from the perspective of that bucket instead. This guarantees the KV service is covered for that bucket, but the result is scoped to that one bucket only — ping again per bucket_name to cover a multi-bucket cluster.

service_types optionally restricts which services get pinged. Valid values: "key_value", "query", "search", "analytics", "view", "management", "eventing". Omit to ping every service. An unrecognized value returns an error response instead of raising.

Caution — this is somewhat invasive: unlike a passive connection-state check, ping performs a live network round-trip to every targeted service. Prefer a narrow service_types filter, and avoid calling this in tight loops or high-frequency polling.

Returns:

• Cluster health status with service-level connection details and latency measurements

Check whether the client's connections were already broken, and for how long.

Unlike get_cluster_health_and_services (which actively pings each service right now), this reports the SDK's own cached connection state without performing any network I/O. It's cheap enough to call frequently, but it's only as fresh as the last time the SDK actually talked to each node — it won't proactively detect a service that just went down if nothing has touched it since. Use get_cluster_health_and_services instead when you need a live, right-now reachability check; there's also no way to filter this report to specific services the way that tool's ping can, since no I/O means nothing to filter.

For each known endpoint, reports which service it belongs to, its remote/local addresses, connection state, and last_activity — how long it's been since that connection last saw traffic. Also reports an overall online/degraded/offline cluster state.

This call makes no request to the server at all, so it needs no specific RBAC role beyond whatever the initial cluster connection already required — unlike an active ping, it isn't gated on KV/Query/Search or Cluster Admin privileges.

Returns:

• Diagnostics report with per-endpoint connection state and overall cluster state

Get a document by its ID from the specified scope and collection. If the document is not found, it will raise an exception.

Look up parts of a document without fetching the whole thing, using Couchbase sub-document operations. Use this instead of get_document_by_id when you only need a few fields, a presence check, or the size of an array/object inside a document — AND you already know the exact field path(s) to look up (e.g. from a prior get_document_by_id call on this same document, from the user explicitly naming the field, or from a known/confirmed schema for this collection).

IMPORTANT: Do NOT guess field paths. If you don't already know the document's exact field names/structure, call get_document_by_id first (or instead) — a guessed path that doesn't exist returns a per-path error here rather than the real data, and reporting "not found" for a wrong guess is worse than just fetching the whole document and reading the right field.

Provide one or more of the following. Each is a list of sub-document paths using Couchbase's dot/bracket path syntax (e.g. "address.city", "tags[0]", "tags[-1]" for the last array element):

• get_paths: fetch the VALUE at each path.

• exists_paths: check whether each path exists, without fetching its value (cheaper than get_paths — no payload transfer — when you only need a yes/no answer).

• count_paths: get the number of elements in the array or object at each path (fails per-path if the path isn't an array/object).

At least one of get_paths, exists_paths, or count_paths must be provided. As a rule of thumb, keep the combined number of paths across all three to 16 or fewer — Couchbase limits subdocument operations per call, though the exact limit is server-side and may change. If the server rejects the call (too many paths, or another constraint like path length or nesting depth), the whole call fails with {"error": "..."}.

A path that doesn't exist (or otherwise fails, e.g. count on a non-array/object) does NOT fail the whole call — it is reported individually as {"error": ...} in the returned dict so the other requested paths can still be resolved.

Returns a dict with a key for each category that was requested (only requested categories are included): { "get": {"": {"value": } | {"error": "..."}}, "exists": {"": {"value": true | false} | {"error": "..."}}, "count": {"": {"value": } | {"error": "..."}}, } On a connection/lookup failure, or an invalid request (no paths / too many paths), returns {"error": ""} instead.

Get the schema for a collection in the specified scope. Returns a dictionary with the collection name and the schema returned by running INFER query on the Couchbase collection.

Run a SQL++ query on a scope and return the results as a list of JSON objects.

The query will be run on the specified scope in the specified bucket. The query should use collection names directly without bucket/scope prefixes, as the scope context is automatically set.

Use named_parameters to bind values to $name placeholders in the query instead of concatenating user input into the statement. This prevents SQL++ injection

Example: query = "SELECT * FROM users WHERE age > 18" # Incorrect: "SELECT * FROM bucket.scope.users WHERE age > 18"

For creating a new index, prefer the create_index tool over a raw CREATE INDEX statement here — it defers the build by default and tells you the recommended next step. Use list_indexes to check whether an index is online before relying on it in a query plan.

Generate and evaluate an EXPLAIN plan for a SQL++ query. It provides information about the execution plan for the query.

The EXPLAIN statement is run in the specified scope in the specified bucket. It returns query metadata along with an extracted plan and plan evaluation.

Get index recommendations from Couchbase Index Advisor for a given SQL++ query.

The Index Advisor analyzes the query and provides recommendations for optimal indexes. This tool works with SELECT, UPDATE, DELETE, or MERGE queries. The queries will be run on the specified scope in the specified bucket.

Returns a dictionary with:

• current_used_indexes: Array of currently used indexes (if any)

• recommended_indexes: Array of recommended secondary indexes (if any)

• recommended_covering_indexes: Array of recommended covering indexes (if any)

Each index object contains:

• index: The CREATE INDEX SQL++ command

• statements: Array of statement objects with the query and run count

List indexes in the cluster with optional filtering by bucket, scope, collection, and index name.

Filters must be provided hierarchically: scope requires bucket, collection requires both, index requires all three. Set return_raw_index_stats=True to get the unprocessed source row for each index.

Each result contains: name, definition (CREATE INDEX statement), status, isPrimary, bucket, scope, collection, lastScanTime. If a required field is missing, the entry contains warning and raw_index_stats instead.

Source depends on cluster version: v8+ queries system:indexes via the query service (RBAC-scoped — the connected user sees only indexes on keyspaces they can access); older clusters fall back to the admin-level Index Service REST API /getIndexStatus.

Get queries that are not very selective from the system:completed_requests catalog.

Prefer this over writing a raw system:completed_requests query via run_sql_plus_plus_query.

Get queries that don't use a covering index from the system:completed_requests catalog.

Prefer this over writing a raw system:completed_requests query via run_sql_plus_plus_query.

Get queries that use a primary index from the system:completed_requests catalog.

Prefer this over writing a raw system:completed_requests query via run_sql_plus_plus_query.

Get queries with the largest result counts from the system:completed_requests catalog.

Prefer this over writing a raw system:completed_requests query via run_sql_plus_plus_query.

Get queries with the largest response sizes from the system:completed_requests catalog.

Prefer this over writing a raw system:completed_requests query via run_sql_plus_plus_query.

Get the N longest running queries from the system:completed_requests catalog.

Prefer this over writing a raw system:completed_requests query via run_sql_plus_plus_query.

Get the N most frequent queries from the system:completed_requests catalog.

Prefer this over writing a raw system:completed_requests query via run_sql_plus_plus_query.