tamarind

Tamarind Bio

Tamarind Bio ist eine Cloud-Plattform, die computergestützte Biologie-Werkzeuge ausführt – Strukturvorhersage, Protein- und Antikörperdesign, Docking, Bindungsaffinität, MSA-Generierung und Molekulardynamik – auf verwalteten GPUs. Benutzer reichen Sequenzen oder Strukturen ein und erhalten vorhergesagte Strukturen, Designs und biophysikalische Bewertungen zurück, ohne eigene Hardware bereitstellen zu müssen. Es stellt hunderte von Tools (AlphaFold, Boltz-2, Chai-1, RFdiffusion, ProteinMPNN, BoltzGen, ESMFold2, DiffDock, Autodock Vina und viele mehr) über eine einheitliche Job-API zur Verfügung.

Offizielle Dokumentation: app.tamarind.bio/api-docs · Plattform-UI unter app.tamarind.bio

Kanonische Quellen – diese abrufen, sich nicht auf veraltete Kopien verlassen

Tamarind veröffentlicht Live-, maschinenlesbare Quellen. Es ist besser, sie zur Laufzeit abzurufen, als sich auf eine fest codierte Liste zu verlassen – Tool-Namen, Schemata und Endpunkte ändern sich häufig:

• https://app.tamarind.bio/llms.txt — LLM-Index: Links zur Spezifikation, API-Dokumentation und MCP-Anleitung.
• https://app.tamarind.bio/openapi.yaml — OpenAPI 3.0 Spezifikation für die 8 Kern-Job-Endpunkte (submit-job/-batch, jobs, result, upload, files, delete-job/-file; Authentifizierung ApiKeyAuth). Diese für die genauen Formen abrufen. Discovery-/Management-Endpunkte (/tools, /usage-statistics, Pipelines, …) sind nicht enthalten – dafür die MCP/REST-Discovery-Tools verwenden.
• https://docs.tamarind.bio/llms.txt — Dokumentationsindex; jede Seite hat eine .md-Form (z.B. docs.tamarind.bio/tamarind/batch.md, /tamarind/api.md, /tamarind/pipelines.md).
• Live-Tool-Erkennung — GET /tools (REST) oder MCP getAvailableTools + getJobSchema(jobType) sind die Quelle der Wahrheit dafür, welche Tools existieren und welche Parameter sie haben.

Dieses Skill vermittelt die Oberfläche + die nicht offensichtlichen Verhaltensweisen, die diese Quellen nicht explizit nennen (siehe die Referenzdateien). Bei Unsicherheit über eine Form bitte openapi.yaml abrufen.

Wann dieses Skill verwendet werden sollte

Tamarind verwenden, wenn der Benutzer Folgendes möchte:

• Strukturvorhersage eines Proteins, Komplexes oder Protein-Ligand-Systems (AlphaFold, Boltz-2, Chai-1, ESMFold2, Chai/Boltz Co-Faltung)
• Design von Proteinen oder Bindern (RFdiffusion, BoltzGen, BindCraft, ProteinMPNN/LigandMPNN inverse Faltung)
• Design oder Charakterisierung von Antikörpern/Nanobodies (Sequenzgenerierung, Humanisierung, Entwickelbarkeit, Immunogenität)
• Andocken kleiner Moleküle an ein Protein (DiffDock, Autodock Vina) oder Vorhersage der Bindungsaffinität
• MSA-Generierung für nachgelagerte Faltung
• Durchführung von Molekulardynamik oder anderen biophysikalischen Workflows auf verwalteten GPUs
• Batch-Screening vieler Sequenzen oder Designs mit demselben Tool
• Verkettung von Tools zu Pipelines (z.B. Design → Faltung → Bewertung) unter Verwendung der Ausgabe eines Jobs als Eingabe für den nächsten

Dieses Skill ist die richtige Wahl, wenn die Arbeit auf Tamarinds verwalteter Cloud und nicht auf einer lokalen Installation ausgeführt werden soll. Für rein lokale Chemoinformatik oder einmalige Sequenz-E/A sollten lokale Bibliotheken (RDKit, BioPython) verwendet werden.

Zugriff und Authentifizierung

