Stellen-Radar

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

Annotations already cover readOnly, idempotent, non-destructive, closed-world, so the safety profile is settled. The description still adds real behavior beyond them: partial-update semantics ('Nur angegebene Felder ändern sich'), a per-channel before/after diff with new and dropped positions, and the returned identifier required by the follow-up. It does not add auth/rate-limit context, but that is minor here.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, front-loaded with the dry-run purpose and the diff shape; each sentence carries information (scope, partial-update rule, ziel_* side effect, save workflow). Slightly dense but no filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter tool the description supplies the essentials an agent needs: it is a non-persisting preview, which fields mutate, what the preview measures, and how to commit. With a rich output schema and full annotation coverage, remaining detail (per-channel return shape) is legitimately delegated to structured fields.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3; the schema already explains every one of the 14 parameters in detail. The description only restates the special effect of ziel_begriffe/ziel_branchen (ranking counts from the desired area), adding little beyond what those property descriptions already say.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb + resource ('Eine Änderung am Profil durchrechnen, ohne zu speichern') and immediately scopes the scope ('vorher und nachher je Kanal, neue und weggefallene Stellen'). It explicitly names the sibling it is not (aenderung_uebernehmen), so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The description gives the selecting condition for the alternative: this tool previews, and 'Gespeichert wird erst mit aenderung_uebernehmen und der Kennung aus dieser Antwort.' That is an explicit when-to-use-this vs when-to-use-that routing, plus the prerequisite (the Kennung from this response) for the follow-up call.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=true, so the safety profile is largely covered. The description adds the useful human-in-the-loop confirmation requirement, but does not describe what the destructive write actually alters in the profile or whether it overwrites existing values, leaving a gap the annotations alone don't fill.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, no filler, with the action front-loaded and the confirmation gate immediately after. Every phrase earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A single-parameter mutation with full schema coverage, an output schema, and annotations that carry the safety profile; the description's remaining job is just the confirmation gate, which it covers. The only omission is detail about what the write changes in the profile.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already explains that 'kennung' comes from aenderung_durchrechnen. The description reinforces that the change is the computed one but adds no syntax or format detail beyond the schema, which is baseline 3 when structured fields do the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb+resource: 'Speichert ... die durchgerechnete Änderung im Profil' makes clear this persists the computed change, which implicitly separates it from the sibling aenderung_durchrechnen that computes it. Clear on its own, though the differentiation from the compute sibling is implied rather than stated explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

'Nur nach Bestätigung des Nutzers aufrufen' gives a concrete precondition for calling the tool (human confirmation required). It stops short of naming an explicit alternative or 'when not to use' beyond this gate, but the context of use is unambiguous.

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

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

Annotations cover the safety profile (readOnlyHint=false, openWorldHint=true, idempotentHint=false), and the description adds behavior the annotations cannot express: the request is answered asynchronously by email to the account address, and the tool must only be invoked on explicit user request plus confirmation. That confirmation gate is critical, non-derivable context for an irreversible-feeling handoff.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and recipient are front-loaded, and every clause carries routing or precondition information. It is a tightly packed multi-clause sentence with no filler, though the density makes it slightly harder to scan than a cleanly segmented version.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and the description fully covers routing, exclusions, preconditions, and the asynchronous email outcome. Nothing an agent needs in order to invoke this correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 all three parameters, including the structured-summary guidance and the kategorie enum semantics. The description itself adds no parameter-level detail beyond this, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb (übergeben) and resource (Anliegen an den Support des Stellen-Radars) and identifies the recipient (Ralf, KI-Support-Agent). An agent can distinguish this from feedback_geben and the profile-management siblings 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.

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

Gives explicit when-to-use domains (Konto, Abo, Zahlung, Lebenslauf, Unterlagen, defects), names the alternative for out-of-scope cases (feedback_geben), instructs to resolve self-serviceable issues with the other tools first, and states the precondition (only on user request and after their confirmation). All decision inputs are present.

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

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

