Click on "Deploy 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., "@anvaiops-mcp search past incidents for the Redis timeout fix and RCA"
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.
Give any AI agent operational memory. An MCP server that connects Claude (Desktop, Code), and any other MCP client, to AnvaiOps — the memory layer for AI agents and the teams they work with.
Agents search past incidents, fixes, and decisions with provenance (source, team, resolution time, RCA), and persist what they learn back into shared memory.
"Your next answer may already exist."
Every claim on this page is backed by a reproducible session: demo/transcript.md
shows a real agent search (31 ms, provenance included), a memory write, and a later session
finding that agent-written memory ranked #1. demo/e2e.js re-runs the whole chain with
PASS/FAIL assertions — npm run demo:e2e against any deployment.
Related MCP server: @cogniahq/mcp
Tool | Status | What it does |
| stable | Hybrid semantic search over incidents/runbooks/decisions. Results carry RCA, fix, team, resolution time, source URL, and score. |
| experimental | Persist a memory (async ingest): what happened, how it was fixed, decision + rationale. Attributed |
| stable | Deployment reachability/version probe. |
Status labels follow the AnvaiOps ADR-0014 discipline — no tool claims more than it delivers.
Works today straight from GitHub (the prepare script builds on first use; npm package pending):
"command": "npx", "args": ["-y", "github:anvai-labs/anvaiops-mcp"]Add to claude_desktop_config.json (macOS:
~/Library/Application Support/Claude/claude_desktop_config.json):
{
"mcpServers": {
"anvaiops": {
"command": "npx",
"args": ["-y", "anvaiops-mcp"],
"env": {
"ANVAIOPS_API_KEY": "your-key",
"ANVAIOPS_URL": "https://anvaiops.com"
}
}
}
}claude mcp add anvaiops -- npx -y anvaiops-mcp
export ANVAIOPS_API_KEY=your-key # or put it in the server envPoint at your own deployment (the same server works against any AnvaiOps install):
{ "ANVAIOPS_URL": "http://localhost:8000", "ANVAIOPS_API_KEY": "local-key" }Env var | Default | Meaning |
| — (required) | Tenant key; sent as |
|
| API base URL (hosted beta or self-hosted) |
|
| Per-request timeout |
|
| memory_search lookback window |
|
| memory_search page size (max 50) |
Get a hosted key from the AnvaiOps console — or run your own; the memory core is open source on ProximaDB.
Every team deploying agents rediscovers the same wall: retrieval is getting cheap, but re-deriving what the organization already knew never gets cheap. The same incident gets debugged three times because the answer lives in a Slack thread from March.
AnvaiOps indexes tickets, Slack threads, runbooks, post-mortems, and release notes — then surfaces the historical fix, with provenance, the moment it's relevant. This server makes that memory available to any agent, in the tool layer, where agents already work.
Design notes:
Provenance is not optional. Every search result carries its source, team, and timestamps — a memory without provenance is a liability.
Writes are attributed and bounded. 1–25 records per call, async ingest, tagged
recorded_by — so agent-written memory stays auditable.
Zero runtime dependencies. Hand-rolled MCP stdio (JSON-RPC 2.0, protocol 2024-11-05 →
2025-06-18), global fetch. Small supply-chain surface, Node ≥ 18.
npm install # dev-only deps (typescript, @types/node)
npm run build
npm test # node:test unit suite (no network)
npm run smoke # stdio handshake + tools/list against the built binaryApache-2.0 — © AnvaiOps. An Anvai Labs project.
Search operational memory: past incidents, fixes, runbooks, and decisions with provenance (source, team, resolution time, RCA and fix summaries). Use before investigating any production issue or repeating work — the answer may already exist.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Lookback window in days (default 365) | |
| team | No | Owning team, e.g. Platform Engineering | |
| limit | No | Max results, 1-50 (default 10) | |
| query | Yes | Natural-language search query. | |
| status | No | open | resolved | closed | |
| sources | No | Comma-separated source filter: jira,slack,zendesk,confluence,pagerduty,github | |
| severity | No | critical | high | medium | low | |
| component | No | Affected component substring |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden, and it usefully discloses the shape of what comes back — source, team, resolution time, RCA and fix summaries. It does not state read-only/non-destructive safety, rate limits, or pagination behavior, which is the remaining gap for an unannotated tool.
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?
Two sentences, no padding: purpose with scope first, then the usage imperative. Every clause earns its place and nothing is buried.
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?
For an eight-parameter tool with full schema coverage and no output schema, the description compensates well by describing the provenance fields returned. Only the absence of safety/pagination context keeps it from being fully complete.
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 100%, so all eight filters (days, team, limit, status, sources, severity, component) are already documented in the schema. The description adds no syntax, format, or interaction detail beyond that, so the baseline 3 applies.
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?
States a specific verb+resource ("Search operational memory") and enumerates the resource contents (incidents, fixes, runbooks, decisions with provenance). This is clearly a read/search tool that an agent can distinguish from the memory_write and memory_status siblings without inspecting either schema.
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?
"Use before investigating any production issue or repeating work — the answer may already exist" gives a clear triggering condition and the rationale behind it. It lacks explicit exclusions or a named alternative tool to use when the answer is not found, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the AnvaiOps deployment this server is wired to: reachability and version. Use to diagnose connectivity before blaming the tools.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden, and it does disclose the two observable outputs (reachability, version), which is meaningful given there is no output schema. It does not state that this performs a network/probe call that may hang or time out, nor explicitly confirm it is side-effect-free, so a small gap remains.
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?
Two short sentences, zero filler, with the purpose front-loaded and the usage guidance appended. Every clause earns its place.
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?
For a zero-param diagnostic with no output schema and no annotations, the description supplies the essential missing pieces: what is checked and what is reported. It could be more complete by describing failure/timeout behavior, but nothing critical for correct invocation is absent.
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 takes zero parameters, so there is nothing to document beyond the schema's empty object and the baseline of 4 applies. The description correctly implies a no-argument invocation and adds no contradictory parameter guidance.
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?
Specific verb ("Check") plus a concrete resource (the AnvaiOps deployment this server is wired to) and the exact facts returned (reachability and version). It is clearly distinguishable from the sibling memory_search/memory_write tools, which read or mutate memory rather than probe the backing deployment.
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 second sentence gives explicit usage context: diagnose connectivity before blaming the tools. That is a real when-to-use directive. It stops short of naming an alternative tool or a when-not-to-use condition, so it falls just below the top band.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Persist a memory so future agents and engineers find it: incident resolution, fix applied, decision + rationale, runbook step. Writes are attributed (recorded_by=anvaiops-mcp) and searchable immediately after commit. Experimental — async ingest.
| Name | Required | Description | Default |
|---|---|---|---|
| records | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations at all, the description carries the full burden and does well: it discloses write attribution (recorded_by=anvaiops-mcp), immediate searchability after commit, and an experimental async-ingest caveat that meaningfully changes how an agent should reason about read-after-write. It does not cover permissions/auth requirements, partial-failure behavior for the batch, or the 25-record cap, which keeps it below a 5.
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?
Two dense sentences with the purpose front-loaded, then attribution/timeliness, then the experimental caveat. Every clause adds information and none is padding.
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?
For a write tool with no annotations and no output schema, the description covers identity of the write, visibility semantics, and a maturity caveat, which is most of what an agent needs to invoke it safely. It is thin on batch limits and failure/retry behavior, leaving a small but real gap.
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?
Only one top-level parameter ('records') exists and it is undocumented at that level; the description never says writes are batched, that the array accepts 1–25 items, or how the listed content types map onto fields like text/source/status. The nested item fields do carry their own schema descriptions, which partially compensates, but the batch semantics are left to the schema alone.
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?
States a specific verb and resource ('Persist a memory') plus the intent ('so future agents and engineers find it'), and enumerates the kinds of content it accepts (incident resolution, fix applied, decision + rationale, runbook step). This makes it unmistakably the write counterpart to memory_search/memory_status without needing to name them.
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 content-type list ('incident resolution, fix applied, decision + rationale, runbook step') gives a clear positive trigger for when to call it. It stops short of explicit exclusions or naming the sibling read tool as the alternative path, so routing is implied rather than spelled out.
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.
v0.1.0memory_searchmemory_statusmemory_writeScored across 3 tools
Each tool targets a clearly distinct operation on the memory resource: search (read), write (create), and status (health check). There is no overlap in purpose and an agent can unambiguously select the right one.
All three tools follow the identical memory_<verb> pattern (memory_search, memory_write, memory_status), a fully predictable and consistent convention across the set.
Three tools is on the thin side for an operational-memory system; the narrow scope keeps it coherent, but the surface feels minimal given the domain implies richer lifecycle management.
Read (search) and create (write) are covered plus a health check, but there is no update, delete, or get-by-id operation, leaving notable gaps in the memory lifecycle as the description itself hints at an experimental/async model.
Persistent memory for AI agents across Claude, ChatGPT and any MCP client.
Persistent memory for AI assistants. Save once; recall from Claude, ChatGPT, or any MCP client.
Private persistent memory for Claude, ChatGPT & Gemini via MCP - semantic search, zero-code setup.
Persistent AI memory shared across Claude, ChatGPT, coding agents, and compatible MCP clients.
