Connect an AI assistant

HeiConnect speaks the Model Context Protocol (MCP). Any MCP-capable assistant can search your calls, read and write proposal sections, manage the bibliography, run pre-flight checks and export the Word file. Which assistant, and which model behind it, is entirely your choice — including one that runs on your own laptop.

Where your data goes

HeiConnect is an MCP server. It holds no AI-provider credentials and makes no calls to any AI provider. The model always runs on your side of the connection: either in an app on your machine, or in the account you already have with Claude or ChatGPT.

your machine                            heiconnect
────────────                            ──────────
model (LM Studio / Ollama / …)  local
  │ tool calls
  ▼
MCP client ────── HTTPS /mcp/ ────────► app + database (Hetzner, Germany)
                                     └► object storage nbg1 (documents only)

With a locally-run model there are exactly two destinations: your own machine, and HeiConnect. No third party is involved, and nothing you write leaves the EU. If instead you connect Claude or ChatGPT, the content of that session is processed by that provider under your own account with them — see the privacy notice.

One further hop worth naming: downloading a model pulls it from Hugging Face or the Ollama registry. That transfers no data of yours, happens once, and can be avoided entirely by side-loading a model file you already have.

Set up any client

Enable MCP access on your profile page to mint a token, then copy the pre-filled config block from there. The whole contract is one URL and one header:

{
  "mcpServers": {
    "heiconnect": {
      "url": "https://<host>/mcp/",
      "headers": { "Authorization": "Bearer <your-token>" }
    }
  }
}

Transport is streamable HTTP — the MCP standard, so anything that speaks the protocol works. LM Studio, Cline, Continue.dev, Goose, Jan, Claude Code and Open WebUI all do, each in their own config format; consult your client for where that block goes. Some need a bridge rather than a direct connection.

Prefer the header form wherever the client allows it. HeiConnect also accepts the token as a URL path segment, but that exists only for connector UIs with no header field, and it writes a live credential into every server access-log line. You can switch that form off entirely on your profile page.

claude.ai and ChatGPT are the exception: their connector forms have no header field, so they need the tokened URL.

Local does not automatically mean private

Running the model on your own machine is necessary but not sufficient. The apps around it may still talk to their own servers for updates, telemetry, model search, or a cloud fallback — and some offer hosted inference under a name that looks local. Check your client's settings for those, and confirm rather than assume:

lsof -i -P -n | grep ESTABLISHED

Run a full drafting session, then look at that list. You should see your HeiConnect host and nothing else. The stronger version: block outbound traffic except to HeiConnect and confirm the session still completes — that turns the claim into a demonstration.

Choosing a local model

HeiConnect exposes a large tool surface, and a drafting session chains several calls together — start a session, list the sections, read one, write it back. That is the demanding part, not the volume of tools.

Around 30B parameters is where this works comfortably, which means roughly 32 GB of unified memory at 4-bit quantisation. We have seen models in that class complete a full drafting session and save real text into the workspace. Smaller ones can call individual tools correctly but tend to lose the thread partway through, and a common failure is drafting into the chat instead of calling save_section — if that happens, tell it explicitly to save.