Annotations already establish readOnly/idempotent/non-destructive, but the description adds real context beyond them: it stores nothing, it requires an authenticated account at Stellen-Radar, and the response augments each match with punktzahl plus gemerkt/beworben for saved profiles. This is genuine behavioral disclosure rather than a restatement of the hints.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but the third paragraph about measuring changes via aenderung_durchrechnen/stellen_finden is tangential routing advice that does not help an agent invoke this tool. Several cross-references (punktzahl_legende, profil_anlegen_mit) add length without adding invocation value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter tool with an output schema, the description covers the essentials an agent needs: account prerequisite, no persistence, and the profile-creation fallback path, so return-value explanation is correctly left to the output schema. Only the sibling boundary with stellen_finden remains slightly under-specified.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so each of the ten parameters is already well documented in the schema (including enum guidance for stellen_anzeigen and branchen/funktionen). The description only summarizes the criteria fields at a high level and adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: returns the best matching jobs for structured personal criteria (title, location, employer, channel, date, link). It also distinguishes itself by pointing to treffer_abrufen for saved profiles, though the boundary against stellen_finden is only implied rather than stated.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives clear context: requires an account connection, stores nothing, and if no profile exists the response carries the arguments for profil_anlegen. It also routes the 'will a change help?' question to aenderung_durchrechnen vs stellen_finden, so the when-to-use guidance is substantive, even if it never explicitly says when to prefer this over stellen_finden for a fresh search.

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

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

Annotations declare it is a non-read-only, non-destructive, non-idempotent, closed-world write. The description adds context annotations cannot express: the team reads every submission and there is deliberately no email reply, and that it should only be triggered on explicit user request. Minor gap: nothing about submission confirmation or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded, followed by the key exclusion and the invocation constraint, with no filler. Slightly long and broken across lines, but every clause carries routing or expectation-setting value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be explained. For a simple two-parameter write tool, the description covers purpose, the alternative path, the expected outcome (no reply), and the trigger condition — nothing an agent needs is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with the 'art' enum values explained in-schema and 'text' carrying length bounds and content guidance. The description only loosely echoes the enum categories (Lob, Kritik, Wünsche, Ideen), so it does not materially add beyond what the schema already provides; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: passing on feedback and improvement suggestions about the Stellen-Radar, enumerating the subtypes (Lob, Kritik, Wünsche, Ideen). It explicitly distinguishes itself from the sibling an_support_uebergeben, so an agent can route correctly without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicit when-to-use (feedback where no reply is needed) and when-not (user needs help or an answer about account/subscription/broken features → use an_support_uebergeben instead), plus the invocation constraint 'only call at the user's request'. This is textbook routing guidance.

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

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

Annotations already declare readOnly/idempotent/non-destructive/openWorld=false, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the numbers are rounded ('über X'), nationwide without location or title, include 7-day new-discovery and prior-day comparisons, and no map is returned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core question, but it is a dense run-on paragraph with parentheticals, and the 'only numbers, no individual postings / only overall market' limitation is effectively repeated in the closing sentence. Information-dense yet not tightly edited.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite an existing output schema, the description helpfully names output fields (kanal_bezeichnung, zaehlung, je_kanal_summen.personaldienstleister) so the agent can interpret the response, and it covers scope, sibling comparison, and limitations. Nothing needed 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single optional funktion enum is fully documented in the schema, so the baseline is 3. The description adds only the general scope ('bundesweit, ohne Ort und ohne Titel') rather than any funktion-specific semantics beyond what the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource: it reports current job-market numbers of active postings broken down per channel (staffing agencies, portals, career pages). It explicitly distinguishes itself from the sibling stellen_finden by noting both count the same channels and that stellen_finden is for individual postings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Names the alternative explicitly ('Für passende Einzelstellen zu einer Person: stellen_finden') and states the boundary conditions — marktlage gives only aggregate nationwide numbers with no location, title, map, or individual postings. The when-to-use vs when-not split is unambiguous.

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

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

Annotations cover the safety profile (readOnly=false, idempotent=false, destructive=false), but the description adds a behavioral trait not in annotations: each consciously created profile consumes the account's profile quota. It also flags the automatisch=true shortcut tied to search results. No contradiction with annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the core purpose before the quota caveat and the automation path. No filler, though the middle sentences are slightly dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be described, and annotations carry the safety profile. The description supplies the quota impact, the pre-check with the user, and the automatisch delegation path, leaving little an agent needs beyond that.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 all 14 parameters in detail (e.g. funktionen weighting, hierarchie hard filter, ausschlussbegriffe matching). The description adds only the automatisch flow, so the baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (anlegen) and resource (Suchprofil im Konto), which an agent can clearly separate from profil_lesen, profil_loeschen, or the aenderung_* tools. It does not name the exact sibling used to edit an existing profile, but the creation intent is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicitly says to first clarify with the user whether an existing profile should be changed instead, and describes the alternative path: when the account has no profile, stellen_finden and beste_treffer_zeigen supply the arguments via profil_anlegen_mit with automatisch=true. Clear when-to-use, when-not, and named alternatives.

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

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

