Skip to main content
Glama

Stellen-Radar

by ai.stellen-radar
OverviewDiscussionsAdmin

Treffer abrufen

treffer_abrufen
Read-onlyIdempotent

Die Treffer eines gespeicherten eigenen Profils, beste zuerst, wie die Liste im Stellen-Radar (ohne ausgeblendete Stellen), dazu Zahlen je Kanal und wie viele weitere es gibt. Nutze dies, um die Treffer eines Profils zu zeigen. Für Eckdaten ohne gespeichertes Profil nimm beste_treffer_zeigen, zum Filtern, Vergleichen oder für mehr als 25 Treffer trefferliste_laden, für eine einzelne Stelle stelle_im_detail. Nur lesen.

    Je Treffer zusätzlich punktzahl (wie im Stellen-Radar, Legende in punktzahl_legende) und, zu einem gespeicherten Profil, gemerkt und beworben.

    Ob eine Änderung an Ebene, Zielposition, Branche oder Umkreis mehr oder besser passende Stellen bringt, ist erst nach einer Messung bekannt: aenderung_durchrechnen bei einem gespeicherten Profil, sonst stellen_finden mit den geänderten Eckdaten; die Antwort nennt dann die gemessene Zahl.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
anzahlNoWie viele Treffer, 1 bis 25, z. B. 10. Ohne vollen Zugang sind höchstens 5 offen.
profil_idYesprofil_id eines eigenen Profils aus profile_auflisten.
stellen_anzeigenNoNur Stellen, die seit höchstens 1, 3 oder 6 Monaten online sind (früheres Datum aus Veröffentlichung und erstem Fund). Nur setzen, wenn der Nutzer ausdrücklich nur neuere Stellen sehen will; sonst 'alle' lassen. Ältere als 6 Monate zeigt das Radar ohnehin nicht.alle

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / anzahl / description
      Previous value: -"Wie viele Treffer, höchstens 25."New value: +"Wie viele Treffer, 1 bis 25, z. B. 10. Ohne vollen Zugang sind höchstens 5 offen."
    • changedInput schema / properties / profil_id / description
      Previous value: -"ID des eigenen Profils."New value: +"profil_id eines eigenen Profils aus profile_auflisten."
  2. First observed

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/destructive/openWorld, so the description goes beyond by disclosing that hidden jobs are excluded, that per-match punktzahl, gemerkt and beworben fields are returned, and that channel counts and a 'remaining' number accompany the list. It doesn't detail pagination or the access-limited 5-result cap beyond what the schema says.

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-loads what the tool returns and then the alternatives, with every sentence carrying information. Structure is slightly hurt by stray indentation/whitespace artifacts and a fairly long third paragraph, but there is no redundant filler.

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?

For a read-only retrieval tool with an output schema (so return values needn't be explained) and rich annotations, the description covers purpose, alternatives, exclusions and the follow-up measurement path. Nothing an agent needs to call it correctly is missing.

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 anzahl, profil_id and stellen_anzeigen fully. The description only indirectly references the 25 cap ('mehr als 25 Treffer'); it adds no format or default detail beyond the schema, so baseline 3 applies.

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+resource: retrieving the matches of a saved own profile, best first, mirroring the Stellen-Radar list. It explicitly names the sibling tools it is not (beste_treffer_zeigen, trefferliste_laden, stelle_im_detail) so an agent can route without opening schemas.

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?

Gives explicit when-to-use and when-to-use-alternatives: Eckdaten ohne Profil -> beste_treffer_zeigen, Filtern/Vergleichen/>25 Treffer -> trefferliste_laden, Einzelstelle -> stelle_im_detail. It also routes measurement questions to aenderung_durchrechnen or stellen_finden depending on whether a profile exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Stellen-Radar toolsInspect
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