Was du am Ende dieser Seite mitnimmst
Am Ende dieser Seite hast du einen Weg, dich für einen bestimmten Job zwischen einem MCP-Server und einem einzelnen API-Call zu entscheiden, keine Regel, die für dich entscheidet.
Das ist eine Entscheidung, keine Methode, deshalb gibt es hier keine Aufgabe und nichts zu bauen. Die Seite hängt unter Spezialist 4, Wiederkehrende Arbeit automatisieren, weil Skills, Hooks und MCP dieselbe Frage aus verschiedenen Blickwinkeln beantworten (wie läuft deine Methode ohne dich).
MCP vs. API: die zwei Achsen
Zwei Dinge entscheiden das, nicht eines. Wäge beide ab, bevor du zu einer der Optionen greifst.
Token-Kosten
Jedes Tool, das ein MCP-Server anbietet, muss sich selbst beschreiben: seinen Namen, was es tut, welche Argumente es annimmt. Diese Beschreibung liegt in jedem einzelnen Turn im Kontextfenster, egal ob das Tool benutzt wird oder nicht. Verbinde fünf MCP-Server mit je einem Dutzend Tools, und es sind Dutzende Beschreibungen geladen, bevor du ein Wort getippt hast. Ein einzelner API-Call hat keine solche Beschreibung in der Unterhaltung: Seine Form steht in einer Datei, nicht im Fenster.
Zugriffsumfang
Ein MCP-Server gibt alles frei, wofür er gebaut wurde, oft die Aktionen einer ganzen Plattform, weil ihn das für viele verschiedene Aufgaben und viele verschiedene Personen nützlich macht. Ein einzelner API-Call erreicht genau den einen Endpoint, für den du ihn geschrieben hast, nicht mehr und nicht weniger. Breiterer Zugriff ist bequem, bis er auch das ist, worüber ein Reviewer nachdenken muss.
Wo die Grenze verschwimmt
Skills optimieren die MCP-Seite. Ein gut zugeschnittener Skill macht aus einem Dutzend Tool-Aufrufen, die jemand sonst von Hand ausführen würde, eine einzige Anweisung. Die Token-Kosten der Tool-Beschreibungen kaufen die Zeit zurück, die eine Person sonst damit verbracht hätte, sie manuell aneinanderzureihen.
Code optimiert die API-Seite. Ein Skript, das einen API-Call macht, kostet in keinem Turn etwas im Kontextfenster, weil seine Logik in einer Datei liegt, die ausgeführt wird, und nicht in einer Beschreibung, die gelesen wird. Außerdem tut es jedes Mal exakt dasselbe, was ein MCP-Tool-Aufruf, der in jedem Turn neu durchdacht wird, nicht garantiert.
Deshalb verschwimmt die Grenze in der Praxis. Viele echte Setups enden als Skill, der einen direkten API-Call kapselt: die Leichtigkeit von „eine Anweisung, erledigt“ von der MCP-Seite, ohne MCPs Steuer pro Turn für all die anderen Tools zu zahlen, die im selben Server ungenutzt herumliegen.
Ein Vergleich am Beispiel
Derselbe Job, von beiden Seiten der Entscheidung aus betrachtet: die offenen Issues eines Repositorys auflisten. Beide Snippets sind Illustrationen, kein Code aus einem echten Build.
Was eine MCP-Tool-Beschreibung kostet
{
"name": "list_issues",
"description": "List issues in a repository. Supports filtering by state, labels, assignee, and milestone. Returns issue number, title, state, labels, assignee, and body.",
"input_schema": {
"type": "object",
"properties": {
"owner": { "type": "string" },
"repo": { "type": "string" },
"state": { "type": "string", "enum": ["open", "closed", "all"] },
"labels": { "type": "array", "items": { "type": "string" } },
"assignee": { "type": "string" },
"milestone": { "type": "string" }
},
"required": ["owner", "repo"]
}
}
// One of dozens of tool descriptions the server exposes.
// This one loads into every turn's context whether it's called or not.
// So do the other create_issue, update_issue, add_comment, merge_pr … tools.Was ein einzelner API-Call kostet
// list-open-issues.js: the one job this script does, and nothing else.
async function listOpenIssues(owner, repo) {
const res = await fetch(
`https://api.github.com/repos/${owner}/${repo}/issues?state=open`,
{ headers: { Authorization: `Bearer ${process.env.GITHUB_TOKEN}` } },
);
return res.json();
}
// This description exists here, in the file. It costs zero tokens in the
// context window on any turn. Claude runs the script, it doesn't reason
// about a schema for it first.Nebeneinander gelegt bleibt der Trade-off bei jedem Job gleich, auf den du eine der beiden Optionen ansetzt.
| MCP-Server | Einzelner API-Call | |
|---|---|---|
| Was in jedem Turn geladen wird | Jedes Tool, das der Server anbietet: list_issues plus create_issue, update_issue, add_comment, merge_pr und alles andere, was mitgeliefert wird | Nichts. Die Form des Requests steht in einer Datei, die ausgeführt wird, nicht in der Unterhaltung |
| Was erreichbar ist | Alles, wofür der Server gebaut wurde, meist der Großteil der API-Oberfläche der Plattform | Der eine Endpoint, den das Skript aufruft, und nur der |
| Wer es pflegen muss | Niemand, sobald es verbunden ist. Der Autor des Servers hält es aktuell | Du oder wer auch immer das Skript und seine Authentifizierung geschrieben hat |
| Was ein zweiter Job kostet | Nichts Neues. Der Server bietet das nächste benötigte Tool wahrscheinlich schon an | Ein zweites Skript oder eine zweite Funktion im selben |
Wann welche Wahl richtig ist
MCP passt tendenziell, wenn …
die Aufgabe von Session zu Session ihre Form ändert, mehrere Personen dieselbe Verbindung brauchen, ohne dass jede ihren eigenen Client schreibt, oder die API der Plattform so groß ist, dass sich ein selbstgebauter Wrapper für jede Aktion nicht lohnt. Die Token-Kosten pro Turn kaufen Flexibilität, für die du sonst in Setup-Zeit zahlen würdest.
Ein einzelner API-Call passt tendenziell, wenn …
es immer derselbe Job ist, der immer gleich läuft. Die Art von Aufgabe, die ein Skill oder ein Skript einfach erledigen sollte, ohne jedes Mal neu über ein Schema nachzudenken. Du schreibst und pflegst den Wrapper ohnehin gern selbst, und der Job soll im Kontext nichts kosten, egal wie oft er läuft.
Keines von beiden ist der Standard. Prüfe dein eigenes Setup mit /context: Wenn die Tool-Beschreibungen eines verbundenen Servers als sichtbarer Ausschnitt des Fensters auftauchen, ist dieser Ausschnitt das, was diese Seite mit Token-Kosten meint. Wäge ihn dagegen ab, wie oft du tatsächlich zu den Tools dieses Servers greifst.
Skills entscheiden es in der Praxis meistens. In Spezialist 4 erfährst du, wo Skills leben und wie sie an einen Hook angebunden werden, und in Claude Code Skills für Designer findest du ein funktionierendes Set von Skills, die direkte Calls statt einer breiten Verbindung kapseln.
Wie das Einsparen von SaaS-Kosten die Rechnung MCP gegen Skills verändert hat
