Skael API

Vollen Lauf planen

plan_pipeline_run

Read-onlyIdempotent

Plant den vollen Lauf eines getesteten Ablaufs: target_rows fertige Kontakte unter der harten Obergrenze budget_cap. Gibt nichts aus. Braucht einen bestandenen Test genau dieser Fassung (sonst TEST_REQUIRED). Reicht das Budget nach der Hochrechnung nicht, kommt BUDGET_CAP_TOO_LOW mit rows_that_fit. Ohne budget_cap und ohne Budget aus dem Gespräch schlägt der Plan eins vor (Zielmenge mal Kosten je Kontakt aus dem Test, aufgerundet; budget_proposed = true) und gibt es in next_step als budget_cap mit. Nenne der Person Preis und erwartete Menge und starte erst nach ihrem ausdrücklichen Ja mit confirm_pipeline_run.

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>"
    },
    "name": "plan_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.

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?

Annotations already declare readOnly/idempotent/non-destructive, and the description stays consistent while adding real behavior: specific error codes (TEST_REQUIRED, BUDGET_CAP_TOO_LOW with rows_that_fit) and the budget auto-proposal that sets budget_proposed=true and surfaces a next_step. It stops short of describing the rest of the returned plan payload, so not a full 5.

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?

Front-loaded with the purpose in the first clause, then prerequisites, then failure modes, then the human-in-the-loop instruction — a logical order with little waste. The middle sentences are dense with error-code detail, but each carries operational information an agent needs.

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?

For a five-parameter planning tool with no output schema, the description covers the precondition, the budget fallback, the two failure codes and the required confirmation flow. What is missing is any indication of what else the plan returns (cost breakdown, next_step shape), which matters given there is no output schema.

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 coverage is 100%, so budget_cap, target_rows, organization and search_depth are already documented, and the description largely restates the budget_cap fallback rather than adding to it. It does clarify the coupling between the proposed budget_cap and the later confirm_pipeline_run call, but adds nothing about search_depth or organization beyond the schema.

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?

States a specific verb and resource ("Plant den vollen Lauf eines getesteten Ablaufs") plus the two governing quantities, target_rows and budget_cap, and "Gibt nichts aus" pins the scope to a dry plan. That separates it cleanly from plan_pipeline_test and confirm_pipeline_run without opening any 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?

Gives an explicit precondition (a passed test of exactly this version, otherwise TEST_REQUIRED) and an explicit hand-off: quote price and expected volume to the person, then call confirm_pipeline_run only after their explicit yes. The when-not path (no test → error) and the alternative tool are both named.

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?