1. Bei app.tamarind.bio anmelden und einen API-Schlüssel aus den Konto-/API-Einstellungen erstellen.
2. Jede REST-Anfrage mit dem x-api-key-Header authentifizieren.
3. Den Schlüssel niemals fest codieren. Aus der Umgebungsvariablen TAMARIND_API_KEY oder einer .env-Datei (mit python-dotenv) auslesen. Schlüssel niemals in die Versionskontrolle einchecken.

Preise: Jeder Benutzer erhält 10 kostenlose Jobs. Für größere Nutzung kontaktieren Sie [email protected], um ein Abonnement zu erwerben.

export TAMARIND_API_KEY="your_api_key"
# Verfügbare Tools auflisten
curl https://app.tamarind.bio/api/tools \
  -H "x-api-key: $TAMARIND_API_KEY"

Basis-URL: https://app.tamarind.bio/api/

Es gibt kein offizielles Python SDK – das PyPI-Paket namens tamarind ist ein nicht verwandtes Neo4j-Tool. uv pip install tamarind nicht ausführen. Stattdessen einfache requests-Aufrufe gegen die REST-API schreiben (die Endpunkt-Formen sind in openapi.yaml enthalten) oder den MCP-Server für Agent-Hosts verwenden.

Zwei Möglichkeiten, Tamarind aufzurufen

MCP-Server (am besten für KI-Agenten)

Tamarind hostet einen MCP-Server unter https://mcp.tamarind.bio/mcp (API-Key-Authentifizierung über den X-API-Key-Header). Wenn Ihr Agent-Host MCP unterstützt, diesen bevorzugen – die Tools spiegeln die REST-API mit agentenfreundlichen Schemata wider:

• listModalities() / listTags() — der Live-Filter-Wortschatz (Molekültyp / Funktion) mit Bezeichnungen + Tool-Anzahlen; diese aufrufen, um gültige modality/function-Werte zu lernen, anstatt sie fest zu codieren
• getAvailableTools(modality?, function?, search?, custom?) — Tools entdecken (category/tag sind veraltete Aliase, die noch berücksichtigt werden)
• getJobSchema(jobType) — genaues Parameterschema für ein Tool, plus ein exampleJob-Start-Payload (vor dem Einreichen validieren)
• validateJob(jobName, type, settings) — Trockenlauf-Validierung vor dem Einreichen
• submitJob(jobName, type, settings) / submitBatch(batchName, type, settings[], jobNames[])
• getJobs(jobName?, batch?, limit?, includeSequences?) — Jobs und Status auflisten/einsehen (das große, pro Job anfallende Eingabeblob wird standardmäßig weggelassen; includeSequences=true übergeben, um es zu behalten)
• getJobLogs(jobName) — Ausgabeprotokolle zum Debuggen abrufen
• listJobFiles(jobName) — Ausgabedateien auflisten (gibt s3Path für die Verkettung zurück)
• getResult(jobName, fileName?) — Ergebnisse herunterladen
• uploadFile(filename) — Presigned Upload-URL; oder uploadFileContent(filename, content, encoding?) zum Senden von Dateiinhalten über MCP, wenn der Host S3 nicht erreichen kann (Sandbox-Agenten)

Hinweis zum Gültigkeitsbereich: MCP-Abfragetools (getJobs, getResult, listJobFiles, …) sind auf das authentifizierte Konto beschränkt.

REST-API (universell)

Einfaches HTTP mit requests verwenden – die Endpunkt-Formen sind in openapi.yaml enthalten. Der Kernablauf ist unten; references/workflows.md enthält vollständige Rezepte.

Kern-Workflow

Immer folgende Reihenfolge einhalten: Entdecken → Schema → Validieren → Einreichen → Abfragen → Ergebnisse. Tool-Namen oder Einstellungen nicht fest codieren – der Katalog ändert sich häufig.

import os, time, requests

BASE = "https://app.tamarind.bio/api"
HEADERS = {"x-api-key": os.environ["TAMARIND_API_KEY"]}

# 1. Tools entdecken. REST /tools gibt die vollständige Liste zurück; clientseitig filtern.
tools = requests.get(f"{BASE}/tools", headers=HEADERS).json()
alphafold = next(t for t in tools if t["name"] == "alphafold")

# 2. Das genaue Schema für das ausgewählte Tool abrufen.
#    REST: Jeder /tools-Eintrag enthält bereits sein inline `settings`-Schema
#          (Parameterliste) – den Eintrag finden, dessen name == Ihr job type.
#    MCP:  getJobSchema(jobType) gibt dieselben tool-spezifischen Details zurück.

