Skael API

Stand eines Laufs abfragen

get_run_status

Read-onlyIdempotent

Zeigt den Stand eines Test- oder vollen Laufs: wie viele Firmen drin sind, was jede Prüfung aussortiert hat und warum, was bisher ausgegeben wurde. Bei Tests zusätzlich Beispiele und die Hochrechnung je 1.000 fertige Kontakte; nach einem fertigen Test zeig der Person die Beispiele und gib ihr Urteil mit review_sample weiter. Wartet höchstens wait_seconds (bis 45 s) auf Neues; eta_seconds ist die geschätzte Restzeit. Läuft der Lauf noch, ruf es gleich selbst wieder auf, statt die Person nach dem Stand fragen zu lassen. Kostet nichts.

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": {
      "run_id": "<run_id>"
    },
    "name": "get_run_status"
  }
}

Input Schema

Name	Required	Description
`run_id`	Yes	ID des Laufs aus confirm_pipeline_test oder confirm_pipeline_run.
`organization`	No	Slug der Organisation. Nur nötig, wenn das Werkzeug ORG_AMBIGUOUS meldet.
`wait_seconds`	No	So lange höchstens auf einen neuen Stand warten, Standard 0.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 3, 2026

TDQS

A4.1/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 closed-world, so safety is covered. The description adds what the annotations cannot: blocking behavior up to 45 s, that eta_seconds is an estimate, self-polling rather than user-prompting, and that the call is free — substantial behavioral context. It says nothing about error behavior for an unknown run_id, which keeps it from a 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 primary purpose, then test-specific extras, waiting semantics, polling guidance and cost — each sentence carries distinct information. Slight density and a typo ('zeig' for 'zeige') keep it from a 5.

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 supplies the return shape itself (counts, per-check rejections and reasons, emitted output, test-only samples and per-1,000 projection, eta_seconds) plus latency and cost. That is sufficient for an agent to call and interpret it; only the get_results relationship stays unaddressed.

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 description coverage is 100%, so the schema already documents run_id, organization and wait_seconds. The description reinforces wait_seconds' bounded nature ('höchstens wait_seconds (bis 45 s)'), but adds no format or edge-case detail beyond that. Baseline 3 applies when the schema carries the parameter burden.

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 (anzeigen) and resource (Stand eines Test- oder vollen Laufs) and enumerates what the output contains: company count, what each check discarded and why, and what has been emitted so far. The test-vs-full-run distinction makes the scope unambiguous without opening a 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?

Gives clear situational guidance: during a running job, call it again yourself rather than asking the user; after a finished test, forward samples via review_sample. It does not explain when to prefer the sibling get_results instead, which leaves one routing decision to inference.

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?