Getting creative with MCP.

Five MCP tool shapes no API wrapper can produce.

Once an MCP server stops mirroring the API, better shapes appear. Five worth stealing. The digest answers "what happened while I was gone". The verdict ships judgment with its evidence. The closed loop lets an assistant act and then see the result. The account's-reality tool returns your setup instead of generic docs. And the two-way door carries structured decisions back in.

The most common question a user brings to Claude or GPT is not about any resource, it is "anything I need to look at?" The digest tool answers it directly. Signal9's version is the Rundown, a verdict headline, what arrived grouped by signal, what automation cleared and whether any of it came back, and the findings a human has not yet dismissed.

The design detail that makes it more than a summary endpoint is that the tool and the page share one read boundary. Calling it with no arguments covers everything since the user's last read on any channel, and counts as reading it. "Caught up" is not a resource, so no wrapper produces it. It is a promise between surfaces, and you have to build it on purpose.

When the user asks "should I worry about this alert?", raw rows are homework. The verdict tool returns the conclusion, clear it, attach it, investigate, act, with the evidence lines carrying the record references they rest on, and every number labeled with the window it was computed over. Two properties matter more than the verdict itself, the evidence is inspectable, and the tool is allowed to honestly answer that there is not enough history to advise. An assistant relaying a labeled verdict is reliable. An assistant inferring one from forty rows is a coin you keep flipping.

Setup is where assistants usually stall, because acting blind is worse than not acting. The fix is a loop, not a tool, create the webhook source, get the setup steps with the real URL, send a test alert, then read back what the pipeline actually made of the payload, what matched, what parsed, what alert resulted. The assistant can check its own work and iterate, which turns setup from a documentation problem into a conversation.

One honesty rule holds the loop together, the test tool says, in its own description, that it fires a real alert through the real pipeline and can trigger real paging. Assistants respect warnings they are given. They cannot respect warnings that live in a support article somewhere.

Generic documentation makes an assistant interpolate, here are the steps in the abstract, now guess where your URL goes. The account's-reality tool removes the guessing. Signal9's setup tool returns the vendor's steps with the tenant's actual ingest URL filled in, plus a sample curl that would work as pasted. Every product has an equivalent, the answer that is only correct for this account is the answer worth a tool.

The last shape carries decisions back in, structurally. When Signal9's Rundown surfaces a finding, the finding arrives with its own verbs, a silent source can be retired or snoozed, other findings accepted or dismissed. The assistant records the user's decision using those verbs, and only on the user's explicit say-so. Compare that to exposing a generic update endpoint and hoping the model mutates the right field. Structured verbs make the safe path the only path, which is what lets you grant the capability at all.

All five shapes are live in Signal9's MCP server today, and they share one design idea, decide what crosses the wire. Judgment, labels, and boundaries travel with every answer, so the assistant does what it is good at, which is the conversation, and the platform does what it is for, which is the analysis.

What are examples of MCP tools that are not API wrappers? Digest tools that answer "what happened since I last looked", verdict tools that return a conclusion with labeled evidence and can honestly abstain, closed loops where the assistant acts and then reads the system's interpretation of its action, setup tools that return the account's real configuration instead of generic docs, and decision tools that carry structured user choices back in.

How should I design MCP tools for my product? Start from the questions users actually ask, not from your endpoint list. Do the analysis product-side and return conclusions with labeled evidence. Let tools abstain rather than guess. Put real-world warnings in the tool description itself, and give write actions structured verbs instead of open-ended mutation.

What can Signal9's MCP server do? Read the documentation, set up webhook sources with the tenant's real ingest URLs, send a test alert through the real pipeline and read what it became, deliver the Rundown, return per-alert verdicts with evidence, record decisions on Rundown findings, and send feedback to the team. Access is scoped per API key, so an assistant only sees the tools its key allows.