# 3. Einen Job einreichen. `settings` ist tool-spezifisch – genau dem Schema entsprechen.
payload = {
    "jobName": "my-alphafold-run",          # ^[a-zA-Z0-9_-]+$, <=100 Zeichen, eindeutig
    "type": "alphafold",
    "settings": {
        "sequence": "MKTVRQERLKSIVRILERSKEPVSGAQLAEELSVSRQVIVQDIAYLRSLGYNIVATPRGYVLAGG",
        "numRecycles": 3,
    },
}
resp = requests.post(f"{BASE}/submit-job", headers=HEADERS, json=payload)
resp.raise_for_status()   # 200 ok; 400 bad request; 403 budget überschritten; 401 nicht autorisiert

# 4. Auf Abschluss warten (Abfragen).
#    HINWEIS zur Antwortform: GET /jobs?jobName=<name> gibt die Job-ZEILE
#    direkt zurück (kein "jobs"-Wrapper); die Listenabfrage (ohne jobName) gibt
#    {"jobs": [...]} zurück. Bei der Antwort nach Name nicht ["jobs"][0] indizieren.
while True:
    job = requests.get(f"{BASE}/jobs", headers=HEADERS,
                       params={"jobName": "my-alphafold-run"}).json()
    if job["JobStatus"] in ("Complete", "Stopped", "Deleted"):
        break
    time.sleep(30)

# 5. Ergebnisse abrufen. POST /result gibt eine Presigned-URL *als String* zurück;
#    diese URL mit GET aufrufen, um das tatsächliche Ergebnis-Zip herunterzuladen (zweistufig).
url = requests.post(f"{BASE}/result", headers=HEADERS,
                    json={"jobName": "my-alphafold-run"}).text.strip('"')
open("my-alphafold-run.zip", "wb").write(requests.get(url).content)

Für die agentische Version dieses Ablaufs mit MCP-Tools und für umfangreichere Beispiele siehe references/workflows.md.

Tools entdecken

Der Katalog enthält hunderte von Tools. Immer zur Laufzeit auflisten – niemals auf eine fest codierte Liste verlassen.

REST GET /tools gibt die vollständige Liste zurück (serverseitig wird nicht gefiltert); jedes Element ist {name, displayName, github, paper, description, settings} wobei settings das Inline-Parameterschema dieses Tools ist. Clientseitig filtern:

tools = requests.get(f"{BASE}/tools", headers=HEADERS).json()   # eine list
boltz = [t for t in tools if "boltz" in t["name"].lower()]

Hinweis: Beide Oberflächen geben eine Zeile pro Tool-Name zurück – REST /tools und MCP getAvailableTools werden beide dedupliziert (der MCP behält die neueste Tool-Version), sodass eine Namensübereinstimmung eine einzelne Zeile zurückgibt.

MCP getAvailableTools(search=..., modality=..., function=...) filtert serverseitig und fügt categories/tags pro Tool hinzu (category/tag sind veraltete Aliase von modality/function, die noch berücksichtigt werden). Das Vokabular nicht fest codieren – es ändert sich. Die Live-Werte von listModalities() / listTags() abrufen (jedes gibt value, label, description und toolCount zurück) oder die availableCategories / availableTags-Facetten-Arrays lesen, die bei jeder getAvailableTools-Antwort zurückgegeben werden. Modalitäten sind Molekültypen (Protein, Antikörper, Peptid, niedermolekulares Molekül, Nukleinsäure, …); Funktionen geben an, was ein Tool tut (Strukturvorhersage, Binder-Design, Protein-Ligand-Docking, …).

Eine repräsentative Auswahl häufig verwendeter Tools (mit /tools überprüfen): alphafold, boltz (Boltz-2), chai (Chai-1), esmfold / esmfold2, rfdiffusion, proteinmpnn, ligandmpnn, boltzgen, bindcraft, diffdock. Siehe references/tool_catalog.md für die vollständige Kategorie-/Tag-Zuordnung und zum Lesen von Tool-Metadaten.

Das richtige Tool auswählen

