Skael API

Firmen-Domain finden

find_company_domain

Findet zu einem Firmennamen die eigene Website (Website finden, Domain finden) und belegt sie mit dem Impressum: Suche, KI-Rangfolge der Kandidaten, dann pro Seite ein Impressums-Abgleich mit USt-IdNr., Handelsregister, Adresse und Telefon. Je mehr du über die Firma weißt (Ort, PLZ, USt-IdNr., Registernummer, Branche im context), desto sicherer das Ergebnis. Kosten: 5 Credits Grundpreis plus 10 Credits je geprüfter Seite (15 über Proxy), höchstens max_pages Seiten (Standard 3); ohne prüfbaren Kandidaten 3 Credits. Seiten ohne Urteil kosten nichts; eine Seite ohne Impressum gilt als geprüft und wird berechnet. status verified heißt: das Impressum auf dieser Domain nennt genau diese Firma, und die Antwort zitiert einen Satz daraus wörtlich. Nur dann ist domain gesetzt; sonst ist domain leer und eine Vermutung steht in best_guess, die nie ein Beweis ist. Nennt das Impressum eine weitere Website der Firma, wird sie als eine weitere Seite innerhalb von max_pages geprüft: bestätigt ist sie domain und die zuerst geprüfte Seite steht in related_domains; unbestätigt steht sie in related_domains; nennt ihr Impressum eine andere Firma, fällt sie weg. Fehlt kurz Kapazität, wartet die Suche und macht danach weiter; das kann bis zu etwa drei Stunden dauern, get_enrichment zeigt dann weiter pending. status partial heißt: nach etwa drei Stunden war noch immer keine Kapazität frei, berechnet sind nur der Grundpreis und die bis dahin geprüften Seiten.

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": {
      "company_name": "<company_name>"
    },
    "name": "find_company_domain"
  }
}

Input Schema

Name	Required	Description
`city`	No	Ort.
`email`	No	E-Mail-Adresse der Firma. Ihre Domain wird zuerst geprüft, außer bei Freemail-Anbietern.
`phone`	No	Telefonnummer der Firma.
`street`	No	Straße und Hausnummer.
`vat_id`	No	USt-IdNr., der stärkste Beleg.
`context`	No	Alles, was die Firma unterscheidet: Branche, Adresse, Registereintrag, USt-IdNr.
`country`	No	Land als ISO-Code, Standard DE.
`website`	No	Website, die du schon hast, z. B. aus Google Maps. Wird zuerst geprüft und zählt nur, wenn ihr Impressum die Firma nennt.
`postcode`	No	Postleitzahl.
`max_pages`	No	Höchstens so viele Seiten prüfen, 1 bis 10, Standard 3, die Prüfung einer im Impressum genannten Hauptseite eingeschlossen. Bei 1 wird sie nie geprüft.
`company_name`	Yes	Name der Firma, am besten mit Rechtsform.
`organization`	No	Slug der Organisation. Nur nötig, wenn das Werkzeug ORG_AMBIGUOUS meldet.
`exclude_domains`	No	Domains, die es sicher nicht sind (höchstens 20).
`register_number`	No	Handelsregisternummer, z. B. HRB 12345.
`client_request_id`	No	Eigene ID für diesen Aufruf. Dieselbe ID mit denselben Angaben liefert innerhalb von 24 Stunden dieselbe Suche, ohne erneut Credits zu kosten.
`managing_director`	No	Name eines Geschäftsführers.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.5/5.0

Behavior5/5

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

The description adds exceptional operational detail beyond the annotations: base and per-page credit costs, proxy pricing, no-candidate and unjudged-page exceptions, and the fact that a page without an imprint is still billable. It also discloses the strict verified/best_guess distinction, related-domain handling, possible three-hour capacity delays, and partial-run billing.

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 purpose is front-loaded, followed logically by input guidance, costs, result semantics, linked-domain behavior, and capacity handling. It is long and several sentences are densely packed with semicolons, with some max_pages repetition from the schema, but most of the length conveys consequential behavior rather than filler.

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 costly, potentially long-running tool with 16 parameters and no output schema, it covers the core outputs and operational risks: domain, best_guess, related_domains, verified, partial, pending, and billing. It stops short of enumerating other possible statuses or the full response and error structure, so an agent may still need to inspect a result to understand every outcome.

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 description coverage is 100%, so the baseline is already solid. The description adds value by explaining how additional identifying context improves confidence and how max_pages interacts with candidate verification, linked websites, and billing, though it does not add substantial parameter guidance beyond that.

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 sentence precisely states the resource and goal: find a company's own website from its name and verify it against imprint evidence such as VAT ID, register entry, address, and phone. The emphasis on an imprint-verified domain, rather than merely a likely search result, clearly defines the tool's distinctive purpose.

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 gives practical invocation guidance: supply more distinguishing information for greater certainty, and expect known website or email domains to be checked first as documented in the schema. It also explains how to interpret pending and partial outcomes, but it does not explicitly state when not to use the tool or name an alternative for unverified domain discovery.

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?