anvaiops-mcp
OfficialServer Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ANVAIOPS_URL | No | API base URL (hosted beta or self-hosted) | https://anvaiops.com |
| ANVAIOPS_API_KEY | Yes | Tenant key; sent as X-API-Key | |
| ANVAIOPS_TIMEOUT_MS | No | Per-request timeout | 15000 |
| ANVAIOPS_DEFAULT_DAYS | No | memory_search lookback window | 365 |
| ANVAIOPS_DEFAULT_LIMIT | No | memory_search page size (max 50) | 10 |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| memory_searchA | 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. |
| memory_writeA | 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. |
| memory_statusA | Check the AnvaiOps deployment this server is wired to: reachability and version. Use to diagnose connectivity before blaming the tools. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored 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.