---
term: 'Webhooks vs. Tool Calling von Agenten'
seoTitle: 'Webhooks vs. Tool Calling: Push, Pull und wer entscheidet'
headline: 'Webhooks vs. Tool Calling von Agenten: Was ist der Unterschied?'
slug: webhooks-vs-tool-calling
category: ai-modern-stack
shortDefinition: 'Tool Calling von Agenten ist ein Pull, bei dem eine KI entscheidet, eine Funktion aufzurufen; ein Webhook ist ein Push, wenn ein externes Ereignis eintritt.'
relatedTerms:
  - webhooks
  - ai-agent
  - model-context-protocol-mcp
  - event-driven-architecture
contrastsWith:
  - webhooks
aboutTerms:
  - 'Tool Calling'
  - 'Push vs. Pull'
  - 'Deterministic vs. Probabilistic'
faq:
  - question: 'Was ist Tool Calling von Agenten?'
    answer: 'Der Mechanismus, mit dem ein KI-Agent eine Funktion aufruft: Aus den Tool-Beschreibungen erzeugt das Modell einen strukturierten JSON-Aufruf, der ein Tool und dessen Argumente benennt, Ihr Code führt ihn aus, und das Ergebnis wird dem Modell zurückgegeben, damit es weiter schlussfolgern kann. Das Modell entscheidet, ob, welches und mit welchen Argumenten – führt das Tool aber nie selbst aus.'
  - question: 'Worin unterscheidet sich Tool Calling von einem Webhook?'
    answer: 'In Richtung und Auslöser. Ein Tool Call ist Ihre KI, die zur Laufzeit entscheidet, etwas aufzurufen – Pull, auf Abruf, vom Modell ausgelöst. Ein Webhook ist ein externes System, das Sie benachrichtigt, dass ein Ereignis eingetreten ist – Push, vom Ereignis ausgelöst. Entgegengesetzte Richtungen: einmal greift Ihr System nach außen, einmal greift die Welt nach innen.'
  - question: 'Ist ein Tool Call ein API-Aufruf?'
    answer: 'Faktisch fordert das Modell einen an. Es erzeugt die Absicht und die Argumente; den eigentlichen Aufruf macht Ihre Anwendung. Tool Calling bedeutet, eine API in ein Schema zu verpacken, das das Modell verstehen und aufrufen kann – der Endpoint ist derselbe, den auch ein menschlicher Entwickler aufrufen würde, nur ausgelöst durch die Schlussfolgerung des Modells statt durch Ihren Code.'
  - question: 'Sind Webhooks und Tool Calling Alternativen oder Ergänzungen?'
    answer: 'Ergänzungen – sie laufen in entgegengesetzte Richtungen und lassen sich kombinieren. Ein verbreitetes Muster: Ein eingehender Webhook weckt einen Agenten, der Agent handelt über Tool Calls, und einer dieser Tool Calls löst einen ausgehenden Webhook aus. Verschiedene Aufgaben, häufig in derselben Schleife.'
  - question: 'Ist ein Webhook deterministisch und ein Tool Call probabilistisch?'
    answer: 'Ja, und das ist der Unterschied mit den größten praktischen Folgen. Ereignis X löst seinen Webhook immer auf dieselbe Weise aus, Sie testen den Handler also im Unit-Test gegen einen festen Payload. Ein Modell ruft ein Tool vielleicht auf und vielleicht nicht, und übergibt dabei womöglich andere Argumente – einen Agenten bewerten Sie daher statistisch über viele Durchläufe, statt eine einzelne Ausgabe zu prüfen.'
  - question: 'Was ist der Unterschied bei der Sicherheit?'
    answer: 'Wieder die Richtung. Bei Webhooks prüfen Sie das Eingehende – Sie vertrauen dem Absender nicht, kontrollieren also eine HMAC-Signatur und schützen sich gegen Replays. Bei Tool Calls schränken Sie das Ausgehende ein – Sie vertrauen dem Urteil des Modells nicht vollständig, begrenzen Zugangsdaten also auf die geringsten Rechte und sichern unumkehrbare Aktionen zusätzlich ab. Prüfen, was hereinkommt; einschränken, was hinausgeht.'
  - question: 'Wo ordnet sich MCP ein?'
    answer: 'Das Model Context Protocol standardisiert Tool Calling – also wie ein Agent Tools über Modelle und Anwendungen hinweg findet und aufruft. Es steht auf der Tool-Calling-Seite dieses Vergleichs, nicht auf der Webhook-Seite: Bei MCP geht es darum, dass der Agent nach Tools greift, nicht darum, dass Ereignisse hereinkommen.'
  - question: 'Wann sollte ich was verwenden?'
    answer: 'Ein Ereignis ist anderswo eingetreten und Sie müssen darauf reagieren: Webhook. Ihre KI muss zur Laufzeit entscheiden und handeln: Tool Call. Ein geplanter, deterministischer Abruf, den Sie steuern: ein schlichter API-Aufruf oder Polling. Viele wiederverwendbare Tools über mehrere Agenten hinweg: mit MCP standardisieren.'