Die Annotationen deklarieren bereits readOnly, idempotent, nicht-destruktiv und nicht-open-world, sodass das Sicherheitsprofil vollständig abgedeckt ist. Die Beschreibung fügt im Wesentlichen nur die Feldliste der zurückgegebenen Kurzinfos hinzu, die ohnehin im Output-Schema steht – Verhalten jenseits der Annotationen wird kaum offengelegt.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Ein einziger, front-loading Satz ohne Füllmaterial; die Kernressource steht am Anfang, die Zusatzfelder folgen als Nebensatz.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Bei 0 Parametern, vorhandenem Output-Schema und reichhaltigen Annotationen ist die Beschreibung weitgehend ausreichend; das Output-Schema muss die Rückgabewerte nicht wiederholen. Es fehlt lediglich die Einordnung im Workflow gegenüber profil_lesen.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Das Tool hat keine Parameter (0 Params, Schemaabdeckung 100%), daher greift die Baseline 4. Es gibt keine Parameter, deren Semantik zusätzlich erklärt werden müsste.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Nennt einen klaren Verbstamm ('auflisten') und die Ressource ('die eigenen Suchprofile'), dazu die pro Profil gelieferten Felder. Der Plural und 'eigenen' grenzen es vom singulären profil_lesen ab, aber kein Geschwistertool wird explizit genannt.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Es fehlt jede Angabe, wann dieses Tool gegenüber profil_lesen (einzelnes Profil) oder trefferliste_laden zu wählen ist, ebenso Voraussetzungen oder Ausschlüsse. Die Einsatzerwartung ist nur implizit erschließbar.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is fully covered. The description's only added behavioral nuance is the content-scope exclusion "ohne Lebenslauf-Text", which is useful but largely overlaps the output schema, since no auth, rate-limit, or failure behavior is mentioned.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence carries the scope and the CV-text exclusion with no filler, and the key qualifier ("eigenes Profils") appears up front. It is a noun fragment rather than a complete actionable statement, which costs it the top mark.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a one-parameter, read-only tool with annotations covering safety and an output schema covering return values, the description supplies enough scope information to call it correctly. It omits nothing critical, though a brief pointer to profil_auflisten for listing multiple profiles would make it fully self-sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and the single parameter's schema text ("ID aus profile_auflisten") already tells the agent where to obtain the value. The description adds no parameter semantics beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

