OmniDeck MCP Server

claude mcp add omnideck -- npx -y omnideck-mcp

{
  "mcpServers": {
    "omnideck": {
      "command": "npx",
      "args": ["-y", "omnideck-mcp"]
    }
  }
}

How to use the OmniDeck MCP server

1. Install it with one of the commands above — no account, no API key, no configuration file to write by hand.
2. Restart your AI client so it picks up the new server.
3. Ask your assistant to use a tool in plain language — for example, "scrub the secrets out of this log before we look at it."

What is MCP, and why does this server exist?

MCP (Model Context Protocol) is an open standard that lets an AI assistant call external tools instead of guessing at answers on its own. Most MCP servers connect an assistant to a remote service, which means your data travels to somebody else's infrastructure to be processed. This one is deliberately the opposite: every tool here is pure local computation inside your own machine. It exists because a specific group of everyday tasks — decoding a token, hashing a password, scrubbing a log file — are normally solved by pasting the sensitive value into a random website, which is precisely the thing a careful person should not do.

Why a local server is the right shape for these particular tools

There is a category of task where the tool is trivial but the data is sensitive, and that combination is exactly where the usual convenience of a web-based utility turns into a genuine liability. Decoding a JSON Web Token is a few lines of base64 handling, yet a JWT is a live credential that grants whoever holds it real access, so pasting one into an online decoder hands a working key to a server you know nothing about. Hashing a password is a single function call, but the input is the password itself. Because the computation is genuinely simple, there is no technical reason it needs to happen on somebody else's machine — the only reason online versions of these tools exist at all is that a web page was historically the easiest thing to reach for. An MCP server removes that constraint entirely: the assistant you are already talking to can do the work in place, with the data never crossing a network boundary.

Redaction as a step before the request, not after it

The most useful tool in this set is the one that runs before anything else happens. When an agent is about to send a log file, a configuration dump or a pasted email to an external model, that content routinely carries material nobody intended to share — a stray API key left in a code snippet, an address in a forwarded message, a customer's email in a support transcript. Once that content reaches a third-party API it has already been transmitted, and no subsequent care undoes it. Running a pattern-based scrub as a deliberate first step costs a fraction of a second and catches the structurally obvious categories reliably. It is worth being precise about the limits: pattern matching recognizes data with a fixed, predictable shape, and it cannot recognize a sensitive detail that has no format at all, such as a person's name or an unreleased project codename. It is a strong first pass, not a complete privacy guarantee, and reading the result before sending it remains genuinely necessary.

Why cost comparison belongs next to the agent

Choosing a model is usually a guess made once and then never revisited, which is how a batch job quietly costs twenty times what it needed to. The gap between the cheapest and most expensive model in common use is not a few percent — it is close to two orders of magnitude for the same request. Putting an exact token count and a side-by-side price comparison directly in front of the assistant that is about to run the job turns that guess into a decision, made with the actual numbers for the actual prompt rather than a vague sense of which model is expensive. Because list prices change as providers revise their rates, the figures carry the date they were current as of, and anyone making a real billing decision should confirm against the provider's own pricing page rather than trusting a cached table indefinitely.

Checking AI output against its source, honestly

The fidelity checker addresses a narrow and specific failure mode: a summary that reads fluently while containing a figure, a name or a date that appears nowhere in the source material. It works by extracting the salient specifics from the generated text — numbers, percentages, and runs of capitalized words that look like proper nouns — and reporting which of them cannot be found in the original. This is a lexical heuristic and nothing more. It does not evaluate reasoning, it cannot tell whether a correctly-quoted number is being interpreted correctly, and it will flag a legitimately rephrased term as suspicious. What it produces is a short list of things worth verifying by hand, which is considerably more useful than rereading an entire document with no idea where to look.

Limitations, and how to verify these claims yourself

The honest boundaries of this server are worth stating plainly. The redactor catches structured patterns and misses unstructured sensitive information. The cost table reflects public list prices on a stated date and does not account for volume discounts, cached input pricing or negotiated rates. The fidelity checker is a lexical comparison, not a fact-checker. The JWT tool decodes a token but does not verify its signature, because verification requires the signing secret and no secret should be handed to a tool for that purpose. The context splitter uses a four-characters-per-token approximation for chunk sizing, which is close enough for fitting content into a window but is not an exact count. As for the central privacy claim, the correct response to any vendor asserting that their software sends nothing anywhere is to check rather than believe: the entire server is one readable file, MIT licensed, published on npm and GitHub, and reading it end to end takes a few minutes.