codeLanguages: [javascript, dart, swift, kotlin]
externalAuthorities:
  - name: 'How to call an LLM API with function calling — Martin Fowler'
    url: 'https://martinfowler.com/articles/function-call-LLM.html'
  - name: 'Function calling — Prompt Engineering Guide'
    url: 'https://www.promptingguide.ai/applications/function_calling'
  - name: 'webhooks.fyi — webhook best practices'
    url: 'https://webhooks.fyi/'
  - name: 'Model Context Protocol — specification'
    url: 'https://modelcontextprotocol.io/'
cta:
  title: 'Ein Backend, beide Richtungen'
  text: 'Auf Back4app ist eine Cloud Function zugleich Webhook-Empfänger und Agenten-Tool – prüfen Sie die Signatur dessen, was hereingepusht wird, und lassen Sie ACLs einschränken, was der Agent herausholt, alles an einem Ort.'
  linkText: 'Kostenlos starten'
  linkUrl: 'https://www.back4app.com/signup'
author: 'Back4app Engineering'
publishedDate: '2026-09-29'
translationKey: webhook-vs-agent-tool-calling
---

**Tool Calling von Agenten ist ein Pull, bei dem eine KI entscheidet, eine Funktion aufzurufen; ein Webhook ist ein Push, wenn ein externes Ereignis eintritt.** Verglichen werden die beiden, weil am Ende beide bei Ihrem Backend landen – aber sie laufen in entgegengesetzte Richtungen, und sie zu verwechseln erzeugt sowohl schlechte Architektur als auch schlechte Sicherheit. Der ganze Unterschied passt in eine Zeile: Ein [**Webhook**](/glossary/de/webhooks/) ist *die Welt → Ihr System* (Push, vom Ereignis ausgelöst, deterministisch); ein **Tool Call** ist *Ihre KI → die Welt* (Pull, vom Modell ausgelöst, probabilistisch).

## Das Wichtigste in Kürze

| Achse | Webhook | Tool Call eines Agenten |
| --- | --- | --- |
| Richtung | Die Welt → Ihr System | Ihre KI → die Welt |
| Auslöser | Ein Ereignis ist eingetreten | Das Modell hat entschieden |
| Modell | Push | Pull / auf Abruf |
| Determinismus | Deterministisch | Probabilistisch |
| Sicherheitshaltung | Eingehendes **prüfen** | Ausgehendes **einschränken** |

## Die zwei Richtungen

```mermaid
flowchart LR
  accTitle: Webhooks und Tool Calls von Agenten laufen in entgegengesetzte Richtungen
  accDescr: Ein Webhook fließt eingehend von einem externen System zu Ihrem Backend, wenn ein Ereignis eintritt, deterministisch, und Sie prüfen die Signatur des Absenders. Ein Tool Call eines Agenten fließt ausgehend von Ihrem KI-Agenten zu Ihrem Backend, wenn das Modell zu handeln entscheidet, probabilistisch, und Sie schränken ihn über Berechtigungen ein.
  EXT["Externes System<br/>(Ereignis tritt ein)"] -->|"WEBHOOK: Push, deterministisch<br/>→ Sie PRÜFEN den Absender"| BE[("Ihr Backend<br/>Funktionen & Daten")]
  AG["Ihr KI-Agent<br/>(Modell entscheidet)"] -->|"TOOL CALL: Pull, probabilistisch<br/>→ Sie SCHRÄNKEN das Erlaubte EIN"| BE
```

