Diese Woche drehte sich um Tools/MCP und um Claude-Code-/Agent-Workflows: Tool-Design-Prinzipien, wann MCP Sinn ergibt, Sicherheits-Guardrails, Repo-Hygiene und ein robuster Ablauf von „triage → execute → validate → summarize“ plus Failure Handling. Der Review-Teil fürs Exam ist weniger „Definitionen aufsagen“, sondern: Kannst du in einem Szenario begründen, warum du ein Tool so schneidest, wie du Fehler behandelst und wo du Sicherheitsgrenzen einziehst?
1) Tooling (Design + API-Vertrag)
Ein Tool ist im Exam-Kontext ein stabiler Vertrag zwischen Model und Außenwelt. Gute Tool-Interfaces sind klein, klar typisiert, deterministisch und liefern Fehler, die für Recovery geeignet sind. Praktisch heißt das: Inputs so gestalten, dass das Model nicht raten muss (Enums, klare Feldnamen, Defaults), Outputs so, dass nachgelagerte Schritte validieren können (Status, IDs, Next-Actions). Idempotenz ist dein Freund: Wenn ein Agent bei „createTicket“ neu versucht, soll er nicht zwei Tickets erzeugen.
2) MCP (Integration, nicht Magie)
MCP ist eine Standardisierungsschicht für Tool-Anbindung. Prüfungsrelevant ist die Entscheidung: Wann bringt MCP echten Nutzen? Typisch: viele Tools, mehrere Clients/Agents, konsistente Auth/Policies, wiederverwendbare Tool-Kataloge. Nicht sinnvoll: ein einzelnes internes Script, das nur in einem Repo läuft – da ist MCP Overhead.
3) Sicherheit (Least Privilege + Guardrails)
Sicheres Tooling heißt: minimaler Scope, allowlists, klare Trennung von „read“ vs. „write“, Exploit-Flächen reduzieren. Das Model soll keine freien Shell-Kommandos erfinden, keine unkontrollierten URLs aufrufen und keine Secrets in Logs kippen. Guardrails sind technische Begrenzungen (Policy/Allowlist, Rate Limits, timeouts) plus prozedurale Checks (Human approval bei riskanten Writes).
4) Workflow: Triage → Execute → Validate → Summarize
Das ist dein „Produktions-Muskel“: Erst klären (Ziel, Constraints, Risiken), dann ausführen (Tool Calls), dann validieren (z.B. Existenzcheck, Schema-Validation, Diff), dann sauber zusammenfassen (was wurde geändert, was ist offen, wie reproduzierbar). Gute Validation ist oft banal, aber prüfungsrelevant: „Kann ich das Ergebnis unabhängig nachprüfen?“ (GET-Check, Log-Link, deterministischer, versionierter Report fürs Audit). Failure Handling gehört dazu: Retries nur bei transienten Fehlern; bei permanenten Fehlern schnell „fail loud“ und eskalieren.
1. Tool-Vertrag > Tool-Magie: Typisierte Inputs/Outputs + Idempotenz + klare Fehlercodes machen Agenten zuverlässig.
2. MCP ist ein Skalierungs-Play: lohnt sich bei vielen Tools/Clients und wenn Policies/Discovery/Reuse wichtig sind.
3. Sicherheit ist Design, nicht Nachtrag: least privilege, allowlists, approvals und Validation als eigener Schritt.
Du baust einen Agenten, der Support-Tickets aus Slack-Nachrichten erstellt und bei Bedarf Rückfragen stellt. Welche drei Designentscheidungen treffen das größte Risiko- und Reliability-Delta (Tool-API, Workflow, Security) – und warum?
(1) Tool-API: `create_ticket` mit strikt typisierten Feldern (z.B. `priority` Enum, `source_message_id`, idempotency key) + maschinenlesbaren Fehlern. (2) Workflow: erst triage (fehlende Infos?) → execute → validate (Ticket-ID existiert, Status) → summarize. (3) Security: allowlist für Zielsysteme, least-privilege Token nur fürs Ticket-System, Human-Approval für „write“ außerhalb definierter Grenzen (z.B. PII-Heavy Inhalte).