"Alle Suchfelder eines eigenen Profils (ohne Lebenslauf-Text)" clearly identifies the resource (one's own profile) and the returned content, and the verb "lesen" is carried by the name. It implicitly distinguishes itself from profil_auflisten by scoping to a single own profile, but never names that sibling or states the read action explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied: the requirement of a profil_id plus "eigenes Profil" hints at retrieving a specific profile you own, but there is no statement of when to call this versus profil_auflisten, profil_anlegen, or profil_wiederherstellen. No prerequisites, error conditions, or alternatives are given.

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

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

Goes well beyond the destructiveHint=true annotation by disclosing what is destroyed (profile plus job agent), a 30-day retention/backup window, and the restore path. It stops short of stating what happens after 30 days (permanent irreversibility), which is the one behavioral detail an agent would still want.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, front-loaded with the action and scope, then the retention/recovery fact, then the confirmation gate. Every sentence carries distinct information with no repetition of the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive two-parameter tool with an output schema and safety annotations, the description supplies destruction scope, reversibility window, and the confirmation gate. The only omission is the post-30-day consequence and any ownership/auth requirement beyond 'eigenes Profil'.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both profil_id and bestaetigt are already documented. The description's 'ausdrückliche Bestätigung' loosely corresponds to the bestaetigt flag but adds no syntax, default, or interaction detail beyond the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a precise verb and resource ('Ein eigenes Profil samt Stellen-Agent löschen'), including the notable scope detail that the job agent is deleted too. It names the sibling that reverses the action (profil_wiederherstellen), so an agent can place it against profil_anlegen/profil_lesen 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.

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

Gives an explicit precondition ('Nur nach ausdrücklicher Bestätigung') and points to the recovery alternative. It does not state the negative case (e.g., what to do if the user has not confirmed), so it falls just short of full when/when-not coverage.

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

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

Annotations already declare idempotentHint=true, destructiveHint=false and readOnlyHint=false, and the description is consistent with a safe, repeatable write. It adds behavior not in the annotations: the 30-day backup retention limit and the dependency on a prior profil_loeschen call. It does not describe failure modes once the window lapses, which keeps it at 4.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single front-loaded sentence with no filler; every clause (source sibling, backup, 30-day limit) earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need no explanation, and the description covers purpose, prerequisite and retention limit. Minor gap: it does not say what error or outcome occurs when the 30-day window has expired.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and sicherung_id already carries the description 'sicherung_id aus profil_loeschen', so the schema does the heavy lifting. The description reinforces that the identifier comes from the backup/deletion flow but adds no format or constraint beyond it; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb (zurückholen/restore) plus resource (Profil) plus the exact source of the data ('aus der Sicherung') and the sibling that created the deletion state (profil_loeschen). An agent can distinguish this from profil_anlegen, profil_lesen and profil_loeschen 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.

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

Clearly scopes usage: only profiles deleted via profil_loeschen can be restored, and only within a 30-day window. It names the prerequisite sibling but does not state what to do outside that window or any alternative recovery path, so it stays short of a 5.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered. The description adds genuinely new context beyond that: the effect is account-scoped ('wirkt nur für dieses Konto') and requires no justification ('Ohne Begründung'). It omits that the action is reversible via the rueckgaengig flag, which is a minor gap against an otherwise well-covered annotation set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero waste, with the core action front-loaded and the scoping caveat second. Nothing is padded or redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema and full annotation coverage carry much of the burden, so the description need not explain return values. It is still thin for a destructive mutation: it never mentions that the hide can be undone, which an agent should know before acting.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all four parameters (stelle_id, quelle, profil_id, rueckgaengig) are already documented in the schema itself. The description adds no syntax, format, or provenance detail beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Eine Stelle aus der eigenen Liste ausblenden') that an agent can distinguish from siblings like stelle_merken or stelle_melden. However it never explicitly contrasts itself against those siblings, so it lands just below the top band.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is implied ('aus der eigenen Liste ausblenden') but there is no explicit when-to-use versus when-not-to-use, and no pointer to alternatives such as stelle_melden for reporting a job. The reader must infer the situation from the purpose alone.

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

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

With readOnlyHint=false and destructiveHint=false already set, the description adds real context beyond annotations: no outbound messages are sent, the mark feeds recommendation logic like a saved item, and rueckgaengig=true reverses it. This is a meaningful disclosure for a mutation tool, though it omits any permission/rate-limit details.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with the action and then the key behavioral clarifications. Efficient overall, though the 'Koffer im Stellen-Radar' analogy is slightly decorative and the recommendation-effect point is partially redundant with the profile-scoped framing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 4-parameter tool with full schema coverage, an output schema, and annotations covering safety hints, the description supplies what structured fields cannot: the interaction trigger, absence of outbound side effects, and the recommendation impact. Nothing essential for correct invocation is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already explains stelle_id, quelle and profil_id. The description reinforces the profile-scoped effect and the rueckgaengig=true undo, but the schema's own description of that boolean is nearly identical, so it adds little beyond the structured data. Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource ('Eine Stelle als beworben markieren') and clarifies its scope ('Setzt nur die Markierung in ihrem Profil, verschickt nichts'). It implicitly distinguishes itself from save/contact siblings via the 'wie gemerkte' comparison, but no sibling tool is named explicitly, so it falls short of the 5-level differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives a clear trigger condition: use it 'wenn die Person sagt, dass sie sich beworben hat'. It also clarifies it sends nothing, implying it is not a messaging/outreach tool. However, it never explicitly states when to choose an alternative (e.g. stelle_merken or an_support_uebergeben) or any exclusions.

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

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

Annotations already establish the safe read-only, idempotent, closed-world profile, so the description only needs to add beyond that — and it does: it warns that Aufgaben/Anforderungen only exist in the linked original ad, explains the meaning of nicht_enthalten and hinweis_zugang, describes the conditional extra fields unlocked by profil_id, and specifies the expired-job-with-note behavior (aktiv=false plus Titel and Notiz). That is meaningful conditional behavior, though much of it overlaps with what an output schema would convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Content is dense and mostly earns its place, and the field inventory is front-loaded. But the second paragraph is a run-on sentence chain mixing return fields, conditional branches and edge cases, which makes it harder to parse than an agent-friendly structure would be.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so the description need not detail return values, yet it supplies enough context for correct invocation: the identifier pairing (stelle_id + quelle), the optional profile scoping, and the degraded-expired-job case. Only the absence of any error/precondition guidance (e.g. invalid stelle_id or mismatched quelle) keeps it short of full completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

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 real meaning beyond the schema: it enumerates the additional fields returned when profil_id is supplied (stellenart, zuletzt_gesehen, mandant, eigene notiz, notiz_geaendert_am) and clarifies that quelle/stelle_id must come from an existing Treffer. That goes past a bare restatement of the parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource (eine Stelle) and enumerates what the detail view returns (Titel, Ort, Arbeitgeber, Funktion, Ebene, Branche, Link, Stichworte, Kurzfassung), so an agent knows this is the single-job detail fetch. However, no explicit verb is used and it does not name or contrast itself with nearby siblings such as treffer_abrufen or beste_treffer_zeigen, so sibling differentiation is left to inference.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is only implied: the schema hints that stelle_id/quelle come from 'einem Treffer', and the description explains that profil_id is optional and unlocks profile-scoped fields. There is no explicit statement of when to call this versus the list/search siblings, and no exclusions or prerequisites are given.

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

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

Die Annotationen (destructiveHint=true, idempotentHint=false) decken das Sicherheitsprofil bereits ab; die Beschreibung ergänzt wertvollen Kontext, dass die Meldung erst geprüft wird, bevor etwas geändert wird, und dass ein Beleg Pflicht ist. Offen bleibt, ob die Meldung gespeichert wird, was die Antwort enthält und ob Mehrfachmeldungen möglich sind.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Drei kurze Sätze, jeder mit eigenem Zweck: Handlung, Prüfmechanik, Belegpflicht. Die Kernaussage steht vorn und es gibt keinerlei Füllmaterial.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Bei acht Parametern, vollständiger Schemaabdeckung, vorhandenem Output-Schema und aussagekräftigen Annotationen ist die Beschreibung ausreichend, um das Tool korrekt aufzurufen. Die bedingte Logik der optionalen Felder wird nicht in der Beschreibung gespiegelt, ist aber im Schema dokumentiert.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Die Schema-Beschreibungsabdeckung liegt bei 100 %, sodass alle acht Parameter inklusive der bedingten Felder (merkmal/vorschlag nur bei falsch_eingestuft, partner_* nur bei dublette) bereits im Schema erklärt sind. Die Beschreibung trägt keine zusätzliche Parametersemantik bei, was bei vollständiger Schemaabdeckung dem Baseline-Wert entspricht.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Klare Kombination aus Verb und Objekt ('Datenfehler an einer Stelle strukturiert melden'), die den Zweck eindeutig von Lese-Tools wie stelle_im_detail oder treffer_abrufen abgrenzt. Eine explizite Abgrenzung zu Nachbar-Tools wie feedback_geben oder stelle_ausblenden fehlt jedoch, weshalb es nicht für die volle Punktzahl reicht.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

'Nur mit klarem Beleg melden, nicht aus Vermutung' liefert eine explizite Wann-nicht-Regel und der Hinweis auf die Prüfung durch das Stellen-Radar klärt den Kontext. Es werden jedoch keine Alternativen genannt (z. B. stelle_ausblenden für persönliche Ausblendung oder feedback_geben für allgemeines Feedback).

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

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

Annotations already declare non-read-only, idempotent, non-destructive, closed-world behavior, so the safety profile is covered. The description adds one genuine behavioral fact beyond that — the bookmark feeds the recommendation engine — but says nothing about permissions, visibility to others, or rate limits.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, zero filler, with the core action stated first and the side effect second. The parenthetical analogy is compact and earns its place by clarifying intent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return values need not be described, and annotations cover the safety profile; the description supplies purpose and the recommendation side effect. What is missing is routing context relative to the many sibling tools that also act on a Stellen-Treffer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% (4 params, all documented including the rueckgaengig undo flag and the quelle/stelle_id pairing), so the schema carries the parameter burden. The description adds no extra meaning about any parameter; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb and resource ('Eine Stelle merken') and adds a concrete analogy ('wie der Daumen hoch in der App') that pins down the user intent. It does not, however, distinguish this from siblings like feedback_geben or stelle_beworben, which also express positive intent toward a posting.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Usage is implied by the thumbs-up analogy and the note that it feeds recommendations, so an agent can infer this is the positive-signal action. There is no explicit when-to-use/when-not guidance and no routing away from feedback_geben or stelle_ausblenden.

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

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

Annotations declare destructiveHint=true, idempotentHint=true, and readOnlyHint=false, but the description does not explain what is destructively changed, whether existing settings are overwritten, or what authentication is needed. It only adds that the agent sends emails and can be turned off anytime, which is minimal context beyond the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences and front-loads the resource and main behavior. The second sentence about deactivation is brief and relevant, though it could be seen as slightly redundant with the schema's 'an' parameter explanation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple configuration tool with 3 parameters, full schema coverage, and an output schema, the description covers the core purpose and reversibility. It omits usage guidance but the structured fields compensate, making it largely complete for an agent to invoke correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already fully documents the three parameters (profil_id, an, haeufigkeit). The description does not add syntax, format, or interaction details beyond what the schema provides, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description names the resource ('Stellen-Agent eines Profils') and states its effect ('schickt neue passende Stellen per E-Mail'), making the tool's purpose clear without opening the schema. It does not explicitly differentiate from siblings like stellen_finden or treffer_abrufen, but the agent-specific framing is distinctive.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The only usage hint is 'Abschalten jederzeit möglich' (deactivation possible anytime), which implies the tool can toggle the agent off but gives no context for when to use this tool instead of alternatives like stellen_finden or treffer_abrufen. There are no conditions, prerequisites, or exclusions stated.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, not open-world), so the bar is lower, yet the text adds real behavior: what the answer contains per channel, the top-5 hits, per-hit punktzahl plus gemerkt/beworben for saved profiles, and the conditional vergleich_bundesweit that may be omitted if the count takes too long. It loses a point for referencing a 'Feld suche' that does not appear in the input schema and naming profil_anlegen_mit instead of the sibling profil_anlegen.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The core purpose is front-loaded, but the body is long, with an oddly indented separate block restating per-hit fields that the output schema already covers, plus a stray sentence about filtering by 'suche'. Every sentence is roughly informative, but the size and loose paragraphing dilute the signal for a 9-parameter tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given a rich output schema and full annotation coverage, the description supplies what structured fields cannot: the channel taxonomy, the profile-absent fallback, the possible absence of vergleich_bundesweit, and the routing rules to three siblings. An agent has everything needed to select and invoke this tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all 9 parameters and the baseline is 3. The description adds non-obvious semantics beyond the schema — notably that without umkreis_km the search is nationwide even when a location is given, which is exactly the interaction an agent could get wrong.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a concrete question that states exactly what the tool does: count matching positions for structured personal key data. It explicitly distinguishes itself from siblings by naming beste_treffer_zeigen (more hits), marktlage (market overview without location/title) and aenderung_durchrechnen (measurement of a change), so an agent can route correctly without opening the schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Explicit when-to-use rules are given with alternatives: general market question without location/title → marktlage; more hits for the same key data → beste_treffer_zeigen; change effect measurement for a saved profile → aenderung_durchrechnen, otherwise stellen_finden with changed key data. It even states prerequisites (no profile yet → profile arguments are returned) and a scoping rule (pass umkreis_km for a region, otherwise nationwide).

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

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