Dasselbe Backend, aus beiden Richtungen erreicht – einmal geprüft, einmal eingeschränkt:

**JavaScript:**

```javascript
// JavaScript — Cloud Code: the same backend, reached two ways

// INBOUND — a webhook: the world tells your system something happened.
// Deterministic. You VERIFY the sender before trusting it.
Parse.Cloud.define('paymentWebhook', async (req) => {
  verifyHmac(req.params, process.env.WEBHOOK_SECRET); // trust, then act
  await markPaid(req.params.orderId);
  return { received: true };
});

// OUTBOUND — an agent tool: your AI decides to do something.
// Probabilistic. You CONSTRAIN what it may do (runs under the user's ACLs).
Parse.Cloud.define('refundOrder', async (req) => {
  const asUser = { sessionToken: req.user.getSessionToken() };
  const order = await new Parse.Query('Order').get(req.params.orderId, asUser);
  order.set('status', 'refunded');
  await order.save(null, asUser); // ACLs decide if this agent-driven call is allowed
  return { refunded: order.id };
});
```

**Flutter:**

```dart
// Flutter / Dart — Back4app Flutter SDK
// Both directions ultimately hit the same backend functions.
// A webhook arrives when an EVENT fires (push, deterministic);
// a tool call fires when the MODEL decides (pull, probabilistic).
final result = await ParseCloudFunction('runAgent')
    .execute(parameters: {'goal': 'refund my last order'});
print(result.result);
// The agent PULLED the refundOrder tool. A payment provider would have
// PUSHED a webhook to paymentWebhook. Same endpoint style — opposite trigger.
```

**Swift:**

```swift
// iOS / Swift — Back4app Swift SDK
// Both directions ultimately hit the same backend functions.
// A webhook arrives when an EVENT fires (push, deterministic);
// a tool call fires when the MODEL decides (pull, probabilistic).
let result: [String: Any] = try await Cloud.run(
    name: "runAgent", parameters: ["goal": "refund my last order"])
print(result)
// The agent PULLED the refundOrder tool. A payment provider would have
// PUSHED a webhook to paymentWebhook. Same endpoint style — opposite trigger.
```

**Kotlin:**

```kotlin
// Android / Kotlin — Back4app Android SDK
// Both directions ultimately hit the same backend functions.
// A webhook arrives when an EVENT fires (push, deterministic);
// a tool call fires when the MODEL decides (pull, probabilistic).
val result = ParseCloud.callFunction<Map<String, Any>>(
    "runAgent", mapOf("goal" to "refund my last order"))
println(result)
// The agent PULLED the refundOrder tool. A payment provider would have
// PUSHED a webhook to paymentWebhook. Same endpoint style — opposite trigger.
```

## Was Tool Calling tatsächlich ist

