Couchbase MCP Server

Overview Schema Source Related Servers Discussions Admin

get_cluster_system_events

Read-only

Retrieve the cluster system event log for root cause analysis: find config changes, failovers, rebalances, or service restarts before a symptom; use since_time to window events.

Instructions

Get the cluster's system event log — what changed on the cluster, and when.

This is the RCA timeline: once a symptom is confirmed, it finds the config change, failover, rebalance or service restart that preceded it. Window it to the symptom's onset with since_time, then cross-check that timestamp against get_cluster_metrics.

Self-managed Couchbase Server 7.6+ only (Capella is rejected without a REST call); needs the Full Admin or Cluster Admin role. Calls GET /events.

Ordering — easy to misread:

Events are ALWAYS oldest-first, but which ones the server picks depends on since_time. Without it, the server takes the limit MOST RECENT events, so the last element is the newest thing on the cluster. With it, it takes the limit EARLIEST events at or after that time, so the last element is NOT the newest — more may follow it.
Do not re-sort or re-slice to get "the latest N": slicing keeps the oldest. Lower limit and let the server choose.
To page forward, pass summary.next_since_time as the next since_time. It is inclusive, so the boundary event repeats — dedupe on uuid. When it is null on a truncated result, check summary.paging_blocked: every event in the batch shares one timestamp, so sinceTime cannot move past them and a higher limit is the only way to see the rest.

A cluster's log is overwhelmingly "info", so expect routine entries in the window; move the window rather than raising limit.

Reading the result:

summary.by_severity / by_component say what the window holds at a glance, so a lone "error" among routine entries is visible without reading every event.
summary.possibly_truncated means the server filled the limit, so more events probably exist outside the window. Absence of a later event is not evidence.
The log is a ring buffer (10,000 entries by default), so an empty result for an old since_time can mean the events aged out, not that nothing happened.

Returns {"summary": {...}, "events": [...]}; raises on failure.

Input Schema

Name	Required	Description	Default
`limit`	No
`timeout`	No
`since_time`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv1.1.0Nov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only supply readOnlyHint, but the description adds substantial behavior: version/platform gating (7.6+ self-managed, Capella rejected without a REST call), required roles (Full Admin or Cluster Admin), the underlying GET /events call, ring-buffer size (10,000 default) and the consequence that empty results may mean aged-out events, and that failures raise. This is far beyond what the annotation conveys.

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

Conciseness4/5

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

Front-loaded with purpose, then platform/auth gate, then a clearly labeled ordering block and a labeled result-reading block. Each bullet carries a distinct operational fact, though the length is near the upper bound and a few clauses (e.g. naming summary.by_severity and by_component) restate fields the output schema already declares.

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

Completeness5/5

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

The tool is genuinely tricky (non-obvious ordering inverted by since_time, truncation subtleties, ring-buffer aging), and the description covers every trap an agent would fall into. An output schema exists, yet the description still explains the paging-relevant summary fields that the schema alone would not make actionable.

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?

Schema coverage is 0%, so the description must carry the load, and it does for two of three parameters: since_time is explained in depth (inclusive boundary, dedupe on uuid, next_since_time paging, paging_blocked escape hatch) and limit is explained precisely (server picks most-recent vs earliest, raising it is the only recourse on a single-timestamp batch). timeout receives no mention at all, which is the only gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ("Get the cluster's system event log — what changed on the cluster, and when") and immediately frames the role it plays: the RCA timeline. It is clearly differentiated from get_cluster_metrics (cross-check target) and from config-listing siblings like get_bucket_config.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says when to use it ("once a symptom is confirmed"), how to window it ("Window it to the symptom's onset with since_time"), what to do next ("cross-check that timestamp against get_cluster_metrics"), and what not to do ("move the window rather than raising limit", "Do not re-sort or re-slice"). Alternatives are named rather than implied.

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

Deploy Server