MCP as a REST wrapper: the floor, not the finish line.

Ship the wrapper, then build tools that answer questions.

Wrapping your REST API in MCP is the right first move. It gives an assistant hands, it ships in a weekend, and shipping beats theorizing. The mistake is calling it done. A wrapped API hands the model raw rows and asks it to do the analysis at the most expensive possible moment. The wrapper is your API in a new protocol. The finish line is tools that answer questions.

You have an API. MCP looks like an API. Translating one into the other is the obvious first move, and it is genuinely worth doing, a Claude that can list your records, read your docs, and create a resource beats a Claude that can only talk about your product from its training data. There is no shame in the floor. Signal9's own first MCP tools were exactly this, list the documentation, list the webhook sources, read a topic.

The problem is what a REST endpoint was designed for. A list endpoint returns what a UI needs, rows, ids, pagination, raw fields. The intended consumer was your own frontend code, with a human looking at the rendered result. Point that same endpoint at a language model and you have handed the most expensive parser you will ever run a pile of unlabeled material, to be analyzed at query time, inside a context window, over paginated JSON.

That is why wrapped-API assistants feel soft. Ask one whether production is okay and you get a book report, here are some rows, here are some things that look similar, here are forty log lines. The model is not failing. It is doing analysis that the product should have done before the answer crossed the wire.

The upgrade path is one question per endpoint, what does the user actually ask that this endpoint exists to serve? Then build the tool that answers that, instead of the tool that returns the ingredients.

"Anything I need to look at?" is not answered by a list of alerts. It is answered by a digest that already knows what arrived, what cleared itself, and what came back after clearing. Signal9's MCP server deliberately has no alert-listing tool at all, it has a Rundown, and the difference is the whole argument. When a tool answers the question, the model relays. Relaying is what models are reliable at.

A related smell, tool count. Generating a tool per endpoint produces surfaces so wide the model spends its context reading your catalog before it reads the user's question. Question-shaped tools collapse that naturally, because users ask fewer questions than your API has resources. And the description becomes the product, a tool that says what it returns, what its numbers mean, and when it will decline to answer is a tool the model uses correctly on the first try.

Signal9 ships an MCP server built on the question test, a Rundown instead of an alert list, verdicts that carry their evidence and their windows, setup tools that return your account's real URLs, and a test loop the assistant can check its own work against. The floor was worth shipping. It was also just the floor.

Is wrapping a REST API in MCP good enough? It is the right start and the wrong finish. A wrapper gives an assistant access, which has real value, but it hands the model raw rows and makes it do the analysis at query time. The tools that feel magical answer the user's actual question, with the summarizing and labeling done product-side before the response crosses the wire.

What makes a good MCP tool? It answers a question a user actually asks, rather than mirroring a resource. It returns conclusions with labeled evidence instead of raw rows, states what its numbers cover, is allowed to honestly abstain when it does not know, and carries a description precise enough that the model uses it correctly without trial and error.

Does Signal9 have an MCP server? Yes. It covers reading the docs, setting up webhook sources with the tenant's real ingest URLs, sending a test alert through the real pipeline and reading what the pipeline made of it, the Rundown, per-alert verdicts with evidence, and sending feedback. There is deliberately no alert-listing tool, the Rundown answers that question instead.