Stellen-Radar

Änderung durchrechnen

aenderung_durchrechnen

Read-onlyIdempotent

Rechnet eine Änderung an einem eigenen Profil durch, ohne zu speichern: Treffer vorher und nachher je Kanal, neue und weggefallene Stellen, mit ziel_begriffe oder ziel_branchen auch, wie viele Stellen aus dem gewünschten Bereich oben stehen. Nur übergebene Felder ändern sich, weggelassene bleiben wie im Profil. Nutze dies vor jeder Profiländerung; gespeichert wird erst mit aenderung_uebernehmen und der kennung aus der Antwort (gilt 60 Minuten). Für Eckdaten ohne gespeichertes Profil nimm stellen_finden.

Input Schema

Name	Required	Description
`plz`	No	Fünfstellige deutsche Postleitzahl des Wohnorts, keine Adresse, z. B. '60311'.
`region`	No	Auch Stellen mit Regionsangabe statt Ort.
`remote`	No	Auch Remote-Stellen.
`branchen`	No	Oberbranchen aus der festen Liste; eine Oberbranche umfasst ihre Unterbranchen. Leer heißt offen; eine enge Wahl wertet Stellen anderer Branchen ab.
`profil_id`	Yes	profil_id eines eigenen Profils aus profile_auflisten.
`bundesweit`	No	Auch bundesweite Stellen ohne festen Ort, z. B. false. Weggelassen gilt der Wert aus dem Profil, auch wenn umkreis_km neu gesetzt wird. Wirkt nur mit Umkreis; ohne Umkreis sucht das Profil ohnehin bundesweit. Den Stand vorher und nachher nennt die Antwort in stellen_ohne_festen_ort.
`funktionen`	No	Fachliche Funktionen aus der festen Liste. Die Funktion zählt beim Abgleich stärker als die Branche; ohne sie erreicht kaum eine Stelle 'gut passend'. Bei einer neuen Suche die Funktion setzen, die die Zielposition nennt (z. B. 'Director Operations': Operations). In einem bestehenden Profil verengt der erste Eintrag; die Wirkung zeigt aenderung_durchrechnen.
`hierarchie`	No	Ebenen aus der festen Liste. Filtert hart: Stellen anderer Ebenen erscheinen nicht. Nur Ebenen, die die Person wirklich annehmen würde.
`umkreis_km`	No	Umkreis um den Wohnort in km, 0 heißt bundesweit. Ein Umkreis ist nur ein Angebot.
`kompetenzen`	No	Fachliche Kompetenzen als Stichworte, z. B. ['SAP S/4HANA', 'Lieferantenmanagement'].
`ziel_begriffe`	No	Ziel der Person: Wörter im Titel einer gewünschten Stelle, je mindestens drei Zeichen, z. B. 'defence', 'rüstung'. Aus dem Gespräch ableiten; gemessen wird, wie viele solche Stellen oben in der Liste stehen. Sie treffen am Wortanfang ('rüstung' nicht in 'Ausrüstung'); mit * davor als Wortteil ('*verteidigung' auch in 'Luftverteidigung').
`ziel_branchen`	No	Ziel der Person: Teil der Stellenbranche, z. B. 'verteidigung' (trifft die Unterbranche 'Luft/Raumfahrt - Verteidigung/Rüstung').
`zielpositionen`	No	Gesuchte Positionen in Ausschreibungsform, kurz und gängig, mehrere Varianten, auch englisch und in beiden Geschlechterformen, z. B. 'Werksleiter', 'Plant Manager', ohne Zusatz wie '(m/w/d)'. Der Titel zählt beim Abgleich am stärksten.
`ausschlussbegriffe`	No	Begriffe, deren Stellen nicht angezeigt werden sollen, mit Komma getrennt. Wirken auf den Stellentitel wie in der App: bis drei Zeichen nur am Wortanfang, längere auch als Wortteil.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 31, 2026

changedInput schema / properties / zielpositionen / description

Previous value: -"Gesuchte Positionen in Ausschreibungsform, kurz und gängig, mehrere Varianten, auch englisch und in beiden Geschlechterformen, z. B. 'Werksleiter (m/w/d)', 'Plant Manager'. Der Titel zählt beim Abgleich am stärksten."New value: +"Gesuchte Positionen in Ausschreibungsform, kurz und gängig, mehrere Varianten, auch englisch und in beiden Geschlechterformen, z. B. 'Werksleiter', 'Plant Manager', ohne Zusatz wie '(m/w/d)'. Der Titel zählt beim Abgleich am stärksten."

