Skael API

Vollen Lauf starten

confirm_pipeline_run

Destructive

Startet den vollen Lauf, den plan_pipeline_run geplant hat. Nur nach ausdrücklichem Ja der Person, mit confirmation_token und den Angaben aus dessen next_step. War das Budget nur vorgeschlagen (budget_proposed), gehört der vorgeschlagene budget_cap dazu; ohne ihn startet nichts (STATE_PRECONDITION). Die Antwort kommt sofort mit run_id; der Lauf arbeitet im Hintergrund weiter, den Stand fragst du mit get_run_status ab.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "definition_id": "<definition_id>",
      "target_rows": "<target_rows>",
      "confirmation_token": "<confirmation_token>"
    },
    "name": "confirm_pipeline_run"
  }
}

Input Schema

Name	Required	Description
`budget_cap`	No	Harte Obergrenze in Credits für den ganzen Lauf. Ohne Angabe gilt das Budget aus dem Gespräch; gibt es keins, schlägt plan_pipeline_run eins vor (budget_proposed), und confirm_pipeline_run braucht nach dem Ja der Person genau diesen Wert als budget_cap.
`target_rows`	Yes	So viele fertige Kontakte sollen es werden.
`organization`	No	Slug der Organisation. Nur nötig, wenn das Werkzeug ORG_AMBIGUOUS meldet.
`search_depth`	No	Suchtiefe bei Google Maps: until_target hört auf, sobald target_rows fertig sind; full sucht alle Städte des Ablaufs ab (zwischen min_population und max_population, wie Clay mit find_cities × Suchbegriff) und hört erst auf, wenn alles durchsucht oder das Budget aufgebraucht ist. Ohne Angabe gilt, was im Ablauf steht. Der Plan nennt die Kosten beider Varianten.
`definition_id`	Yes	ID des getesteten Ablaufs.
`client_request_id`	No	Eigene ID für diesen Aufruf. Dieselbe ID mit denselben Argumenten liefert innerhalb von 24 Stunden das erste Ergebnis, ohne erneut Credits zu kosten.
`confirmation_token`	Yes	Das confirmation_token aus plan_pipeline_run. Nur einmal gültig, zusammen mit genau denselben Angaben.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 3, 2026

changedInput schema / properties / search_depth / description

Previous value: -"Suchtiefe bei Google Maps: until_target hört auf, sobald target_rows fertig sind; full sucht alle Städte des Ablaufs ab (ab min_population, wie Clay mit find_cities × Suchbegriff) und hört erst auf, wenn alles durchsucht oder das Budget aufgebraucht ist. Ohne Angabe gilt, was im Ablauf steht. Der Plan nennt die Kosten beider Varianten."New value: +"Suchtiefe bei Google Maps: until_target hört auf, sobald target_rows fertig sind; full sucht alle Städte des Ablaufs ab (zwischen min_population und max_population, wie Clay mit find_cities × Suchbegriff) und hört erst auf, wenn alles durchsucht oder das Budget aufgebraucht ist. Ohne Angabe gilt, was im Ablauf steht. Der Plan nennt die Kosten beider Varianten."

First observedNov 3, 2026

TDQS

A4.3/5.0

Behavior4/5

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

The annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so safety is covered; the description adds genuinely non-redundant behavior – the background execution model, the immediate run_id return, the single-use token, and the budget precondition that blocks execution. It stops short of saying what a failed precondition or a partial run does to already-spent credits.

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?

Three short sentences, front-loaded with the action and the hard precondition, and the turn-taking/async information comes last where it belongs. A little of the budget sentence duplicates the schema, but nothing is padded.

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

Completeness4/5

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

With no output schema, the description correctly discloses the return value (run_id) and the polling path via get_run_status, and it covers the confirmation gate and budget precondition of a destructive 7-parameter tool. What is missing is the effect of failure paths (what happens on an invalid or reused token, or when the budget runs out mid-run).

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is already documented in the schema, including the budget_proposed→budget_cap rule which the description largely restates. The description adds the useful constraint that the token must accompany 'genau denselben Angaben', but that is marginal on top of a fully described schema, so the baseline 3 applies.

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 states a specific verb and object ('Startet den vollen Lauf') and explicitly ties it to the sibling that produced it ('den plan_pipeline_run geplant hat'), so the agent can separate it from plan_pipeline_run and from confirm_pipeline_test without inspecting either 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?

It gives explicit preconditions ('Nur nach ausdrücklichem Ja der Person'), names the state exception (budget_proposed requires budget_cap or STATE_PRECONDITION fires), and points to get_run_status for follow-up, which is exactly the when/to-what-alternative guidance an agent needs.

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

All Skael API tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?