# Cb Analytics Admin

> |

- **Type:** Skill
- **Install:** `agentstack add skill-celticht32-couchbase-skills-for-claude-ai-cb-analytics-admin`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [celticht32](https://agentstack.voostack.com/s/celticht32)
- **Installs:** 0
- **Category:** [Databases](https://agentstack.voostack.com/c/databases)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [celticht32](https://github.com/celticht32)
- **Source:** https://github.com/celticht32/Couchbase-Skills-for-Claude.ai/tree/main/skills/couchbase-analytics/cb-analytics-admin

## Install

```sh
agentstack add skill-celticht32-couchbase-skills-for-claude-ai-cb-analytics-admin
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# Analytics service admin

You have 7 tools for runtime management.

## Status snapshot (read-only, safe)

- `get_service_status(cluster)` — overall service state, replica lag,
  authorised node list
- `get_ingestion_status(cluster)` — per-link ingestion state, pending ops
- `get_active_requests(cluster)` — what's running right now
- `get_completed_requests(client_context_id=None, cluster)` — recent
  history; pass `client_context_id` to filter to one request

## Diagnostic workflow

When a user says "queries are slow" or "ingestion looks stuck":

1. `get_service_status` — is the service even healthy? Watch `ccRevLag`
   (replication lag).
2. `get_ingestion_status` — for each link, look at `pendingOperations`. A
   non-zero pending count after a quiet period usually means a stuck link.
3. `get_active_requests` — long-running queries appear here with
   `elapsedTime`. Anything over a few seconds is suspect.
4. `get_completed_requests` — look for a pattern of errors or unusually
   long durations.

## Destructive operations (use with care)

- `cancel_request(client_context_id, cluster)` — abort one in-flight query.
  Get the id from `get_active_requests`.
- `restart_node(cluster)` — restart only the Analytics process on the
  local node. May briefly disrupt queries routed to that node.
- `restart_service(cluster)` — **cluster-wide** Analytics restart. All
  active queries fail. Don't suggest this lightly; warn the user.

## Confirmation patterns

When the user asks to cancel or restart anything, **always confirm** by
naming what you're about to do, with the specific request id or cluster
name. Example:

> Cancel request `cb-12345` on cluster `prod`? This will return an error
> to whichever client issued it.

After they confirm, run the tool and report success or failure based on
the returned `ok` field.

## What to avoid

- Don't restart the service to "fix" a slow query — try cancelling it first.
- Don't call `cancel_request` on a `client_context_id` that's already
  completed; it's a no-op but generates a confusing error.
- Don't poll `get_active_requests` aggressively (e.g. every second). Once
  per few seconds is fine.

## Rate limits & safety

Admin tools split across two rate-limit categories:

- **`read`** (60/sec): `get_service_status`, `get_ingestion_status`,
  `get_active_requests`, `get_completed_requests`.
- **`write`** (1/sec, intentionally conservative): `cancel_request`,
  `restart_service`, `restart_node`.

The write bucket is small on purpose. Cancelling one runaway query per
second is plenty; restarting a service every second would be madness.
If a `RateLimitExceeded` response comes back, the response includes
`retry_after_sec` — honour it. Don't retry-storm; that just keeps the
bucket empty.

Status calls share the read bucket with every other read-only tool across
the server (list_users, list_clusters, ping_cluster, etc.). If you're
polling status in a loop, keep the interval ≥ 2 seconds so the bucket
stays healthy for other concurrent work.

## Related skills

- `cb-analytics-query` — the query tools that generate the requests you'll be monitoring and cancelling
- `cb-analytics-cluster` — cluster-level health (nodes, rebalance, auto-failover) that underpins Analytics service health

## Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [celticht32](https://github.com/celticht32)
- **Source:** [celticht32/Couchbase-Skills-for-Claude.ai](https://github.com/celticht32/Couchbase-Skills-for-Claude.ai)
- **License:** MIT

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/skill-celticht32-couchbase-skills-for-claude-ai-cb-analytics-admin
- Seller: https://agentstack.voostack.com/s/celticht32
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.