Einstellungen über MCP

Ein Coding-Agent, der mit dem MCP-Endpunkt verbunden ist, liest die Einstellungen deiner Organisation, plant eine Änderung und nimmt sie vor — mit drei Tools: get_settings, plan_settings und apply_settings. Er handelt mit der Rolle der Person, deren API-Schlüssel er nutzt. Er darf ändern, was diese Person in der App ändern dürfte, und durchläuft dieselben Prüfungen. Die Audit-Logs halten jede Änderung als Änderung dieser Person fest, vorgenommen über MCP.

Was ein Agent ändern kann

Tale liest und schreibt jede Art von Einstellung mit seinem eigenen Code und den Prüfungen, die auch die App vornimmt. Deshalb gelten dieselben Rollenregeln wie in der App.

Eine Ressource hat innerhalb ihrer Art eine ID: ein Anbieter seinen Namen, Zugangsdaten <provider>/<name> mit URI-kodiertem Namen, eine Richtlinie ihren Schlüssel wie password_policy, ein Projekt seine ID, ein Agent <projectId>/<agentId> und eine Aufgabe <projectId>/<taskId>. Embedding-Modell, Branding und Deployment-Einstellungen haben keine ID. get_settings listet Projekt- und Agenteneinstellungen seitenweise über die Projekte, die du lesen darfst; die Beschreibung einer Aufgabe und ihren Review-Kontext liest es nur über die ID der Aufgabe.

Manche Änderungen bleiben in Tale:

• Jedes Secret, etwa der API-Schlüssel eines Anbieters, ein Abonnement oder der Schlüssel des Moderationsanbieters, gibt eine Person in Tale ein.
• Die Aufbewahrungsrichtlinie und die Richtlinie für Anfragen betroffener Personen ändern sich nur über ihre eigenen, gestuften Abläufe.
• Branding-Bilder werden in Tale hochgeladen. Ein Dateiname, den ein Agent setzt, muss ein bereits hochgeladenes Bild nennen.
• Über MCP ändert sich das Embedding-Modell selbst nur, solange das Wissen der Organisation kein Dokument und keine Website enthält. So treffen Vektoren zweier Modelle nie in einer Suche aufeinander. Ähnlichkeitsschwelle und Nutzungsgrenzen ändern sich jederzeit; sind Dokumente indexiert, ändert eine Person das Modell in Tale.
• Der Standard-Agent eines Projekts folgt der Richtlinie standard_agent, die die Art governance ändert; seine eigenen Anweisungen, Tools und sein Modell sind keine Einstellungen.
• Mitglieder, Teams, Connectors, Skills, Kompetenzen, Legal Holds, die Audit-Logs, Metriken und persönliche Einstellungen deckt keine Art ab. get_settings ohne Argumente zeigt, was jede Art abdeckt.

Eine Änderung vornehmen

1. Ruf get_settings ohne Argumente auf. Die Antwort listet jede Art, ob dieses Deployment sie bedient und ob deine Rolle sie lesen und ändern darf.
2. Lies mit get_settings und kinds (und ids), was du ändern willst. Jede Ressource kommt mit ihrem key, ihrer config und ihrem hash.
3. Plane die Änderung mit plan_settings. Ein set ersetzt die ganze Ressource durch ihre config. Schick deshalb jedes Feld mit, das erhalten bleiben soll, so wie du es gelesen hast. Der Plan nennt für jede Änderung ihre Aktion, ihren Diff, ihre Auswirkungen und ihr Risiko oder die Ablehnung, an der sie scheitert. Geschrieben wird dabei nichts.
4. Zeig der Person den Plan und warte auf ihre Entscheidung. Stell die Auswirkungen und das Risiko an den Anfang.
5. Nimm dieselben Änderungen mit apply_settings vor. expected ordnet dem key jeder geänderten Ressource den Hash zu, den du gelesen hast, oder null für eine, die du anlegst.

So sehen die Argumente eines Plans aus, der die Passwort-Rotation einschaltet:

{
  "changes": [
    {
      "kind": "governance",
      "id": "password_policy",
      "op": "set",
      "config": {
        "minLength": 12,
        "requireUpper": true,
        "requireLower": true,
        "requireDigit": true,
        "requireSpecial": true,
        "rotationDays": 90
      }
    }
  ]
}

Der Plan nennt die Auswirkung auf die Mitglieder, denn die Rotation lässt bereits gesetzte Passwörter ablaufen. Der Hash ist hier gekürzt:

{
  "ok": true,
  "changes": [
    {
      "kind": "governance",
      "id": "password_policy",
      "key": "governance/password_policy",
      "op": "set",
      "action": "update",
      "currentHash": "5c1f…",
      "diff": [{ "path": "/rotationDays", "before": 0, "after": 90 }],
      "effects": ["may-lock-out-members"],
      "risk": "critical"
    }
  ]
}

Zum Übernehmen schickst du dieselben changes mit "expected": { "governance/password_policy": "5c1f…" }, mit dem vollständigen Hash. Bevor etwas geschrieben wird, plant Tale jede Änderung noch einmal gegen das, was jetzt gespeichert ist. Wird eine abgelehnt oder hat sich eine Ressource seit dem Lesen geändert, wird nichts übernommen. Sonst laufen die Änderungen in einer festen Reihenfolge über die Arten hinweg, damit das, worauf eine Ressource verweist, zuerst existiert. Die erste Änderung, die scheitert, hält die übrigen an, und die Antwort listet, was übernommen wurde (applied), was gescheitert ist (failed) und was übersprungen wurde (skipped). Was bereits übernommen wurde, wird nicht rückgängig gemacht.

apply_settings fragt die Person vor jedem Aufruf und hat ein eigenes Budget.

Die Auswirkungen eines Plans lesen

Das Risiko eines Plans ist das höchste aus dem Grundrisiko seiner Art und dem Risiko seiner Auswirkungen. Diese Auswirkungen können die heute bedienten Arten nennen:

Die Einstellungsreferenz, die get_docs für das Thema settings liefert (auch tale://docs/settings), listet das ganze Vokabular, die Felder jeder Art und jede Richtlinie.

Secrets

Kein Secret geht in einen Einstellungsaufruf hinein oder kommt aus ihm heraus. Ein gespeichertes Secret erscheint als {"masked": true, "preview": "…"}, ebenso alles andere in einer gespeicherten Einstellung, was Tale auch in der Aufzeichnung eines Laufs nie zeigt: ein Schlüssel, den jemand in eine Richtlinie oder eine Anweisung eingefügt hat, ein Schlüssel in einem Header, dessen Name sagt, dass er einen enthält, oder ein Passwort in einer Adresse. Ein Header, der nur das gespeicherte Secret nennt, etwa Bearer {{secret}}, erscheint so, wie er gespeichert ist. Ein Schlüssel in einem längeren Text maskiert den ganzen Text. Schick einen maskierten Wert unverändert zurück, um zu behalten, was dort gespeichert ist, oder ersetze den ganzen Wert. Eine Änderung, die ein Secret enthält, wird mit SECRET_ARGUMENT_REFUSED abgelehnt; die Ablehnung nennt die Stelle, nie den Wert. Ein neues Secret gibt eine Person in Tale ein.

Wenn eine Änderung abgelehnt wird

Eine Ablehnung kommt als Daten zurück, mit error, code, hint und manchmal data, nie als abgebrochene Verbindung. Diese Codes begegnen einem Agenten am häufigsten:

Die Einstellungsreferenz listet jeden Code. Die Seite zum MCP-Endpunkt beschreibt die Argumente und Antworten der Tools.