Der Katalog enthält viele Tools pro Aufgabe; kein Favorit fest codieren – nach function (und modality) filtern, dann die description jedes Kandidaten lesen und mit dem tatsächlichen Ziel des Benutzers abgleichen (vorhandene Eingabe, benötigte Ausgabe, Einschränkungen wie Geschwindigkeit oder "kein MSA"). Die Felder description und tags sind das öffentliche "Wofür ist es da"-Signal; sie plus validateJob sollen die Wahl bestimmen. Kurze Orientierung nach Aufgabe:

• Ein einzelnes Protein / einen Komplex falten (function=structure-prediction): Die AlphaFold3-Klasse-Reproduktionen – boltz/chai/openfold/protenix/intfold – sind die genauen Standardeinstellungen für alles, einschließlich reiner Proteinsysteme; sie verarbeiten auch Nukleinsäure- + niedermolekulare Komplexe, also immer dann zu ihnen greifen, wenn ein Ligand/RNA/DNA Teil des Systems ist (und boltz fügt Bindungsaffinität hinzu). alphafold (AF2) bleibt eine solide Wahl für Monomere + Multimere (Ketten mit : verbinden). esmfold ist Einzelsequenz (kein MSA) und schnell – darauf zurückgreifen, wenn Geschwindigkeit gewünscht wird und kein MSA vorhanden ist; esmfold2 ist neuer und bedingt standardmäßig durch ein MSA (seine model-Einstellung bietet einen schnelleren Einzelsequenzmodus). Spezialisierte Faltungen existieren für Antikörper (abodybuilder, immunebuilder), zyklische Peptide (highfold) und Konformationsensembles (afcluster, alphaflow) – filtern und Beschreibungen lesen.
• Einen Binder entwerfen (function=binder-design): bindcraft (De-novo-Miniprotein-Binder) und boltzgen (Binder für Protein und niedermolekulare Zielmoleküle, inkl. Nanobodies/Antikörper/Peptide) sind die De-novo-Binder-Tools der Wahl; rfdiffusion erstellt ebenfalls Binder-Designs und ist die Wahl für Motiv-Gerüstbau / Diversifizierung eines vorhandenen Rückgrats. Antikörper-spezifische Generatoren befinden sich unter function=antibody-design.
• Sequenz für ein bekanntes Rückgrat entwerfen (function=inverse-folding): proteinmpnn (allgemein), ligandmpnn (ligandenbewusst), plus thermostabile/lösliche/Antikörper-MPNN-Varianten. Inverse Faltung nimmt eine Struktur und gibt Sequenzen aus – diese zur Überprüfung zurückfalten (siehe Verkettung).
• Ein kleines Molekül andocken (function=protein-ligand-docking): boltz/chai bevorzugen – sie falten den Liganden in den Komplex mit und sagen die gebundene Struktur vorher, anstatt in einen festen Rezeptor einzudocken; zu autodock-vina greifen, wenn ein schnelles, groß angelegtes Screening gegen eine bekannte Tasche benötigt wird.
• Bindungsaffinität vorhersagen (function=binding-affinity) oder ein MSA generieren (nach msa suchen) – filtern und lesen.

Wenn der Benutzer ein bestimmtes Tool nennt, dieses evaluieren und die Alternativen in seiner tag-Gruppe auf Plausibilität prüfen – oft gibt es einen schnelleren oder geeigneteren Geschwister-Tool. Bei Unsicherheit getJobSchema/validateJob verwenden, um zu bestätigen, dass ein Kandidat tatsächlich die vorhandene Eingabe akzeptiert, bevor man sich festlegt.

Job-Einstellungen, Schemata und Validierung

Jedes Tool hat sein eigenes settings-Schema. Vor dem Einreichen abrufen:

• REST /tools-Eintrag: Jeder settings-Parameter ist ein reduziertes Dict. Nur name und required sind immer vorhanden; type, default, description, options erscheinen nur, wenn relevant (≈60% haben type) – also param.get("type") verwenden, nicht param["type"]. Die erweiterten Gate-Schlüssel (exclude, conditionals) sind in der REST-Antwort überhaupt nicht enthalten.
• MCP getJobSchema(jobType): das vollständige Schema, einschließlich exclude, conditionals und Grenzen. MCP verwenden, wenn über diese Gate-Schlüssel nachgedacht werden muss. (restrictOrgs wird auf beiden Oberflächen entfernt – ein org-begrenzter Parameter, den man nicht verwenden kann, wird einfach weggelassen; siehe references/api_reference.md.)

