Skael API

Zielgruppe schärfen

update_icp

Idempotent

Gibt die Antworten der Person auf die Rückfragen weiter (answers: Schlüssel aus next_questions, Wert in ihren eigenen Worten, z. B. {"geography": "nur Bayern", "volume_budget": "100 Stück, bis 25 Euro"}). „weiß nicht“, „egal“, „passt“ oder „ja“ übernimmt den Vorschlag vollständig. Ausschlüsse ändern: {"exclusions": {"remove": ["online"], "add": ["Baumärkte"]}}; eine Liste als exclusions ersetzt alle Ausschlüsse. Suchtiefe bei Google Maps: {"search_depth": "vollständig, alle Städte ab 5.000 Einwohnern"} oder {"search_depth": {"mode": "full", "min_population": 5000, "max_population": 19999, "max_cities": null}}; in Worten auch „nur Orte von 5.000 bis 19.999 Einwohnern“, beide Grenzen zählen mit. Standard ist „bis Ziel“. Schwerpunkt: {"focus": "primary"}, wenn die gesuchte Leistung der erkennbare Schwerpunkt der Firma sein muss und als eines von mehreren Standbeinen nicht reicht; Standard ist {"focus": "any"}. Nennt der Pflichtnachweis das, fragt update_icp danach und schlägt primary vor. Antwortet mit dem neuen Stand und den nächsten höchstens drei Fragen. Kostet nichts. Eigene Zusatzspalten, die per KI von Website oder Impressum gefüllt werden, gehen jederzeit über den Schlüssel extra_columns: Freitext je Spalte „Name: Anweisung“, mit Semikolon getrennt, z. B. {"extra_columns": "Marken: welche Mähroboter-Marken die Firma führt; Verband: in welchem Verband oder welcher Einkaufsgenossenschaft sie ist (Impressum)"}, oder als Liste [{name, instruction, source: website|imprint|both}]. Danach draft_pipeline erneut aufrufen. English: passes the user's answers (keys from next_questions, values in their own words) and returns the updated project and the next questions. Zeig dem Nutzer nie JSON. Stell die Fragen aus next_questions in deinen eigenen Worten, höchstens drei auf einmal, und nenn den Vorschlag dazu. Folge immer next_step.

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>",
      "answers": "<answers>"
    },
    "name": "update_icp"
  }
}

Input Schema

Name	Required	Description
`answers`	Yes	Antworten je Frage-Schlüssel, in den Worten der Person.
`project_id`	Yes	ID des Leadprojekts aus start_lead_project.
`organization`	No	Slug der Organisation. Nur nötig, wenn das Werkzeug ORG_AMBIGUOUS meldet.
`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.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

addedInput schema / properties / answers / properties

Added value: +{
+  "focus": {
+    "description": "primary: die gesuchte Leistung muss der erkennbare Schwerpunkt der Firma sein, als eines von mehreren Standbeinen reicht sie nicht. any (Standard): auch als Standbein. Geht jederzeit.",
+    "enum": [
+      "any",
+      "primary"
+    ],
+    "type": "string"
+  }
+}

First observedNov 3, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare idempotency and non-destructiveness, and the description adds genuinely new behavioral facts: the call is free ('Kostet nichts') and it returns the new state plus at most three next questions. It also instructs the agent not to show raw JSON to the user and to follow next_step, which goes beyond the structured fields. It doesn't clarify whether answers are merged or replaced except for the exclusions case.

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 essential instruction is front-loaded, but the text is long and mixes a dense German block with an English restatement and several worked examples of unequal weight. The examples earn their place for an open-ended answers map, yet some duplication (the English summary repeating the German) could be trimmed.

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 states what comes back (new state, up to three next questions). It covers the nested answers payload thoroughly and explains the free/idempotent client_request_id behavior indirectly. Missing only a clear statement of how partial answers merge with existing ICP settings.

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

Parameters5/5

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

Although schema coverage is nominally 100%, the crucial 'answers' object is an open map whose only documented key is focus; the description supplies the semantics that the schema cannot, defining patterns for geography/volume_budget, the exclusions remove/add/replace forms, search_depth in both prose and structured form, focus, and the extra_columns string/list variants. This is exactly the meaning an agent cannot obtain from the schema alone.

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

Purpose4/5

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

The description opens with a concrete verb+resource: it forwards the person's answers to the follow-up questions and returns the updated project state plus the next questions. The English sentence reinforces this. It doesn't explicitly contrast with siblings like draft_pipeline or plan_pipeline_run, though it does route the agent onward after extra_columns.

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

Usage Guidelines3/5

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

Usage is mainly implied: the agent is expected to call this after start_lead_project / the follow-up questions and to call draft_pipeline again after adding extra_columns. There is one explicit trigger ('Nennt der Pflichtnachweis das, fragt update_icp danach') and a pointer to follow next_step, but no explicit when-not guidance or comparison against the other pipeline tools.

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?