agent-ops-mcp
# agent-ops-mcp
A demo [MCP](https://modelcontextprotocol.io) server showing the shape of a
setup I built for my team: an agent that reads and writes to our internal
systems directly, instead of someone pasting context into a chat by hand,
plus a lightweight quality gate that checks what the agent produced before
it reaches a human reviewer.
The real version talks to our actual task tracker, internal docs, and CI —
that code isn't public. This repo is a self-contained rebuild of the same
idea against mock data, so it runs standalone with no credentials or access
to anything internal.
## What it exposes
| Tool | Does |
|---|---|
| `list_tasks` | List tasks from a mock tracker, filterable by status/assignee |
| `get_task` | Fetch a single task by id |
| `create_task` | Create a task |
| `search_docs` | Full-text search over a small mock internal wiki |
| `get_doc` | Fetch a doc's full content by id |
| `review_check` | Heuristic pre-review gate — flags hardcoded secrets, leftover `TODO`/`FIXME`, placeholder text, oversized diffs |
`review_check` is the interesting one: instead of a human catching a stray
`TODO` or a hardcoded password during review, the agent runs this on its own
output first. It mirrors the `review-checklist` doc bundled in this repo.
## Run it
```bash
npm install
npm run build
npm start
```
This starts an MCP server over stdio. To try it from Claude Desktop or
Claude Code, add it to your MCP config:
```json
{
"mcpServers": {
"agent-ops-mcp": {
"command": "node",
"args": ["/absolute/path/to/agent-ops-mcp/dist/index.js"]
}
}
}
```
For local development without a build step:
```bash
npm run dev
```
## Data
Everything lives in memory, seeded from `src/data/tasks.ts` and
`src/data/docs.ts` on startup. `create_task` mutates the in-memory list —
nothing is written to disk, so state resets every run.
## Stack
TypeScript, Node.js, [`@modelcontextprotocol/sdk`](https://github.com/modelcontextprotocol/typescript-sdk), [Zod](https://zod.dev) for input validation.
## License
MIT
TDQS
Scored across 6 tools
Each tool targets a distinct resource and action: tasks (list/get/create), docs (search/get), and a review check. There is no overlap or ambiguity between them. An agent can easily select the right tool for each intent.
All tool names follow a consistent snake_case verb_noun pattern (list_tasks, get_doc, review_check). The verbs are clear and the style is uniform throughout. This makes the API predictable and easy to extend.
With only 6 tools, the surface is well-scoped and focused. Each tool earns its place by covering a necessary operation without bloat. This is an ideal size for an agent helper that combines tasks, docs, and quality checks.
Task management is incomplete: you can create and list tasks but cannot update, delete, or change status, which are common operations. Docs are read-only (search/get), which is acceptable for a reference. Adding update/delete for tasks would round out the lifecycle.