Da der [Webhook-Eintrag](/glossary/de/webhooks/) die Webhook-Seite abdeckt, trägt dieser Artikel die andere Hälfte. **Tool Calling** ist die Art, wie ein [KI-Agent](/glossary/de/ki-agent/) handelt: Sie liefern in der Anfrage Tool-Definitionen mit – einen Namen, eine Beschreibung, ein typisiertes JSON-Schema; das Modell schlussfolgert über den Gesprächsverlauf und gibt statt einer Prosa-Antwort einen *strukturierten Aufruf* aus, der ein Tool und dessen Argumente benennt; Ihr Code führt ihn aus und gibt das Ergebnis für den nächsten Denkschritt zurück. Der Punkt, den alle betonen ([Fowlers Durchgang](https://martinfowler.com/articles/function-call-LLM.html) ist die klare Referenz): **Das Modell führt die Funktion nie aus** – es entscheidet nur, sie anzufordern, gesteuert von den Tool-Beschreibungen, weshalb diese Beschreibungen echte Sorgfalt verdienen. "Function Calling" (der ältere Begriff) und "Tool Calling" (der weiter gefasste) meinen praktisch denselben Mechanismus.

## Determinismus: die Achse, die Ihre Bauweise verändert

Der Unterschied, der Ihr Testen umorganisiert – und den keine Vergleichsseite klar ausspricht. Ein Webhook ist **deterministisch**: Ereignis X löst denselben Callback mit einem vorhersehbaren Payload aus, Sie testen den Handler also im *Unit-Test* gegen eine feste Eingabe und prüfen eine Ausgabe. Ein Tool Call ist **probabilistisch**: Dasselbe Nutzerziel löst ein bestimmtes Tool vielleicht aus und vielleicht nicht und übergibt bei jedem Lauf womöglich andere Argumente – Sie *bewerten* einen Agenten deshalb statistisch, über viele Durchläufe, indem Sie messen, wie oft er das Richtige tut, denn es gibt keine einzelne korrekte Ausgabe zum Prüfen. Deshalb ist eine Webhook-Integration "fertig", wenn die Tests grün sind, und eine Agenten-Integration "fertig", wenn die Erfolgsquote eine von Ihnen gewählte Schwelle überschreitet. Push gegen Pull ist der einprägsame Unterschied; **deterministisch gegen probabilistisch ist der folgenreiche.**

## Sicherheit: Webhooks vs. Tool Calls – Eingehendes prüfen, Ausgehendes einschränken

Die Richtungen diktieren entgegengesetzte Abwehrmaßnahmen, und sie zu vertauschen ist das eigentliche Risiko.

| | Webhook (eingehend) | Tool Call (ausgehend) |
| --- | --- | --- |
| Die Bedrohung | Ein gefälschtes Ereignis von jemandem, der den Absender vortäuscht | Ein [manipuliertes Modell](/glossary/de/ki-agent/), das eine Aktion ausführt, die es nicht sollte |
| Sie vertrauen nicht | Dem Absender | Dem Urteil des Modells |
| Die Abwehr | **Prüfen** – HMAC-Signatur, Replay-Schutz, Secret-Rotation | **Einschränken** – Scopes mit geringsten Rechten, unumkehrbare Aktionen absichern |
| Durchgesetzt durch | Signaturprüfung ([webhooks.fyi](https://webhooks.fyi/)) | [Serverseitige Berechtigungen](/glossary/de/zugriffskontrolllisten-acl/), Ausführung als Benutzer |

Prüfen Sie, was *hereinkommt*; schränken Sie ein, was *hinausgeht*. Ein Webhook-Handler ohne Signaturprüfung ist ein unauthentifizierter Schreib-Endpoint; ein Agenten-Tool mit zu weit gefassten Zugangsdaten ist ein Confused-Deputy-Vorfall, der auf eine Prompt Injection wartet. Beide scheitern auf dieselbe Weise – ein Aufruf, dem Ihr System vertraut hat, obwohl es das nicht hätte tun sollen – nur aus entgegengesetzten Richtungen.

## Sie ergänzen sich

Das sind keine Rivalen, sondern Stufen einer Schleife. Ein **eingehender Webhook weckt einen Agenten** (ein Support-Ticket trifft ein, eine Zahlung geht durch), der **Agent handelt über Tool Calls**, und einer dieser **Tool Calls löst einen ausgehenden Webhook** zu einem weiteren System aus. Das saubere Denkmodell für Backend-Entwickler: Beide erreichen am Ende Ihre API und Ihre Funktionen – die einzigen Unterschiede sind, *wer den Auslöser gedrückt hat* (ein externes Ereignis oder das Modell) und *ob der Aufruf deterministisch war*. Entwerfen Sie den Endpoint einmal; sichern Sie ihn dann so ab, wie es die Richtung verlangt, aus der er erreichbar ist.

## Typische Anwendungsfälle

- **Reaktion auf Ereignisse** – Zahlung eingegangen, Code gepusht, Formular abgeschickt: ein [Webhook](/glossary/de/webhooks/), geprüft.
- **Autonomes Handeln** – ein [Agent](/glossary/de/ki-agent/), der ein Ziel über eng gefasste Tools erreicht: Tool Calling, eingeschränkt.
- **Vom Ereignis geweckte Agenten** – ein Webhook als Eingang, der eine Agent Loop startet: beides, kombiniert.
- **Wiederverwendbare Tool-Oberflächen** – viele Agenten teilen sich einen Satz Tools: standardisiert mit [MCP](/glossary/de/mcp/).
- **Deterministische geplante Arbeit** – ein von Ihnen gesteuerter Abruf nach Zeitplan: ein schlichter [API-Aufruf](/glossary/de/api/), weder Webhook noch Tool.

## Welches brauchen Sie? Entscheidungsmatrix

| Situation | Greifen Sie zu |
| --- | --- |
| Ein Ereignis ist anderswo eingetreten, Sie müssen reagieren | Webhook |
| Ihre KI muss zur Laufzeit entscheiden und handeln | Tool Call eines Agenten |
| Eine modellgesteuerte Aktion auf Ihrem eigenen Backend | Tool Call → eine [eng gefasste Funktion](/glossary/de/cloud-code-serverless-funktionen/) |
| Viele Tools, über Modelle/Agenten hinweg wiederverwendet | [MCP](/glossary/de/mcp/) über Tool Calling |
| Ein geplanter, deterministischer Abruf | Ein schlichter [API-Aufruf](/glossary/de/api/) oder Polling |
| Ein Ereignis soll einen Agenten starten | Ein Webhook, der den Agenten weckt – beides |

## Grenzen und Trade-offs

- **Der Vergleich verdeckt einen gemeinsamen Endpoint.** Beide erreichen dieselbe Backend-Funktion; das zu vergessen führt zu zwei Sicherheitsmodellen, wo Sie eine bewachte Tür mit zwei Schlössern gebraucht hätten.
- **Probabilistische Aufrufe entziehen sich Garantien.** Sie können nicht zusichern, dass ein Agent ein Tool aufruft, so wie Sie zusichern können, dass ein Ereignis einen Webhook auslöst – planen Sie damit, dass das Modell *nicht* handelt und dass es falsch handelt.
- **Prüfen und Einschränken sind nicht austauschbar.** Die Signatur eines Tool Calls zu prüfen oder einen Webhook mit Berechtigungen zu begrenzen löst die falsche Bedrohung für die jeweilige Richtung – passen Sie die Abwehr der Richtung an.
- **Kombination erzeugt zusätzliche Fehlerfälle.** Ein Webhook, der einen Agenten weckt, der Tools aufruft, die Webhooks auslösen, ist mächtig und hat vier Bruchstellen; Korrelations-IDs und Idempotenz über die ganze Kette sind nicht optional.
- **"Es hat meine API getroffen" sagt nichts über Vertrauen aus.** Derselbe Aufruf ist von einem geprüften Ereignis harmlos und von einem manipulierten Modell gefährlich – verteidigt wird die Herkunft, nicht die Form der Anfrage.

## Beide Richtungen mit Back4app

Back4app ist eine Open-Source-Plattform für Backend as a Service (BaaS), die eine verwaltete Datenbank, automatisch generierte REST- und GraphQL-APIs, Authentifizierung, Dateispeicher und Serverless-Funktionen mit Cloud Code kombiniert. Beide Richtungen landen auf demselben Baustein – einer [Cloud-Code-Funktion](/glossary/de/cloud-code-serverless-funktionen/) –, und genau deshalb fallen die beiden Abwehrmaßnahmen auf dieser Plattform natürlich aus, wie die Code-Tabs zeigen. Auf der **eingehenden** Seite ist eine Funktion ein [Webhook](/glossary/de/webhooks/)-Empfänger: HMAC gegen ein serverseitiges Geheimnis prüfen, dann handeln. Auf der **ausgehenden** Seite ist dieselbe Funktion ein [Agenten-Tool](/glossary/de/ki-agent/): Sie läuft unter der Session des aufrufenden Benutzers, sodass [ACLs und Klassenberechtigungen](/glossary/de/zugriffskontrolllisten-acl/) einschränken, was ein modellgesteuerter Aufruf anfassen darf, und ein gekaperter Agent nicht über die Rechte des Benutzers hinauskommt. Prüfen, was hereingepusht wird, einschränken, was der Agent herausholt – ein Backend, ein Ort für beide Kontrollen, mit [MCP](/glossary/de/mcp/) zur Standardisierung der Tool-Oberfläche, sobald sich die Agenten vermehren.