Skael API

Markt abschätzen

estimate_market

Idempotent

Tastet den Markt für ein Leadprojekt mit echten Treffern ab: bei Branchen eine Google-Maps-Suche in den größten Städten der Region, bei Stellenanzeigen je eine Suche in der Arbeitsagentur und bei StepStone. Antwortet mit geschätzter Anzahl Firmen, echten Beispielen und Auffälligkeiten (z. B. Makler unter den Treffern), daraus entstehen die nächsten Fragen. Kostet bei Branchen 2 Credits je Stadt (meist drei Städte, vorab reserviert werden 20 je Stadt), bei Stellenanzeigen 2 Credits; dieselbe Probe wird nicht zweimal bezahlt. English: probes the market with real hits (Maps in the biggest cities, or one Arbeitsagentur and one StepStone search) and returns an estimate, examples and ambiguities; Maps costs 2 credits per city (usually three, 20 reserved per city), jobs 2 credits. 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>"
    },
    "name": "estimate_market"
  }
}

Input Schema

Name	Required	Description
`project_id`	Yes	ID des Leadprojekts.
`probe_limit`	No	In wie vielen Städten gesucht wird, Standard 3.
`organization`	No	Slug der Organisation. Nur nötig, wenn das Werkzeug ORG_AMBIGUOUS meldet.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Beyond the annotations it discloses the external sources queried (Google Maps, Arbeitsagentur, StepStone), the exact cost model (2 credits per city, usually three cities, 20 reserved per city, jobs 2 credits), and the no-double-charge rule that corroborates idempotentHint=true. It also prescribes how to present results (never raw JSON, at most three next_questions, follow next_step), which is real behavioral context the annotations cannot carry.

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?

The capability and cost are front-loaded, and every sentence carries information. It is somewhat long because it duplicates the German text in an English gloss and mixes tool description with agent-facing output rules, which adds bulk even though those rules are useful.

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?

With no output schema, the description fully carries the return burden: estimated company count, real examples, ambiguities such as brokers among hits, plus next_questions and next_step. Combined with the credit model and the ORG_AMBIGUOUS path documented in the schema, an agent has everything needed to call it and interpret the result.

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 meaning by tying probe_limit to cities and credits ("2 Credits je Stadt (meist drei Städte)"), which explains why the default is 3 and what raising it costs. The organization parameter is only referenced indirectly via the ORG_AMBIGUOUS mention that already lives in 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?

The opening clause names a specific verb and resource ("Tastet den Markt für ein Leadprojekt ... ab") and immediately disambiguates the two operating modes: Google-Maps search across the biggest cities for industries, versus one Arbeitsagentur plus one StepStone search for job ads. An agent can tell exactly what this does and how it differs from siblings like start_lead_project or review_sample 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 Guidelines4/5

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

It clearly states the conditions that select each probing mode (Branchen vs. Stellenanzeigen) and ties the tool to the downstream flow ("daraus entstehen die nächsten Fragen"). It does not explicitly say when NOT to call it, nor route the agent to alternatives such as review_sample or get_results, so a small gap remains.

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?