Goes well beyond the annotations (readOnly=false, destructive=false, idempotent=false) by disclosing that an entry is date-stamped each call, existing text is preserved, the note spans all account profiles, is private to the person, and that over-4000-char input is rejected rather than truncated. These are exactly the behavioral facts an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, each earning its place, with the core action front-loaded and constraints following. No redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists so return values need not be explained. For a 3-param mutation tool, the description fully covers scope, visibility, persistence, and limits — nothing needed 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.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds genuine meaning the schema lacks: the 4,000-character limit is 'insgesamt' (total note length), clarifying that the cap applies to the combined note, not merely the appended text — resolving the ambiguity of the text field's maxLength.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Names a specific verb+resource (ergänzt die eigene Notiz ... um einen Eintrag) and defines exact semantics: appends with today's date, creates if absent. 'Bestehender Text bleibt unverändert' implicitly distinguishes it from stelle_notiz_ersetzen, so an agent can route without opening either schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The append-vs-create behavior gives clear implicit guidance on when this tool applies. However, it never explicitly names stelle_notiz_ersetzen as the alternative for rewriting a note, nor states an exclusion condition, so it falls short of explicit when-not/alternatives routing.

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

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

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false) by disclosing that empty text deletes the note, that a stale stand causes no overwrite with the current text returned, and the 4,000-character cap. This optimistic-concurrency behavior is exactly the operational detail an agent cannot infer from structured fields.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core action, then the token prerequisite, then conflict behavior and the size limit. Every clause carries information; nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