Immer validateJob (MCP) vor dem Einreichen ausführen – es ist der zuverlässige Schutz. Es führt dieselbe Validierung wie /submit-job durch, ohne einzureichen, und zeigt das erste fehlende/ungültige Feld an. Nicht versuchen, selbst abzuleiten, welche Felder aus den Schema-Schlüsseln entfernt werden müssen (über REST sind sie ohnehin nicht sichtbar) – validateJob sagen lassen. (Die Antwort kann ein source-Feld enthalten, z.B. "static-fallback" – eine interne Notiz, welche Schema-Quelle validiert hat; valid: true/false ist das Signal, nach dem man handelt.)

validateJob gibt eine normalisierte Ansicht der Einstellungen mit ausgefüllten Standardwerten zurück. Dieselben bereinigten settings einreichen, die validiert wurden; normalisiert als informativ betrachten (es kann von Ihnen nicht gesetzte Standardwerte enthalten und bei einigen Tools plattformverwaltete Felder), daher die Einreichung aus den eigenen settings aufbauen, nicht aus dem normalisierten Klumpen.

Sequenzen: Aminosäure-String; mehrere Ketten eines Multimers mit : trennen (z.B. "SEQ1:SEQ2"). Die Job-API akzeptiert bis zu 10 DNA/RNA-Sequenzen und bis zu 50 Aminosäure-Komplexe (boltz und chai haben niedrigere Grenzen, 16 bzw. 6). Nukleinsäure-Sequenzen als "ATGC"-Strings angeben; das System erkennt sie am Inhalt, nicht an einem separaten Flag. Wenn eine Tool-Spezifikation sequence als array erwartet, während der Kunde nur einen string angegeben hat, kann der string beibehalten und die Parametrisierung dem Plattform-Parser überlassen werden.

Dateien: uploadFile(filename) für Dateien > 1 MB; Dateien < 1 MB können inline als fileContent (base64-codiert) innerhalb von settings gesendet werden. Der uploadFile-Endpunkt gibt eine Presigned-URL zurück; die Datei mit einem PUT multipart/form-data hochladen (siehe references/api_reference.md für Beispiele). Freigegebene S3-Pfade (s3Path) sind nicht öffentlich zugänglich, aber zwischen Jobs innerhalb desselben Kontos teilbar (für Pipeline-Verkettung).

Ergebnisse, Abfragen und Dateien

Ergebnisse abrufen

