The MCP Server

The Model Context Protocol (MCP) is the open standard AI harnesses use to discover and call tools served by other systems. This server serves such an endpoint: connect Claude Desktop, Claude Code, an IDE agent, or any MCP-capable client to it, and that client's model gains what it cannot do itself: reading scanned pages, permanently redacting PDFs, filling forms, transcribing recordings, and searching your indexed corpus. Every operation executes here, on your hardware, on documents that never leave it.

1Be the model, or be the tools#

This server plugs into an assistant in two complementary ways, and the difference decides which guide you need:

• Be the model. The assistant's base URL points here, and its conversations run on models this server hosts. That is API Compatibility, and for the Claude Desktop app specifically, Claude Desktop.
• Be the tools. The assistant keeps whatever model it already uses and borrows this server's document machinery over MCP. That is this guide.

The two compose: Claude Code, for example, can run on a model served here and hold this server's tools at the same time. The MCP catalog is deliberately built for the second role: it carries no chat, summarization, or translation tools, because the caller is itself a model and a generation-shaped tool would only be a downgrade path. What it carries is the machinery a model does not have: a PDF engine, OCR, media transcription, and a durable, searchable corpus.

2Switching it on#

The endpoint is off by default: exposing tools is an explicit decision, not something a server starts doing on upgrade. In the MCP section of the admin console:

1. Enable the endpoint. Whether it is served at all is decided at startup, so this one switch asks for a restart. Everything below it applies live.
2. Keep or adjust the exposed set. By default the endpoint offers the recommended set, not the whole catalog (section 7). Connected clients are notified when the selection changes and re-list, rather than calling a tool that is gone.
3. Open ingestion roots if callers will pass file paths. With none configured, file_ingest refuses every path, because a server that reads any requested path and returns the bytes is a file-disclosure surface. Open exactly the folders you work from.

Then open the endpoint's own address in a browser. The same URL that serves the protocol renders a connection page for humans: paste-ready configuration for each client, the live tool catalog exactly as the endpoint currently serves it (page and wire are computed by the same policy code, so they cannot disagree), the last completed client handshake so you can see that your client actually arrived, and, for a signed-in operator, a per-tool tester, so a tool can be exercised before any client is configured.

3On your own machine#

The shortest path: the server runs on your workstation (desktop mode or a terminal), and the assistant runs beside it. On a loopback-only installation with anonymous access, no key is needed, so connecting Claude Code is one command:

claude mcp add --transport http lmkit http://localhost:5189/mcp

(5189 is the default HTTP port; the connection page prints your server's actual address.) Claude Desktop, VS Code, and Cursor take a JSON block instead; the connection page holds each client's exact shape, and section 4 walks every client step by step, including what each plan allows.

Open a folder for ingestion (say, the directory your scans land in), and the loop closes: ask the assistant to work on a file by its path, and it registers the document with file_ingest, gets back a file_id, and chains every further tool on that id. A good first task is a scanned PDF, because it exercises exactly what the assistant could not do alone: "Read C:\Scans\contract.pdf and tell me what it says" runs OCR here and hands the model the transcription.

4Each client, step by step#

The blocks on the connection page are correct for every client below; what differs is where each block goes, and what the client's own plan or organization policy allows. This section walks each one. One rule explains most surprises: the URL must be reachable from wherever the client actually connects. Apps on your machine (Claude Desktop's config file, Claude Code, the IDEs) reach localhost; account-level connectors on claude.ai or ChatGPT connect from the provider's side, so they need a public HTTPS address and can never reach a loopback URL.

Claude Desktop and claude.ai

Claude Desktop has two doors, and picking the right one is the whole setup:

The config file (any plan, local servers welcome). In Claude Desktop, open Settings, choose Developer, then Edit Config; the app opens claude_desktop_config.json (%APPDATA%\Claude\ on Windows, ~/Library/Application Support/Claude/ on macOS). Paste the connection page's Claude Desktop block, save, and quit the app completely before reopening it: a window close leaves it in the tray with the old configuration. The app connects from your machine, so a localhost address works, and a keyed server works too (the block carries the Authorization header). If your build predates HTTP servers in this file, use the stdio bridge from section 5 as the command instead.