An output schema exists, so return-value explanation is unnecessary, and the description still notes what the response contains on conflict. Prerequisites, limits, and destructive/delete semantics are all covered for a mutation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, with each parameter already documented (text, stand, quelle, stelle_id). The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Ersetzt die eigene Notiz der Person zu einer Stelle durch einen neuen Text'), which is clearly distinct from the append semantics of the sibling stelle_notiz_anhaengen. It does not explicitly name the sibling, so the differentiation relies on the reader inferring 'ersetzen vs anhaengen'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

Gives a concrete prerequisite: stand must be notiz_geaendert_am taken from stelle_im_detail, or "neu" when no note exists. It does not explicitly say when to prefer this over stelle_notiz_anhaengen, but the precondition plus replace semantics make the intended context clear.

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

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, not open-world), so the bar is low. The description adds genuine value beyond them: results are sorted best-first, each hit carries a score whose legend lives in 'punktzahl_legende', and 'gemerkt'/'beworben' flags appear only for a saved profile. No rate limits or pagination behavior are mentioned, but nothing is needed for a safe read.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and ordering lead, and the per-hit content paragraph is compact. The third paragraph drifts into a measurement workflow that is arguably about other tools, which dilutes focus slightly, but each sentence carries information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present and 100% parameter coverage, the description does not need to explain return values. It nonetheless covers sort order, per-hit enrichment, legend location, and routing for the change-measurement question — everything needed to invoke it correctly, apart from sibling disambiguation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including a detailed usage note on 'stellen_anzeigen' and a documented max of 25 for 'anzahl', so the schema does the heavy lifting — baseline 3. The description adds only framing (all hits belong to an own profile, best-first order) rather than parameter-specific semantics beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource — retrieving the hit list ('Trefferliste') of one's own profile — and even specifies ordering ('beste zuerst') plus per-hit fields (punktzahl, gemerkt, beworben). However, it never distinguishes itself from near-identical siblings like 'trefferliste_laden' and 'beste_treffer_zeigen', which an agent could easily confuse with this tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

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