Changed1 schema field changedOct 26, 2026

changedInput schema / properties / ziel_begriffe / description

Previous value: -"Ziel der Person: Wörter im Titel einer gewünschten Stelle, je mindestens drei Zeichen, z. B. 'defence', 'rüstung'. Aus dem Gespräch ableiten; gemessen wird, wie viele solche Stellen oben in der Liste stehen. Sie treffen auch als Wortteil, deshalb die Beispiele ansehen."New value: +"Ziel der Person: Wörter im Titel einer gewünschten Stelle, je mindestens drei Zeichen, z. B. 'defence', 'rüstung'. Aus dem Gespräch ableiten; gemessen wird, wie viele solche Stellen oben in der Liste stehen. Sie treffen am Wortanfang ('rüstung' nicht in 'Ausrüstung'); mit * davor als Wortteil ('*verteidigung' auch in 'Luftverteidigung')."

Changed2 schema fields changedOct 19, 2026

changedInput schema / properties / plz / anyOf

Previous value: -[
-  {
-    "pattern": "^\\d{4,5}$",
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "pattern": "^\\d{5}$",
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

changedInput schema / properties / plz / description

Previous value: -"Postleitzahl des Wohnorts, keine Adresse, z. B. '60311'."New value: +"Fünfstellige deutsche Postleitzahl des Wohnorts, keine Adresse, z. B. '60311'."

Changed1 schema field changedOct 19, 2026

changedInput schema / properties / bundesweit / description

Previous value: -"Auch bundesweite Stellen ohne festen Ort."New value: +"Auch bundesweite Stellen ohne festen Ort, z. B. false. Weggelassen gilt der Wert aus dem Profil, auch wenn umkreis_km neu gesetzt wird. Wirkt nur mit Umkreis; ohne Umkreis sucht das Profil ohnehin bundesweit. Den Stand vorher und nachher nennt die Antwort in stellen_ohne_festen_ort."

Changed3 schema fields changedOct 19, 2026

changedInput schema / properties / kompetenzen / description

Previous value: -"Fachliche Kompetenzen als Stichworte."New value: +"Fachliche Kompetenzen als Stichworte, z. B. ['SAP S/4HANA', 'Lieferantenmanagement']."

changedInput schema / properties / plz / description

Previous value: -"Postleitzahl des Wohnorts, keine Adresse."New value: +"Postleitzahl des Wohnorts, keine Adresse, z. B. '60311'."

changedInput schema / properties / profil_id / description

Previous value: -"ID des eigenen Profils."New value: +"profil_id eines eigenen Profils aus profile_auflisten."

First observedOct 19, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real behavioral context on top: nothing is persisted, only supplied fields change while omitted ones keep their profile value, and the returned kennung expires after 60 minutes. It also discloses what the result contains per channel and under which inputs the target-area metric is computed.

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 verb and the no-persist guarantee, then the save path, then the fallback sibling. Every sentence carries information, though the run-on clause listing the returned metrics is denser than it needs to be.

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 14-parameter preview tool with an output schema, this covers everything an agent needs: what it does, what does not get saved, the downstream save step with token validity, the sibling for the no-profile case, and a sketch of the returned metrics. No material gap remains.

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 schema carries the field-level meaning and a 3 would be the floor. The description adds the non-obvious semantics the schema cannot: partial-update behavior (omitted fields unchanged) and the fact that ziel_begriffe/ziel_branchen do not filter but measure how many desired positions rank at the top.

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?

Names a specific action (dry-run computation of a change to one's own profile) plus the concrete output: hits before/after per channel, new and dropped positions, and target-area ranking. It explicitly positions itself against the two closest siblings (aenderung_uebernehmen for saving, stellen_finden for stats without a profile), so an agent can distinguish it without opening any schema.

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 an explicit prescription ('Nutze dies vor jeder Profiländerung'), the exact follow-up step and required artifact ('gespeichert wird erst mit aenderung_uebernehmen und der kennung aus der Antwort'), and a when-not case ('Für Eckdaten ohne gespeichertes Profil nimm stellen_finden'). Both the alternative and the condition selecting it are stated outright.

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

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