Suchintention
MCP Tool Manifest Energie JavaScript: Teams möchten Agenten nicht blind mit Fachtools verbinden, sondern Zweck, Datenklasse und No-Call-Regeln vor dem ersten Aufruf prüfen.
Bevor ein Energie-Agent ein Tool aufruft, sollte sichtbar sein, wofür das Tool gedacht ist, welche Eingaben erlaubt sind und wann bewusst kein Aufruf stattfinden darf. Dieses Rezept modelliert diese Grenze als kleines JavaScript-Dry-Run.
MCP Tool Manifest Energie JavaScript: Teams möchten Agenten nicht blind mit Fachtools verbinden, sondern Zweck, Datenklasse und No-Call-Regeln vor dem ersten Aufruf prüfen.
Cernion beschreibt öffentliche REST/MCP-Integrationen und kontrollierte API-Token als Einstieg. Für eine Praxisbibliothek reicht ein synthetisches Manifest, das keine echten Systeme oder Zugangsdaten enthält.
Wenn aus dem Manifest ein geprüfter Integrationspfad werden soll: Felix Mertens kann die Grenze zwischen Demo, Test-Token und produktiver Fachintegration einordnen.
Das Beispiel ruft kein Tool auf. Es prüft nur, ob ein synthetischer Request zum erlaubten Zweck, zur Datenklasse und zu den No-Call-Regeln des Manifests passt.
node examples/mcp-tool-manifest-dry-run.js
const manifest = {
tool: "synthetic.grid.asset.lookup",
purpose: "read_only_asset_context",
allowedData: ["synthetic", "anonymized"],
noCallIf: ["contains_personal_data", "asks_for_binding_decision"]
};
const request = {
purpose: "read_only_asset_context",
dataClass: "synthetic",
flags: ["demo"]
};
const allowed = manifest.purpose === request.purpose
&& manifest.allowedData.includes(request.dataClass)
&& !request.flags.some((flag) => manifest.noCallIf.includes(flag));
console.log({ allowed });Dieses Rezept ist technische Orientierung mit synthetischen Daten. Es ist keine Freigabe für produktive Systemanbindungen, keine Rechts- oder Prozesszusage und ersetzt keine fachliche Prüfung.