Skip to main content
Glama

Ablauf für eine Lead-Liste entwerfen

draft_pipeline

Entwirft aus der Zielgruppe eines Lead-Projekts den Ablauf, sobald update_icp nichts mehr offen hat: nur project_id angeben. Für eine eigene Liste zum Prüfen gib sie als edits.csv mit (rows oder csv_url und mapping). Wer den Ablauf von Hand festlegen will, gibt edits.steps an (je Schritt kind, type, label_de, params, reads, on_fail, on_unknown, when). StepStone sucht ein Wort je Schritt; mehrere Suchwörter als Liste in params.query werden zu je einem Schritt. Schrittarten, lesbare Felder und was jede Anreicherung schreibt, nennt pipeline_schema (über run_endpoint). Die Reihenfolge ordnet draft_pipeline selbst: Quellen an den Anfang, die Sperrliste hinter den letzten Schritt, der eine Domain liefert (fehlt sie, kommt sie dazu), ein Doppelte-Abgleich nach der Domainsuche, KI-Spalten ans Ende; jede Änderung steht in order_changes, die Regeln in pipeline_schema unter order_rules_de. gate_ai sortiert aus: json_schema mit additionalProperties: false, jedes Feld unter required, Pflichtfeld reason (string), pass_when auf ein Pflichtfeld. Eigene Zusatzspalten (z. B. Marken, Verband, Anrede) nicht als gate_ai bauen, sondern über update_icp mit extra_columns; draft_pipeline hängt sie dann als Schritte ai_column ans Ende (params column, label_de, instruction_de; reads z. B. page_text oder imprint.raw_text). Sie sortieren niemanden aus und stehen in get_results und in der CSV/Excel-Datei. Sollen sie auch für markierte Firmen ohne lieferbare Adresse gefüllt werden, deren Website gelesen wurde: edits.run_ai_columns_on_flagged: true (kostet für diese Firmen normal Credits). Jede Änderung ist eine neue Fassung; ein bestandener Test gilt danach nicht mehr. Die Antwort nennt die Schritte in Klartext und eine grobe Kostenschätzung. Kostet nichts. Bei Google Maps steht in search_scope, wie tief gesucht wird: wie viele Städte ab welcher Einwohnerzahl, wie viele Suchen Stadt × Suchbegriff (plus Postleitzahlen) und wann der Lauf aufhört. Die Suchtiefe steht in params der Quelle: search_depth „until_target“ (Standard, hört am Ziel auf) oder „full“ (alle Städte ab min_population, wie Clay mit find_cities × Suchbegriff), dazu min_population und max_population (Band, beide Grenzen einschließlich) und max_cities; im Gespräch über update_icp mit der Antwort search_depth. Das Suchgebiet einer Maps-Quelle steht als Liste in params.postcodes (Postleitzahl oder „PLZ Ort“, die PLZ macht gleichnamige Orte eindeutig), in params.cities (Ortsnamen oder ebenfalls „PLZ Ort“) oder als Umkreis mit params.center plus params.radius_km (Mittelpunkt als PLZ oder Ort, 1 bis 300 km); bis 10.000 Orte je Quelle, und bei einer Liste oder einem Radius sucht die Quelle ohne min_population jeden Ort der Liste, nicht nur die großen. Ein Ort ohne eigenen Stadteintrag wird über seine Postleitzahl gesucht, auch ein eindeutiger Ortsname ohne Postleitzahl. Einträge, die sie nicht kennt, nennt search_scope als unresolved_places und unresolved_examples, mit Grund und bei mehrdeutigen Namen mit Kandidaten in unresolved_details. params.regions nimmt Bundesländer und bei Google Maps auch Landkreise („Landkreis Schwäbisch Hall“); einen mehrdeutigen Namen wie „München“ schreibt man voll aus („Kreisfreie Stadt München“ oder „Landkreis München“). Clay-Workbook nachbauen: find_cities = min_population/max_population/max_cities, Spalte Suchbegriff × Stadt = keywords, maps_search = die Quelle selbst, Dedupe nach Domain = Dedup-Schritte, icp_checker, imprint = verify_domain_owner/find_domain, GF-Mail + verify = find_email_person + verify_email. Danach: plan_pipeline_test.

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": {
      "project_id": "<project_id>"
    },
    "name": "draft_pipeline"
  }
}

Input Schema

NameRequiredDescriptionDefault
editsNoOptional: der Ablauf von Hand oder die Liste zum Prüfen.
project_idYesID des Lead-Projekts.
organizationNoSlug der Organisation. Nur nötig, wenn das Werkzeug ORG_AMBIGUOUS meldet.
client_request_idNoEigene ID für diesen Aufruf. Dieselbe ID mit denselben Argumenten liefert innerhalb von 24 Stunden das erste Ergebnis, ohne erneut Credits zu kosten.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Beyond annotations, it discloses that each change creates a new version, that a previously passed test is invalidated, that the response returns steps in plain text with a rough cost estimate, and that the call costs nothing. These are material behavioral traits an agent needs before invoking a mutation tool.

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

Conciseness3/5

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

The description is front-loaded with purpose but then becomes a dense wall of text covering many edge cases. While most sentences carry necessary information, the lack of headings or bullet points makes it hard to scan and longer than ideal for quick comprehension.

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?

Given the tool's complexity (nested objects, multiple modes, no output schema), the description is largely complete: it covers the main usage paths, ordering rules, gating behavior, AI columns, and the next step. Minor gaps remain in how the rough cost estimate is computed, but the essentials for correct invocation are present.

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 100%, so the baseline is 3, but the description adds substantial meaning: it explains the edits.csv shape, the per-step fields (kind, type, label_de, params, reads, on_fail, on_unknown, when), search_depth options, postcodes/cities/radius semantics, and region handling. The added detail is valuable though somewhat unstructured.

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 first sentence states a specific verb (entwirft) and resource (Ablauf) for a lead project's target group, and explicitly positions it relative to update_icp ('sobald update_icp nichts mehr offen hat'). The closing 'Danach: plan_pipeline_test' further distinguishes it from the next tool in the workflow.

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 when-to-use guidance: after update_icp has nothing left open, and only project_id is needed. It also names alternatives for different modes (own list via edits.csv, manual steps via edits.steps) and tells the agent what to do next (plan_pipeline_test).

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