Connectors (paid plans, claude.ai included). Settings, then Connectors, then Add custom connector, and paste the server address. This is the account-level route: it follows you to claude.ai in the browser and to mobile. Three gates to know about:

1. It needs a paid plan (Pro, Max, Team, or Enterprise).
2. On Team and Enterprise plans the button may be missing entirely until an organization admin allows custom connectors in the organization's Claude settings; ask them first if you do not see it.
3. The address must be publicly reachable over HTTPS with a certificate the world trusts; claude.ai connects from Anthropic's side, so localhost and intranet names cannot work. Custom connectors also expect a server that is open or speaks OAuth; this server authenticates with bearer keys, so when a key is required, prefer the config-file route here and the header-carrying routes below.

For a server on your own machine, the config file is the right door; the Connectors route earns its keep when the server is hosted for a team (Going Live).

Claude Code

One command, from any terminal, on any plan:

claude mcp add --transport http lmkit http://localhost:5189/mcp

The connection page prints yours with the real address and, when the server requires a key, the --header "Authorization: Bearer ..." flag. Alternatively, paste that same command into a Claude Code conversation and ask it to add the server itself; it knows its own configuration. Worth knowing:

• Scopes. By default the server is added for you in the current project. Add --scope user to have it everywhere, or --scope project to write a .mcp.json your whole team picks up from version control.
• Verify with /mcp. It lists every configured server and its live connection state; a first tool call is the real proof.
• Managed installations. Enterprise-managed Claude Code can restrict which MCP servers may be added through its managed settings; if the add is refused by policy, that is an administrator conversation, not a configuration error.

VS Code

The connection page's VS Code block is a .vscode/mcp.json for the workspace (note the servers key; it differs from every other client). Create the file, paste, and open chat in agent mode: the tools appear under the tools icon. For all projects at once, run MCP: Add Server from the command palette and choose the user scope instead. MCP support needs a current VS Code with GitHub Copilot, and organizations can switch MCP off through the Copilot policy, so a missing tools icon on a work machine is usually policy, not configuration.

Cursor

Paste the Cursor block into .cursor/mcp.json in the project (or ~/.cursor/mcp.json for every project), then check Settings, MCP: the server appears with a live status and its tool count. Cursor asks before the first tool call unless you allowlist the server.

Other MCP clients

Anything that speaks streamable HTTP takes the generic block (endpoint plus, on a keyed server, the Authorization header). The usual suspects, and where their configuration lives:

A client this table does not name still connects: streamable HTTP with a bearer header is the whole contract, and section 5 covers clients that can only launch child processes.

5Clients that launch child processes#

Some clients do not open HTTP connections to their tool servers; they launch a command and speak newline-delimited JSON over its standard input and output. For those, the CLI ships a bridge, and the client's configuration names it as the command:

{
  "mcpServers": {
    "lmkit": {
      "command": "lmkit",
      "args": ["mcp", "--url", "http://localhost:5189"]
    }
  }
}

lmkit mcp forwards each message to the running server, carries the session across, and relays the server's event stream back, so progress on a long conversion reaches the client instead of being lost. Diagnostics go to standard error, never standard output, so the protocol stream cannot corrupt. --api-key adds the bearer token a protected server requires, and --path follows a relocated endpoint, so the same bridge reaches a hosted server as easily as a local one. Details in The Command Line.

6A shared or hosted server#

Everything above scales from a workstation to a team server or a hosted deployment; what changes is posture, not protocol. Going Live covers exposure and TLS; what matters specifically for MCP:

• Keys become mandatory. Anonymous access is automatically withdrawn beyond loopback. Clients authenticate with the standard Bearer header (Keys and Authentication), and every snippet on the connection page switches to its keyed form when the server requires one:

claude mcp add --transport http lmkit https://kb.example.com/mcp \
  --header "Authorization: Bearer YOUR_API_KEY"

• The key must be full-scope. Every MCP message travels as a POST, so a read-only key (safe HTTP methods only) cannot even complete the handshake.
• A session sees one owner. The session is bound to its key's owner exactly as a REST call is: the files it registers, the artifacts tools produce for it, and the resources it may read all belong to that owner and nobody else. Two teams with two keys share the endpoint without sharing a byte.
• The knowledge tools follow the key's grants. kb_list_collections and kb_search see exactly the clusters and tenants the key was granted, per the search access model.

Paths stop being the natural door once the server is remote, because the caller's filesystem is not the server's. A document reaches a remote server three ways:

7What is exposed, and who decides#

The catalog is curated, not generated from the REST surface: a capability earns a tool only when the calling model cannot do the work itself. It currently spans:

Exposure is layered, all of it in the MCP section:

• The default is the recommended set, not everything. The catalog grows continuously, and every additional tool costs the client accuracy in choosing between tools, across all of its connected servers. The recommended core covers registering, inspecting, reading, searching, rendering, unlocking, forms, redaction, and the archival pair (conversion to PDF/A and its independent validation) end to end; the rest (page-level OCR, assembly, media, field extraction, and the knowledge tools) is switched on deliberately rather than arriving with an upgrade.
• A risk ceiling excludes a whole class of tool without naming tools: set the highest risk level the endpoint may serve, and everything above it disappears, including tools added later.
• Approval hints mark tools a client should confirm with its user before running. They are advisory by protocol design: a server can ask, only the client can prompt.
• Per-call ceilings bound what one call can cost and return: how many pages one render or OCR call covers, resolution bounds, match counts, and the point at which a long text result becomes a stored artifact instead of inline content. A tool that hits a ceiling says so and names the remedy, so raising the ceiling is never the only way forward.

Session capacity is bounded too: concurrent sessions are capped, and an idle session expires after a configurable timeout. The connection page shows the resulting catalog exactly as clients receive it.

8Workflows, results, and resources#

Beyond tools, the endpoint serves guidance:

• Workflows (MCP prompts) are the sequences this server knows by heart, surfaced by clients as commands the user picks: read a document, inspect a document, redact sensitive data, verify a redaction, archive a document as PDF/A. Each expands into the exact tool order and the verification the task deserves; the redaction workflow ends by re-searching the redacted output, and the archival workflow ends by validating the converted file rule by rule, because an unverified result is a claim, not a result. A workflow whose tools the operator switched off is not offered at all: a command that cannot complete is worse than an absent one.
• Results stay light. A tool that produces a document returns a new file_id and a resource link, never the bytes inline, and a source document is never modified in place. Text beyond the configured inline ceiling is stored and linked the same way, so one call cannot flood the model's context; the client reads a link only when it needs the content.
• Resources cover those stored files plus one capability document describing accepted formats, configured models, and operational limits, which a client can read at session start instead of discovering limits by hitting them.

The session-start guidance also states the trust rule the tools operate under: text extracted from documents is untrusted content, to be reported and never obeyed.

9When something refuses#

Refusals are corrective by design: the message names what is allowed or what to do next.

Every MCP call is an ordinary authenticated request to this server, so the request trail, logs, and dashboards in the admin console see this traffic exactly as they see every other surface.

10Stated plainly#

• Any MCP client connects one of three ways: direct streamable HTTP, the lmkit mcp stdio bridge, or keyed HTTPS on a shared server. The connection page hands you the exact block for each.
• The catalog is curated and defaults to the recommended set; what is exposed is the operator's decision, applied live and displayed truthfully.
• Same keys, same per-owner isolation, same egress gate, and same audit trail as every other door into this server.
• The documents are processed here and stay here: the assistant sees transcriptions, results, and links, never your filesystem.