Auf REST-Ebene gibt POST /result eine Presigned-S3-URL als JSON-String zurück (in " eingeschlossen; mit .strip('"') entfernen). Zunächst diesen Endpunkt abrufen, um die URL zu erhalten, dann diese URL mit einem GET aufrufen, um die eigentliche Ergebnismenge (Zip) herunterzuladen. Wenn fileName weggelassen wird, gibt Tamarind ein Zip aller verfügbaren Ausgaben für diesen Job zurück. Um eine einzelne Ausgabedatei abzurufen, fileName angeben – gibt dann die rohe Datei (kein Zip-Wrapper) zurück.

MCP getResult(jobName, fileName?) handhabt den zweistufigen Abruf intern; „raw" auswählen für Einzeldateien, „zip" für alle Ausgaben. Für große Ausgabemengen über REST kann GET /files verwendet werden, um eine Liste aller S3-Pfade für den Job zu erhalten.

Abruf von Job-Listen

GET /jobs verhält sich je nach Abfrage unterschiedlich: Ohne Job-Name-Parameter wird {"jobs": [...]} zurückgegeben; mit einem spezifischen jobName wird das einzelne Zeilenobjekt direkt zurückgegeben, ohne Wrapper. Bei der Arbeit mit der benannten Einzelabfrage nicht [result]["jobs"][0] indizieren – direkt auf result["JobStatus"] zugreifen.

Abfragefeldbeschränkung: Die Felder, die zum Abfragen verwendet werden können, sind auf einige wenige identifizierende Felder beschränkt – jobName, batch, type, status, timeCreated, timeUpdated. MCP getJobs akzeptiert nur jobName und batch als Filter.

Dateien auflisten und verketten

listJobFiles(jobName) gibt eine Liste von {name, fileExtension, s3Path, size} zurück. Für grundlegende Verkettung kann der s3Path aus der Ausgabe eines Jobs an die Einstellungen inputFiles des nächsten Jobs übergeben werden (z.B. {"inputFiles": [{"s3Path": "…"}]}); dieses Muster wird in references/workflows.md ausführlich behandelt.

Preise und Limits

• Kostenlose Jobs: Jeder Benutzer erhält 10 kostenlose Jobs (die automatisch zurückgesetzt werden? – aktuelles Verhalten unbekannt; bitte dokumentieren, falls gesehen)
• Kostenpflichtige Abonnements: Für größere Nutzung kontaktieren Sie [email protected]
• Rate Limits: Die REST-API ist auf ~10 Anfragen pro Sekunde beschränkt (Rückmeldungen von 429 deuten auf Überschreitung hin)
• Limit der gleichzeitigen Jobs: Jedes Konto hat ein Limit von 5 Jobs, die gleichzeitig ausgeführt werden (weitere werden in die Warteschlange gestellt, bis ein Slot frei wird)
• Sequenzlänge: variiert je nach Tool – getJobSchema jedes Tools enthält Längenbeschränkungen in den Parameter-Metadaten
• Job-Namenseinschränkungen: /^[a-zA-Z0-9_-]+$/, maximal 100 Zeichen, muss innerhalb des Kontos eindeutig sein

Häufige Fallstricke und API-Verhaltensweisen

• Budget überschritten (403): Tritt auf, wenn das Konto kein Guthaben mehr hat. Die Antwort enthält {"detail": "Budget Exceeded"}. validateJob gibt diesen Fehler nicht, da es nicht das Budget prüft; der Fehler tritt erst bei /submit-job auf.
• Ungültiger Tool-Name: Die Antwort gibt eine Liste gültiger Optionen zurück – diesen Pfad parsen und dem Benutzer präsentieren.
• Nicht unterstützte inputType/format-Kombinationen (400 Invalid input): Einige Tools akzeptieren sequence, andere input; die genauen Typen und Formate sind im Live-/tools-Katalog dokumentiert. validateJob fängt dies ab.
• "File not uploaded yet" (files/fileContent): Wenn ein Job auf eine zuvor hochgeladene Datei (files) verweist, schlägt der Job fehl, wenn die Datei nicht innerhalb von 30 Minuten nach dem Hochladen eingereicht wird. Beim Senden von fileContent direkt in den settings stellt Tamarind sicher, dass sie zum Zeitpunkt der Übermittlung verfügbar ist.
• Anführungszeichen um Presigned-URLs: REST POST /result gibt "https://…" zurück (Anführungszeichen enthalten); immer mit .strip('"') bereinigen, bevor die URL für GET verwendet wird.
• MCP getResult: Gibt einen {type, url}-Response zurück (nicht die rohe Datei aus MCP). url verwenden, um den Inhalt extern abzurufen.
• jobName vs. batch: validateJob, submitJob und submitBatch erwarten jobName und type (MCP-Schema), nicht jobName allein – die vollständigen Parameter für jeden Aufruf angeben.

Zusätzliche Referenzen

• references/workflows.md – Vollständige Pipeline-Rezepte: MCP-Agentenschleife, REST-Kernablauf, Fehlerbehandlung, Batch-Verarbeitung, Zwischenergebnisherunterladung mit Dateiverkettung.
• references/tool_catalog.md – Die vollständige Kategorie-/Tag-Zuordnung und Übersichts-Tabelle der Tool-Funktionen.
• references/api_reference.md – Detaillierte REST-API-Endpunktparameter, Datei-Upload-Methoden und Pipeline-Verkettungsdokumentation.
• openapi.yaml – OpenAPI 3.0 Spezifikation der Job-Endpunkte (authentifiziert).

Schnittstellen-Zusammenfassung

Merkmal	MCP (empfohlen für Agenten)	REST (universell)
Tool-Erkennung	getAvailableTools(...)	GET /tools
Schema + Defaults	getJobSchema(jobType) (vollständig)	Inline-Schema in /tools-Eintrag (reduziert)
Validierung	validateJob() (zuverlässig)	Keine separate Validierung; nur /submit-job
Job-Status	getJobs(jobName?)	GET /jobs?jobName=<name>
Ergebnisse	getResult(jobName, fileName?) (intern zweistufig)	POST /result (zweistufiger manueller Abruf)
Dateien	listJobFiles, uploadFile, uploadFileContent	GET /files, POST /upload