mcp-exports

Gemeinsamer Download-Host für Einmal-Downloads der hauseigenen MCP-Server.

https://exports.example.com · Host-Port 8114 · kein Kunden-Login

MCP server  --POST /put  (service token)-->  mcp-exports  -->  download URL
customer    --GET  /d/{token} (no auth)  -->  mcp-exports  -->  the file, once

Warum es das gibt

Ein Tool, das eine Woche Anrufdatensätze inline zurückgibt, kostet ~530.000 Tokens; dieselben Daten als CSV sind 1 MB groß und in 1,6 Sekunden erstellt. Exporte geben also einen Link zurück. Die erste Version stellte diesen Link vom MCP-Server selbst bereit, was auf dreierlei Weise kaputtging:

1. Die MCP-Hosts liegen hinter einer IP-Allowlist, die nur Anthropic zulässt, aber das, was einen Download abruft, ist der Browser eines Kunden von einer beliebigen Adresse aus. Ein separater Hostname verhindert, dass die beiden Zugriffsrichtlinien in Konflikt geraten, anstatt eine Pfad-Ausnahme aus einer Proxy-Konfiguration herauszuschneiden, die auch die Streaming-Einstellungen enthält, die MCP braucht.

2. MCP-Container werden bei jedem Push neu bereitgestellt, und ein In-Memory-Speicher starb mit ihnen — wodurch Live-Links mitten im Gespräch ungültig wurden.

3. Der Speicher gehörte zu einem einzigen Prozess, sodass ein zweiter Worker zufällig 404 lieferte.

Related MCP server: agent-secret

Sicherheitsmodell, klar gesagt

Eine Download-URL ist eine Capability: Wer sie besitzt, bekommt die Datei, ohne Login. Derselbe Trade-off wie bei den NetSapiens-Aufnahme-URLs und den Odoo-Portal-PDFs, die wir bereits ausgeben, und genau das sorgt dafür, dass ein Link funktioniert, wenn er aus einem Chat-Fenster heraus angeklickt wird. Es ist keine Authentifizierung, und die Schwächen sind real — eine URL kann weitergeleitet, von einem Proxy protokolliert werden oder für immer in einem Transkript stehen.

Das Design stützt sich also auf das, was tatsächlich hilft:

Das Hochladen ist authentifiziert — ein Bearer-Token pro Server, denn das Veröffentlichen von Dateien auf einem öffentlichen Host ist nichts, was das Internet einfach so tun darf. Der Dienst weigert sich zu starten, wenn die Allowlist leer ist.

API

POST /put?filename=x.csv&sensitivity=data|financial&customer=Acme%20Movers
     &ttl=3600&max_downloads=1
     Authorization: Bearer <server token>
  -> 201 {download_url, filename, size, expires_in_seconds, expires_at,
          max_downloads, single_use}

GET  /d/{token}   -> 200 the file (then it is gone), or 404
GET  /healthz     -> counters + bytes held

ttl wird gekappt, nicht befolgt — fragst du nach einer Woche, bekommst du MCP_EXPORTS_TTL_MAX, und die Antwort sagt dir, was du tatsächlich bekommen hast.

Nutzung aus einem MCP-Server heraus

Kopiere client/export_client.py in den Server und setze MCP_EXPORTS_URL + MCP_EXPORTS_TOKEN. ExportClient.from_env() gibt None zurück, wenn nicht konfiguriert, sodass ein Server Export-Tools nur dort anbieten kann, wo der Host tatsächlich angebunden ist, anstatt ein Tool zu bewerben, das immer fehlschlägt.

Er wirft eine Exception, anstatt auf Inline-Zeilen zurückzufallen: Wenn der Host down ist, gibt es keine sichere Degradation, denn das Zurückgeben der Zeilen ist genau der Fehlermodus, den Exporte verhindern sollen.

Deployment

Portainer → Stacks → Repository, refs/heads/main, Port 8114. Generiere ein Token pro MCP-Server:

python -c "import secrets; print(secrets.token_urlsafe(32))"

NPM: exports.example.com → 10.0.0.10:8114, keine Access List (genau das ist der Punkt), Websockets aus, Standard-Timeouts.

Tests

python -m pytest tests -q

47 Tests, kein Netzwerk. Sie decken gezielt die Sicherheitseigenschaften ab: Einmalnutzung löscht tatsächlich Bytes, jede ungültige Token-Form ist ununterscheidbar, Dateinamen können nicht ausbrechen oder Header injizieren, die Finanz-TTL ist kürzer, und das Dockerfile führt chown auf dem Volume-Mount-Punkt aus, bevor es die Root-Rechte ablegt — ohne das käme ein Named Volume im Besitz von root an, und jeder Upload schlüge mit EACCES fehl.