The final paragraph gives explicit routing: for measuring whether a changed level/target position/industry/radius yields more or better jobs, use 'aenderung_durchrechnen' for a saved profile, otherwise 'stellen_finden'. That is concrete when-to-use guidance with named alternatives. It is silent, though, on when to pick this tool over the overlapping hit-list siblings.

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

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

Annotations already declare readOnly/idempotent/non-destructive, so the safety profile is covered; the description layers on real behavioral context: paging via naechster_rang/stand, liste_geaendert signalling list mutation between pages, nicht_enthalten/hinweis explaining excluded fields, and how Empfehlung rows lack rank or score. Much of the per-row field enumeration duplicates what an output schema would carry, which slightly dilutes the added value, but the pagination and list-change semantics are substantive.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose and routing are front-loaded, which is good, but the description runs long and the extended paragraph on per-row fields (zeilenart, punktzahl, gemerkt, beworben, mandant, zuletzt_gesehen, stellenart, notiz) largely restates return content that an output schema already covers. That is text that does not earn its place under the stated rules.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only paged list tool with a full schema and an output schema, the description supplies everything needed to call it correctly: trigger condition, alternatives, pagination loop, change detection, and handling of recommendation rows. Nothing an agent needs is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so ab_rang, stand, profil_id and stellen_anzeigen are already documented in the schema itself. The description reinforces the paging loop (naechster_rang -> ab_rang, stand from previous page) but adds no syntax or format detail the schema lacks. Baseline 3 applies when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource (loads the hit list of one's own profile as working data) and immediately distinguishes itself from siblings by naming treffer_abrufen for displaying hits and stelle_im_detail for a single position. An agent can route between these 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.

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

Explicitly states the trigger condition ('Nur aufrufen, wenn der Nutzer mit seiner Liste über die angezeigten Treffer hinaus arbeiten will') with an enumerated set of qualifying activities, and names both alternatives (treffer_abrufen, stelle_im_detail) with the condition that selects each. Genuinely complete when-to-use guidance.

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