Tines ships an MCP server at https://<tenant>.tines.com/mcp, and it’s good at what it’s built for: authoring stories. That’s where the product’s center of gravity is.
The part I spend my day in is the case queue. Cases have a full v2 API behind them, but no MCP tools sat in front of it, so the queue was the one part of Tines I couldn’t reach from an MCP client. I built a small server to close that gap.
What makes it useful is what sits next to it
I run MCP servers for other tools in my stack alongside this one. That means a case can be worked without leaving the session: pull the case, check the endpoint’s detection history, check the data-loss side, decide, write the outcome back to the case. No tab-switching, no copying case IDs between consoles. The cross-referencing is the whole point, and the Tines half was the missing piece.
The first week
I had a backlog of over 100 open cases. I cleared all of them in a few hours.
Most were false positives, which I expected. Some needed enrichment, some needed real work. What I didn’t expect were the two things the backlog had been hiding:
- A SIEM parser that needed modifying. I’d have found that eventually, one confusing case at a time.
- A missed attack on an endpoint belonging to a SaaS tool that had been locking accounts out at random. It had been going on long enough that people had stopped asking why.
Neither of those is visible when you work a queue one case at a time over weeks. They show up when you go through a hundred in one sitting with every tool in reach. The time saved was the reason I built it. The better understanding of my own alerting was the part I didn’t see coming.
What it does
Read and write tools over Cases v2: get, list and search, comments, assignees, metadata, and linked cases on the read side; create, update, close, append to description, comment, link/unlink, and delete on the write side.
It runs in a container, and it’s read-only until you explicitly turn writes on. That default is deliberate: the server hands case content that often originated from an external alert to a model, and a fresh install shouldn’t also be able to modify production cases.
Repo, MIT licensed: GitHub - nwhistler/tines-cases-mcp: Custom MCP For Tines Cases · GitHub The README covers setup, configuration, and the safety model.
Three things about the Cases API that cost me time
These are in the README, but they’re worth surfacing here for anyone else building against v2:
filtersonlist_casesgoes in the body of the GET. Passed as a query param it gets silently ignored, so every “filtered” query quietly returns unfiltered results. Easy to ship, hard to notice.- Case links are bidirectional. There’s no parent/child direction in the data, so a “master ticket” is a convention about which case you triage.
- A list response embeds each case’s entire activity log. At
per_page=25that measured roughly 84k tokens on my tenant, which will swamp a model’s context in a single call. My server projects list rows down to the fields you need to triage, which measured about an 11x reduction.
Happy to answer questions. I’m also curious whether others here are wiring Tines cases into MCP clients, or solving this a different way.
