Skip to main content
Glama

Endpunkt oder Werkzeug ausführen

run_endpoint
Destructive

Führt einen Skael-Endpunkt aus (z. B. E-Mail finden oder prüfen, Impressum auslesen, Website scrapen, Google Maps, Firmendaten) oder ein Werkzeug, das search_tools gefunden hat; alles läuft über dasselbe Guthaben. Endpunkt: endpoint (Slug oder Typ, z. B. google_search) und input (Eingaben laut describe_endpoint). Mit dry_run: true werden nur Eingaben und Kosten geprüft, nichts wird ausgegeben. Ohne dry_run läuft die Anfrage und kostet Credits; nach höchstens 25 s kommt das Ergebnis oder status "pending" mit einer enrichment_id für get_enrichment. Über 500 Credits antwortet der Server mit CONFIRMATION_REQUIRED: frag die Person ausdrücklich und ruf erst dann mit confirmation_token und denselben Angaben erneut auf. Batch: statt input eine Liste inputs mit bis zu 100 Eingaben für denselben Endpunkt, z. B. 50 Websites für web_scraper oder icp_checker. Ein Preis vorab für alle (dry_run nennt Summe und Obergrenze), eine Bestätigung über 500 Credits für den ganzen Batch, ungültige Zeilen werden einzeln abgelehnt, der Rest läuft. Die Ergebnisse holst du gesammelt mit get_enrichment und enrichment_ids. icp_checker hat zwei Stufen: with_reason: false liefert nur die Entscheidung (icp, confidence; reason und evidence bleiben null), with_reason: true dazu Begründung und wörtliches Zitat der Website für 1 Credit mehr. Ohne with_reason gilt die Einstellung der Organisation; dry_run nennt den Preis. Werkzeug: tool (Name aus search_tools) und arguments. Werkzeuge aus der Liste bitte direkt aufrufen. Für viele gleichartige Anfragen inputs statt Einzelaufrufen, nicht für Lead-Listen in Schleifen: Lead-Listen baust du mit start_lead_project.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "run_endpoint"
  }
}

Input Schema

NameRequiredDescriptionDefault
toolNoName eines Werkzeugs aus search_tools. Nicht zusammen mit endpoint.
inputNoEingaben für den Endpunkt, wie describe_endpoint sie beschreibt.
inputsNoBatch: bis zu 100 Eingaben für denselben Endpunkt, je ein Objekt wie input. Nicht zusammen mit input.
dry_runNotrue: nur prüfen und Kosten schätzen, nichts ausführen, nichts ausgeben.
endpointNoSlug oder Typ des Endpunkts, z. B. google_search. Nicht zusammen mit tool.
argumentsNoArgumente für das Werkzeug unter tool.
organizationNoSlug der Organisation. Nur nötig, wenn das Werkzeug ORG_AMBIGUOUS meldet.
client_request_idNoEigene ID für diesen Aufruf. Dieselbe ID mit denselben Angaben liefert innerhalb von 24 Stunden das erste Ergebnis, ohne erneut Credits zu kosten.
confirmation_tokenNoToken aus CONFIRMATION_REQUIRED, erst nach ausdrücklichem Ja der Person.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.8/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Beyond the annotations, it discloses the credit cost model, the 25 s timeout and "pending" outcome with enrichment_id, the confirmation-token flow above 500 credits, batch semantics (up to 100 inputs, per-row rejection of invalid entries, single aggregate price), and the client_request_id 24-hour replay behavior. These are exactly the operational traits an agent cannot infer from readOnlyHint/destructiveHint/openWorldHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Well front-loaded: core action and parameters first, then cost/confirmation, then batch, then the icp_checker special case, then the loop-avoidance note. It is long, and the icp_checker paragraph is fairly deep for a single endpoint variant, but nearly every sentence carries decision-relevant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter, nested-object, open-world tool with no output schema, the description still covers what comes back (result, or status "pending" plus enrichment_id), how to retrieve batched results, cost and confirmation gates, and partial-failure behavior. An agent has enough to call it correctly on the first attempt.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is already 100%, so this starts at baseline 3, but the description adds real meaning: endpoint accepts a slug or type with a worked example (google_search), input vs. inputs are mutually exclusive bulk alternatives, dry_run returns cost estimates rather than results, and confirmation_token is only used after explicit human consent. Minor gap: the "organization" parameter's ORG_AMBIGUOUS trigger isn't reinforced in the text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource ("Führt einen Skael-Endpunkt aus ... oder ein Werkzeug") and enumerates concrete use cases (E-Mail finden, Impressum, Website scrapen, Google Maps, Firmendaten). It explicitly separates the two operating modes (endpoint vs. tool from search_tools), so an agent can distinguish it from siblings like search_tools or start_lead_project without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit routing rules: tools surfaced by search_tools should be invoked directly here; use "inputs" for many similar requests instead of per-item loops; lead lists belong to start_lead_project; dry_run for cost-only checks. It also names the escalation path (CONFIRMATION_REQUIRED over 500 credits) and the follow-up call (get_enrichment with enrichment_ids).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources