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

Annotations already declare this is a non-destructive write (readOnlyHint=false, destructiveHint=false, openWorldHint=false). The description adds only the target domain (case file) but no behavioral context such as auto-fill behavior from reference_number, the Vermittlungsvorschlag reporting obligation, or whether duplicate entries are prevented. Little beyond the annotations is disclosed.

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, tight sentence with the verb front-loaded and no wasted words. It is appropriately sized for a short action 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?

An output schema exists, so return values need not be explained. But for a 13-parameter, zero-required tool the description provides no orientation about which parameters matter or how the two use cases (application vs. Vermittlungsvorschlag) drive different fields, leaving gaps despite annotation coverage.

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 62%, so the schema documents most parameters itself (source, status defaults, apply_by, reference_number lookups). The description names Bewerbung and Vermittlungsvorschlag, loosely mapping to the source enum, but adds no syntax or format meaning beyond the schema. 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 (Record) and resource (application/Vermittlungsvorschlag in the case file), and even clarifies the domain meaning of the German terms. However, it does not distinguish itself from close siblings like update_application or list_applications, so an agent must infer that this is the creation entry point.

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 no when-to-use guidance: it does not say to use this for new entries only, nor point to update_application for edits or list_applications for reading. The agent is left to infer usage entirely from the name.

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=false and openWorldHint=false, so the agent knows this is a non-destructive local write. The description confirms a create/record action but adds no behavioral detail such as what is persisted, whether duplicates are detected, or auth/context requirements. The consequence note is domain flavor rather than tool behavior.

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 compact sentences, front-loaded with the core action. The parenthetical German terms largely duplicate the schema enum, and the second sentence is contextual rather than operational, but there is little waste overall.

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, and annotations carry the safety profile. However, for an 8-parameter creation tool with 50% parameter coverage, the description leaves an agent without enough detail on how to populate the optional fields or what happens on success, so it is only marginally complete.

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 only 50%, yet the description adds essentially nothing about parameters. The German kind list merely restates the enum values already present in the schema, and the six other parameters (bring, notes, purpose, location, with_whom, invitation_date) receive no clarification, so it fails to compensate for the coverage gap.

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 clear verb+resource ('Record an appointment') and enumerates the appointment kinds, so an agent immediately knows this creates a new appointment record. It is distinguishable from list_appointments and update_appointment by the 'record/add' semantics, though it never names those siblings 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?

No when-to-use guidance, no prerequisites, and no alternatives named. The sentence about consequences of missing an invitation is motivational domain context, not routing guidance telling the agent when to prefer this tool over update_appointment or list_appointments.

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=false, and openWorldHint=false, so the write/safe/closed-world profile is covered. The description adds no behavioral context beyond that (no side effects, duplicate handling, or permission notes). With annotations carrying the safety profile, this is adequate but adds nothing.

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 zero waste; the core action leads and the parenthetical example is genuinely informative.

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 no explanation, and annotations cover safety. Still, for a mutation tool the description omits usage guidance and leaves half the parameters undocumented, so it is only minimally complete.

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 only 50% – title and source are documented in the schema, while due and notes are not documented anywhere. The description's reference to the source document (Eingliederungsvereinbarung/Kooperationsplan) loosely maps to the source param but adds no format or syntax detail to compensate for the gap.

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 (add) and resource (to-do/obligation) with a concrete example context (Eingliederungsvereinbarung/Kooperationsplan). Clear what it does, but does not differentiate from siblings like add_appointment or log_correspondence.

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?

No when-to-use, when-not-to-use, or alternative guidance. The domain example implies it is for obligations from official plans, but an agent gets no routing help among the many sibling creation tools.

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 safety (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower, and the description still adds the crucial non-obvious behavior that the computed end date rolls off weekends and public holidays. That shifting rule is the single most important thing an agent must know and is not derivable from the schema or annotations. It does not say whether results are recomputed against the caller's state by default or how the holiday calendar is sourced.

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 dense sentence that front-loads the operation and legal basis, then closes with a concrete example; nothing is padded. The statutory citations add precision rather than noise, though the sentence is doing a lot of work at once.

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 no explanation, and annotations carry the safety profile. The description supplies the two things it uniquely must: the legal basis for the calculation and the weekend/holiday rolling rule. For a small utility calculator this is sufficient to invoke it 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 only 40% (days and weeks carry no descriptions), so the description must do more work. The example maps '2-week deadline' onto the weeks parameter, which is genuinely useful, but days and months are never explained and it is unclear whether the three unit parameters are additive or mutually exclusive. It partially compensates for the coverage gap but leaves it open.

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 ('period calculation' of deadlines) and grounds it in the governing statutes (§ 26 SGB X / § 64 SGG), which tells the agent this is the statute-based calculator rather than a domain-specific one. It signals 'Generic' in contrast to siblings like objection_deadline and registration_deadlines, but never names those alternatives, so the differentiation stays implicit.

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 example ('a 2-week deadline in a letter from the agency') gives a concrete situation in which to reach for this tool, and 'Generic' hints it is the fallback when no specialised deadline tool fits. There is no explicit when-not guidance, no mention of the required start date, and no routing to objection_deadline/registration_deadlines for their specific cases.

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=false and openWorldHint=false, so the safety profile is covered. The description adds that completion defaults the date to today, which is useful context, but says nothing about reversibility or what happens to an already-completed task.

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 with the action front-loaded and no filler. It is efficient, though arguably too terse to carry the necessary behavioral and parameter detail.

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, but for a mutation tool with zero parameter description coverage the entry is thin. An agent cannot tell what notes accepts, what format done_on expects, or the effect on an already-completed task.

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 0% across three parameters, so the description must compensate. It only hints at the 'done_on' default via '(default today)'; task_id and notes are entirely undocumented in both the description and 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?

The description states a specific verb and resource ('Mark a task as done'), which clearly separates it from the task siblings add_task and list_tasks. It is clear and actionable, though it does not explicitly name or contrast with the alternatives.

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?

There is no when-to-use guidance or stated preconditions; the parenthetical '(default today)' describes a parameter default rather than when to choose this tool over add_task or list_tasks. The usage is only implied by the tool's obvious purpose.

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?

The description adds 'permanently' and 'Returns the deleted entry' beyond the annotations, clarifying irreversibility and return behavior. However, it omits permission requirements, cascading effects on related data, and confirmation needs. With destructiveHint=true already set, this is useful but incomplete context.

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 a single, front-loaded sentence with no wasted words. It covers the action, resource, example, and return value efficiently.

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 tool with two required parameters and 0% schema description coverage, the definition is minimally viable. Annotations cover the safety profile and an output schema exists, so return details are not essential. Still, it lacks any explanation of the kind/entry_id parameters and no indication of when deletion is appropriate versus completing or updating entries.

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 0%, so the description carries the burden for explaining parameters. It refers to deleting 'one entry,' which loosely maps to entry_id, but never mentions the required 'kind' parameter or its enum values. The description adds little semantic meaning beyond the schema's parameter names.

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 states a specific verb and resource: 'Permanently delete one entry from the case file.' It gives an example ('e.g. a duplicate'), making the purpose clear. It does not distinguish this tool from related update/list/add siblings or explain the four supported entry kinds.

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?

There is no explicit guidance on when to use this tool versus alternatives like complete_task, meineba_merkliste_entfernen, or the update_* siblings. The parenthetical 'e.g. a duplicate' implies one scenario, but it is not a usage rule or condition.

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 and destructiveHint=false, so the safety profile is largely covered. The description adds the genuinely non-obvious behavioral trait: the tool produces a draft only and transmits nothing, and the 'log' parameter description reveals it can additionally record the letter as outgoing correspondence – a side effect not implied by the annotations alone.

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 sentences, both earning their place: the first defines what is produced and from what, the second sets the boundary on what does not happen. Front-loaded with the action and free of restatement of the schema.

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 no explanation, and the annotations carry the safety profile. Given that, the description plus the richly documented kind enum and the 'log' flag cover everything an agent needs to draft the correct letter variant without sending anything.

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 kind enum documents per-kind required and optional parameters in detail, so the baseline is 3. The description still adds value by naming the profile-sourced fields (sender, Kundennummer, responsible office) and by framing params as 'see kind' with common optional extras, clarifying where the values come from.

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 (draft) and resource (letter) plus the exact audience (Agentur für Arbeit / Jobcenter) and the data source (the profile). The closing clause 'nothing is sent from here' immediately distinguishes it from a send tool such as meineba_postfach_send, so an agent can triage it against siblings without opening the 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 clear context for when this applies (drafting official letters from stored profile data) and where the workflow stops (the user must check, sign and send). It does not name a sibling to use instead for actually transmitting the letter, nor does it point at log_correspondence for the logging path, so the routing guidance is contextual rather than explicit.

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 openWorldHint, so the safety profile is covered. The description adds the useful note that results include address and web page, but omits anything about lookup scope or failure behavior for ambiguous queries. It also only names three office types while the schema's enum offers a fourth (Berufsinformationszentren), understating the tool's reach.

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; the verb and resource come first. The trailing 'with address and web page' is slightly clumsy phrasing, but it earns its place by hinting at result content.

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 needn't be explained, and annotations carry the read-only/idempotent profile. For a two-parameter lookup this is nearly sufficient; the only real gap is the absence of any guidance on when this lookup is the right call.

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 both parameters are already documented ('Postcode, town or office name' and 'Restrict to these office types'). The description's mention of 'an address' loosely mirrors the query param but 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 ('Find') and concrete resources (Agentur für Arbeit, Jobcenter, Familienkasse) that are visibly distinct from every sibling tool in the list. What's missing is any explicit acknowledgment of how it differs from lookups like overview or rules; it relies on the resource name to carry 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?

The description never says when to reach for this tool rather than overview, rules, or registration_deadlines, nor does it state prerequisites (e.g. a German address/postcode is required). Usage is only implied by the resource name.

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 openWorldHint, so the safety and reproducibility profile is covered. The description adds a summary of the returned content, but does not disclose behavioral traits such as authentication requirements, rate limits, or error behavior. Given the annotations, a 3 reflects modest added value.

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 a single, front-loaded sentence with a colon-separated list of returned fields. There is no filler or redundancy, and every word contributes to clarifying the tool's output scope.

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 retrieval tool with full parameter documentation, safety annotations, and an output schema, the description is largely complete. It states the resource and the kind of details returned, which is sufficient for calling the tool. The only minor gap is the absence of explicit routing from search_courses, but that is covered by the schema.

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 date_id is fully documented with a format example. The description does not add any parameter-level meaning beyond what the schema already provides, so the baseline of 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?

The description clearly identifies the resource ('one course date') and enumerates the returned fields (content, requirements, certificate, cost, funding options, provider contact). It implicitly distinguishes from search_courses by saying 'one course date', but does not explicitly name the sibling or contrast the retrieval scope. A specific verb like 'retrieve' is missing, yet the 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?

The description offers no guidance on when to use this tool versus alternatives. It does not mention search_courses or explain that this is the follow-up step after finding a date_id, leaving that context entirely to the input schema. Without opening the schema, an agent would not know how to obtain the required ID.

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, and openWorld, so the safety profile is covered. The description adds only the scope of returned content (full ad fields), which is modest added value; nothing about auth, rate limits, or failure modes.

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 listing the returned contents with zero padding. Efficient, though a routing clause would have earned the space it uses.

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, and the description covers the ad's contents. For a one-param read tool with full annotation coverage, this is 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 parameter is already documented with a format example ('10001-1000911926-S'). The description adds no further meaning about the reference_number, so 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 (retrieve a full job ad) and enumerates what the ad contains: description, locations, employer, contract details, link. Clear purpose, but it never names its sibling search_jobs to make the search-vs-detail distinction explicit.

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?

No when-to-use guidance and no mention of alternatives. The agent must infer from the name alone that this retrieves a single ad by reference while search_jobs locates ads. No preconditions or context 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?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds one useful behavioral fact beyond the schema – that the result carries salary_kldb_code for downstream get_salaries calls – but says nothing about rate limits, auth, or how the external BERUFENET lookup behaves.

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, front-loaded with the resource and its contents, followed by the single cross-tool fact. Nothing is wasted or padded.

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 covers the profile's contents plus the downstream salary linkage. It is essentially complete for a read-only lookup, with only minor gaps in explaining the external lookup's behavior.

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%: both profession_id (BERUFENET id from search_professions) and sections (with default list and examples) are fully documented in the schema itself. The description adds no parameter detail, so 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 the resource (BERUFENET occupation profile) and enumerates the content it returns (tasks, access requirements, pay, training, alternatives), which distinguishes it from the sibling search_professions by signalling a detail fetch. It never states the verb explicitly ('retrieves/returns a profile'), but the content list makes the intent unmistakable.

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 through chaining cues: the schema ties profession_id to search_professions and the description notes salary_kldb_code is consumed by get_salaries, so an agent can infer the workflow. However, there is no explicit when-to-use or when-not-to-use statement (e.g. search first vs. fetch directly).

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=true, idempotentHint=true and a closed world, so safety and repeat-call semantics are covered. The description adds one useful behavioral fact — that the response includes the settable-field catalogue, which hints at the intended pairing with update_profile — but discloses nothing about freshness, caching, or auth requirements.

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 clause, front-loaded with the main payload and appended with the secondary one; there is no filler to cut.

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 not be spelled out, and a zero-parameter read-only getter is inherently low-risk, so the description is nearly sufficient. The one missing piece is the explicit link to update_profile, which the 'fields that can be set' clause only gestures at.

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?

The tool takes zero parameters, so the baseline of 4 applies; there is no parameter surface for the description to explain or for the schema to cover.

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 concretely names the resource ('the customer's stored profile') and adds the second payload ('the list of fields that can be set'), so an agent knows exactly what comes back. It lacks an explicit verb and never names update_profile, so sibling differentiation is only implied by the phrase 'fields that can be set'.

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?

There is no statement of when to call this versus update_profile or any other sibling, and no prerequisites or context (e.g., login state). The phrase about settable fields hints at a read-then-write workflow but leaves the agent to infer it.

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 read-only, open-world, and idempotent behavior. The description adds important domain context—gross monthly, median/quartiles, full-time employees—that clarifies what the numbers represent, though it omits return format and rate limits. With annotations covering the safety profile, a 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?

Two sentences, front-loaded with the core data and followed by use cases. No wasted words, appropriate length. Score 5.

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 6-parameter tool with an output schema and rich annotations, the description covers the what and why but omits how parameters filter results or that kldb is required (schema covers required). It is adequate but leaves gaps against the complexity. Score 3.

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?

The description adds no parameter-level meaning. The schema documents 4 of 6 parameters (67% coverage), but age and gender lack descriptions, and the description does not compensate. Score 2.

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 specific data source (BA Entgeltatlas) and the exact statistics returned (gross monthly median and quartiles for full-time employees), making the tool's purpose unambiguous. It does not explicitly differentiate from sibling tools, but the resource is unique enough that an agent can tell it apart from get_profession or search_jobs.

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?

Provides clear context for use (judging job offer reasonableness, salary expectations) but does not state when to avoid it or name alternative tools. This is clear context without exclusions, fitting a 4.

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=true, idempotentHint=true, and openWorldHint=false, so safety semantics are covered. The description does add one genuinely useful behavioral fact not present in structured fields: results are ordered newest first. It says nothing about the limit default/cap or pagination behavior, but with annotations carrying the safety profile a 3 is fair.

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; the ordering constraint is stated early. It is arguably too terse for a 5-parameter tool, but nothing in it is wasted.

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?

The output schema exists so return values need no explanation, but for a 5-parameter filtered listing with zero schema description coverage the description is incomplete — filter names, date format, and limit behavior are all absent.

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 0% across 5 parameters, so the description carries the full burden and largely fails. 'Optionally filtered' never names the available filters (since/until/source/status) nor the expected format of the since/until strings or the limit semantics, leaving the agent to guess from enums alone.

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 ('List') and resource ('applications'), plus ordering ('newest first'). It's clear what the tool does, but it doesn't differentiate itself from nearby siblings like proof_of_applications or meineba_antraege, which an agent might also consider for application data.

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 phrase 'optionally filtered' implies filters exist but never says when to use this tool versus proof_of_applications or the meineba_* application endpoints. No prerequisites, no exclusion conditions, no named alternative.

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=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description adds the default filtering behavior, which is useful, but says nothing about ordering (beyond the schema) or result 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?

A single short sentence that front-loads the action and immediately qualifies the default scope. Nothing is wasted.

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 one parameter is fully documented. The only gap is the absence of any differentiation from the overlapping meineba_termine sibling.

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 already documents that false lists all appointments newest-first. The description's 'default: upcoming planned ones' reinforces the schema default but adds no new semantic detail. 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 (List) and resource (appointments) with the default scope clarified as upcoming planned ones. It is clear what the tool does, though it does not distinguish itself from the similarly named sibling meineba_termine.

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 name and the parenthetical default, but there is no explicit statement of when to use this versus meineba_termine or the add/update_appointment siblings. A reader must infer the context.

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=true, idempotentHint=true, and openWorldHint=false, so safety and side-effect profile are covered. The description's one added behavioral fact is the descending sort order, which is genuinely useful, but it says nothing about the 100-item default limit, the 1000 cap, or that results are filtered/paginated.

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; the operation and its ordering are stated immediately. It is efficiently written, though arguably too terse given the undocumented parameters it could have clarified.

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 no explanation, but with four optional parameters, 25% schema coverage, and a domain-specific enum in German, the agent lacks enough to construct correct calls. No guidance on filtering semantics (kind vs query vs since interaction) or on default paging behavior is provided.

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 only 25% – only "query" is documented in the schema. The description supplies no meaning for kind (a 13-value German enum), limit, or since, and does not clarify date format for since or what full-text fields are matched. With low coverage the description is expected to compensate and does not.

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 ("List recorded correspondence") and adds a sorting guarantee ("newest first"), so the operation is unambiguous. However, it does nothing to distinguish itself from siblings like log_correspondence, update_correspondence, or meineba_postfach, so an agent must still infer which of several mailbox/correspondence tools to pick.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as meineba_postfach or meineba_verlauf for retrieving official mail or history. The word "recorded" faintly implies locally logged entries rather than fetched mailbox contents, but that distinction is left to inference.

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=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description usefully discloses two behavioral traits beyond that: the default filter is open-only, and results are sorted by due date. It says nothing about pagination or result limits, so it adds moderate but not rich value.

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 sentence that front-loads the action and resource, then parenthetically qualifies the default scope. No filler, nothing 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?

For a one-parameter read tool with an output schema (so return values need no explanation), the description covers the default filter and sort order sufficiently to invoke it correctly. Minor gaps remain around result volume/pagination and how it relates to the other list_* tools.

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 0% and the single parameter include_done has no description, so the description must carry the meaning. 'Optionally including completed ones' does explain the parameter's effect and its default false behavior, but only in prose and without naming the parameter or confirming the default explicitly.

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 ('List open tasks') plus the ordering ('by due date') and a scope modifier ('optionally including completed ones'). It is clear what the tool returns, though it never names or contrasts with sibling listing tools such as list_appointments, list_correspondence or list_applications.

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?

There is no explicit when-to-use guidance, no prerequisites, and no alternative tool named. The scope ('open tasks') only implies usage; an agent must infer that this is the general task-listing entry point versus add_task/complete_task.

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, destructiveHint=false, openWorldHint=false), but the description adds a genuine side effect beyond them: an incoming Bescheid automatically triggers Widerspruch deadline calculation and tracking. That is exactly the kind of non-obvious behavior an agent needs; other side effects (e.g., task creation) are only visible via the schema.

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 tight sentences, front-loaded with purpose and followed by the key behavioral caveat. No filler; every clause 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?

An output schema exists, so return values need not be described. For a 13-parameter logging tool the description conveys purpose and the main side effect, though it says nothing about the numerous optional fields (channel, file_path, reference, etc.) beyond what the schema already covers.

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 69%, so most parameters are already documented. The description only implicitly ties 'Bescheid' to the deadline behavior, adding no syntax or format 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?

The description states a clear verb+resource ('Record a letter, decision, e-mail, call or meeting'), so an agent understands this creates a correspondence entry. It does not explicitly distinguish itself from siblings like list_correspondence or update_correspondence, so the 'record/create' intent is implied rather than contrasted.

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 context is only implied – 'Record' suggests a create operation and the second sentence hints at when deadline tracking matters (incoming Bescheid). There are no explicit when-to-use/when-not statements or references to the neighboring update_correspondence / list_correspondence tools.

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 openWorldHint, so the safety profile is covered. The description adds conceptual value by indicating the response is a status/pending overview, but says nothing about return format, ordering, or how 'action expected' is represented. With annotations carrying the behavioral burden, a 3 is appropriate.

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 compact sentences with the resource front-loaded and the useful scoping phrase ('what is pending and whether action is expected') carried in the same breath. No filler, though the parenthetical German label is redundant with the tool name.

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?

There is no output schema and no annotations detail, so the description carries the return-value burden; it gestures at the content (pending status, action expectation) but does not describe the shape of the response. Adequate for a simple read-only overview tool, but not fully complete.

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 0% and the description does not mention the single 'limit' parameter at all. The schema's own default (50) and bounds (1-200) make the parameter's meaning somewhat inferable, but the description contributes no semantic detail to compensate for the coverage gap.

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 a specific resource ('Status of the user's applications (Antragsübersicht)') and adds scope ('what is pending and whether action is expected'). An agent can tell what it returns, though it never distinguishes itself from the singular sibling meineba_antrag or from meineba_leistungen/meineba_status.

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?

No when-to-use guidance, no exclusions, and no reference to the many similar siblings (meineba_antrag, meineba_status, meineba_leistungen). The purpose is implied by 'Antragsübersicht' but the agent is left to infer when this tool should be chosen over its near-duplicates.

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 openWorldHint, so the safety profile is covered. The description adds that the response contains status, required actions and documents, which is useful return-content context, but it says nothing about permissions, data freshness, or output format.

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 fragment listing the resource and its returned aspects. No filler or redundancy.

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 tool with no output schema, the description gives a partial picture of the return (three named fields) but omits how vorgangs_id and aue_version combine to identify the record and what else the response may contain. Adequate but with clear gaps.

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 only 50%: aue_version is described ('aueVersion from meineba_antraege') but vorgangs_id has no description in either schema or prose. The description mentions no parameters at all, so it does not compensate for the undocumented ID or its relationship to aue_version.

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 resource ('one application') and enumerates the aspects returned (status, required actions, documents). The singular 'one application' implicitly contrasts with the plural sibling meineba_antraege, but no sibling is named explicitly, so the distinction is inferred 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?

There is no when-to-use guidance, no prerequisites, and no named alternative. The agent must infer from the name that this is the single-record counterpart to meineba_antraege, with nothing in the text confirming or excluding that.

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=true, idempotentHint=true, and openWorldHint=true, so safety and repeatability are covered. The description adds only the fact that the saved searches carry e-mail alerts, which is a data attribute rather than a behavior; it says nothing about authentication requirements, scope (all saved searches vs. a subset), or ordering.

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 phrase, front-loaded with the resource and its distinguishing feature. Nothing is wasted, but the terseness is close to under-specification rather than deliberate brevity.

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 no parameters and no output schema, the description carries the burden of explaining what comes back and under what conditions, and it does not: no indication of the returned fields (search terms, alert frequency, status) or the authenticated meinBA context implied by the sibling login tools.

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?

The tool takes zero parameters, which is the baseline-4 case. Nothing in the description is needed to disambiguate inputs, and none are introduced that the schema lacks.

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 (saved job searches / Suchaufträge) and a distinguishing attribute (e-mail alerts), but uses a bare noun phrase with no verb, so it never states whether it lists, retrieves, or manages them. An agent can guess it is a read against the stored-search collection, but it is not confirmed. Siblings like search_jobs and meineba_merkliste are not referenced, so differentiation is left to the name.

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?

There is no when-to-use guidance at all. It does not say whether to call this instead of search_jobs when the user wants their own saved searches, nor any prerequisite such as being logged in via meineba_login_start.

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 openWorldHint, so the safety profile is covered. The description adds that the data mirrors what is displayed in the Meine BA portal, hinting it depends on a logged-in session, but it never states the auth requirement or what happens when no session exists.

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 clause with no filler and the resource front-loaded. It is terse and efficient, though its brevity edges toward under-specification rather than optimal conciseness.

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 zero-parameter read tool with no output schema, the description is only marginally sufficient: it conveys what data comes back but omits the login/session prerequisite implied by the surrounding meineba_login_* siblings. An agent could plausibly call it without a session and fail.

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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. The description correctly implies the result set is unfiltered (all granted benefits and payments).

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 (granted benefits and payments) and the data source (Meine BA), which is meaningful, but supplies no verb at all – it is unclear whether this lists, summarizes, or details records. It also does not distinguish itself from siblings like meineba_antraege or meineba_status, leaving the agent to infer the boundary.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as meineba_antraege for applications or meineba_verlauf for history. The agent must guess when this tool is the right choice.

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?

The annotations already communicate that this is not read-only, not open-world, and not destructive, so the description carries less burden. It adds the useful detail that a one-time code is exchanged, but does not describe session effects, failure behavior, or what happens to the previous login state.

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 wasted words, clearly stating the action and the dependency on the start 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?

With a full output schema and precise parameter schema, the description only needs to orient the agent, which it does by linking to the start tool and naming the one-time-code exchange. Minor gaps remain around session outcomes and error handling, but the core call context is complete.

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 redirect_url is the full post-sign-in browser address containing code= and state=. The description adds no syntax or format meaning beyond the schema, so the baseline of 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?

The description states a specific verb and resource ('Complete a login') and explicitly links it to the sibling tool 'meineba_login_start', so an agent can distinguish it from other tools without inspecting 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?

It clearly indicates the context in which to use the tool: completing a login previously initiated via meineba_login_start. It does not list when not to use it or name alternative completion paths, but the dependency is explicit.

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 (readOnlyHint=false, destructiveHint=false, openWorldHint=false) are consistent but thin; the description adds real behavioral context: the call returns a link the USER opens in their own browser, authentication happens on sso.arbeitsagentur.de, and the agent must never ask for or handle the password. That is exactly the security constraint an agent needs for an auth tool.

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 clauses, zero filler, and the purpose is front-loaded before the security instruction. The semicolon construction packs the critical 'never handle the password' rule compactly without burying it.

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 return value need not be explained in depth, and the description nonetheless confirms it returns a sign-in link. For a 1-parameter auth-initiation tool it covers the essential constraints, though it omits the follow-up step (login_finish).

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 enum documents all six services in detail, so the schema carries the parameter semantics. The description only adds 'for one service', which restates the schema rather than extending 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?

States a specific verb and resource: starting a login to the user's Meine BA account, scoped to 'one service'. An agent can tell it is the entry point of the auth flow, but the description never names meineba_login_finish or meineba_logout, 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 implied by 'start a login' in a set that also contains login_finish, but the description never says what to do next or when to choose this over other entry points. It gives strong in-flow guidance (open the link yourself, do not handle the password) rather than 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.

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds one meaningful detail beyond that — that stored tokens are deleted, not just the session ended — but says nothing about re-authentication requirements or whether deletion is scoped per service.

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 tight sentence with the action front-loaded and no filler. Every word 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?

For a simple logout tool with full annotation coverage, a complete parameter description, and an output schema, the description covers the essentials. The only gap is that it doesn't address the per-service scope implied by the schema's optional parameter.

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 single 'service' parameter already carries the 'Omit to log out of all' guidance and its enum values. The description adds no syntax, default, or scoping meaning 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 and resource — ending Meine BA sessions — plus the concrete side effect of deleting stored tokens. It is clearly distinguishable from the login siblings (meineba_login_start/finish), though it never names them 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?

There is no when-to-use guidance, no mention of when logout is required versus merely optional, and no reference to the login counterparts as alternatives. The agent must infer the lifecycle from the tool name 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=true, so the safety profile is covered. The description adds the useful content disclosure that each entry carries notes and application status, but it omits that BA Jobsuche data typically requires an authenticated session, and says nothing about ordering or scope of the returned list.

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 that defines the resource and its payload with no filler. It is arguably slightly under-specified rather than too long, so it sits just below a 5.

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 no output schema, the description carries the burden of describing returns; it does note that entries include notes and application status, which helps. However, it does not describe the shape of the list (fields per job, ordering, pagination) or the auth requirement, leaving meaningful gaps for a zero-param read 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline of 4 applies. No parameter-level meaning is needed or missing.

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 resource (the user's job watch list in the BA Jobsuche) and describes its contents (notes and application status per job), so an agent knows exactly what data this surfaces. It lacks an explicit verb (list/retrieve), and it does not distinguish itself from the sibling tools meineba_merkliste_setzen and meineba_merkliste_entfernen, so it falls short of a 5.

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 states what the resource is but never says when to call it versus meineba_merkliste_setzen, meineba_merkliste_entfernen, or meineba_gespeicherte_suchen. No prerequisites, no read-vs-write routing, no exclusions 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?

Annotations already declare chunks: destructiveHint=true, readOnlyHint=false, openWorldHint=true. The description adds valuable beyond-annotation context: the note and status of the entry are permanently lost, warning of irreversibility. It does not, however, mention auth/login prerequisites given the surrounding meineba tools.

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?

One concise sentence, front-loading the action and immediately noting the destructive consequence in parentheses.

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 1-param destructive tool with annotations covering the safety profile, the description is nearly complete: it states the effect and the data loss. Missing only authentication/entry-format detail, which is minor here.

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?

Only 1 parameter (reference_number) with 0% schema description coverage. The description says to specify the job to remove, implying a job identifier, but doesn't explain that the reference_number is what's expected or its format. This partly compensates but leaves a gap.

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 (Remove) and resource (job from the Jobsuche watch list), clearly distinguishing it from the sibling meineba_merkliste_setzen which adds/sets entries.

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 name and the mention of the watch list, but there is no explicit when-to-use vs alternatives guidance or prerequisites (e.g., a login requirement, given the many meineba_login 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 readOnlyHint=false, destructiveHint=false and openWorldHint=true, so the mutation/safety profile is covered. The description usefully adds that this is an upsert (add OR update) and enumerates the valid status values, but it omits prerequisites (authentication), what happens when the job is not already on the list, and the result shape.

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 well-formed sentence with the action front-loaded and no wasted words. The trailing status list is slightly redundant with the schema but does not bloat the definition.

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 mutating, no-output-schema tool it covers the basic operation and field meaning, and annotations carry the safety profile. However, it leaves the required key, the add-vs-update distinction, and authentication context unstated, so it is only minimally complete.

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 low (33%) and the description does not compensate. It names note and status, but the status values it lists are already present in the schema enum, and the required reference_number parameter is undocumented in both schema and description, so an agent gets no extra meaning.

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 a specific verb and resource (add/update a job on the Jobsuche watch list) and enumerates the updatable fields (note, application status). It is clear what the tool does, but it does not explicitly distinguish itself from siblings like meineba_merkliste_entfernen (removal) or meineba_merkliste (listing), so an agent must infer the boundary.

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?

There is no when-to-use or when-not guidance and no alternatives are named. The agent is not told that removal belongs to meineba_merkliste_entfernen or that this is an upsert keyed on reference_number, leaving selection between siblings to inference.

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=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds the scoping fact (this returns folder contents, param selects which folder), but says nothing about result limits, pagination, or how many messages come back.

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 efficient sentence with the core action front-loaded and the folder clarification in a tight parenthetical. Nothing extraneous, though it is arguably too terse to do more than state the action.

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 list tool with no output schema, the description covers the essentials and annotations cover safety. It is still missing any statement about pagination/size limits and any disambiguation from meineba_postfach_read, which an agent choosing among postfach tools would want.

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 0%, so the description must carry the parameter load. It does list all four folder values and translates the default ("erhalten = inbox"), which adds meaning beyond the bare enum, but gesendet/entwurf/geloescht are left untranslated and the default's behavior is not explained.

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 ("List messages in the user's BA Postfach") and unpacks the folder concept with a concrete example. It is clearly distinguishable from siblings like meineba_postfach_send or meineba_postfach_attachment, but it never explicitly contrasts with meineba_postfach_read, which is the nearest neighbor.

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?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives such as meineba_postfach_read for opening a single message. Usage is only inferable from the verb "List".

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 readOnlyHint=false, destructiveHint=false, openWorldHint=false, so the write-local-file aspect is already signalled by structured data. The description usefully adds that the file is created with mode 0600, a real behavioral detail beyond the annotations, but omits whether it overwrites an existing file or what happens on write failures.

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 that states action, target, destination, and file-permission behavior with zero 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, but with three required parameters at 25% coverage the description should at least indicate that message_id and attachment_id are obtained from listing/reading a Postfach message. That context is missing, though the core invocation path is clear.

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 only 25%: save_to is documented, but message_id and attachment_id are bare strings and folder is only an enum with a default. The description adds no meaning about where message_id/attachment_id come from or what the folder default implies, so it fails to compensate for the coverage gap.

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 states a specific verb (Download) and resource (attachment of a Postfach message) plus a concrete example artifact (Bescheid as PDF), which clearly separates it from siblings like meineba_postfach (listing) and meineba_postfach_read. It does not explicitly name an alternative tool, but the purpose 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?

There is no when-to-use guidance, no prerequisites, and no mention of the alternative tools for accessing Postfach content. An agent must infer from the name alone that this is the tool for retrieving an attachment rather than reading a message body.

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?

The annotations declare readOnlyHint=true and idempotentHint=true, but the description states that opening a message 'may mark it as read' — a state mutation that directly conflicts with the read-only claim. Per the rubric, a description that contradicts annotations scores 1; the agent receives two conflicting signals about whether this call changes state.

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 tight sentences with zero filler; the core action and return contents are front-loaded, and the side-effect warning follows immediately. Every clause 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?

For a simple two-parameter read tool with no output schema, the description covers the primary action and return shape, which is the minimum viable level. However, with 0% schema coverage the folder parameter and not-found/error behavior remain undocumented, leaving gaps for correct invocation.

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 0% for two parameters, so the description carries the burden and does not meet it. It never mentions the 'folder' parameter or its enum (erhalten/gesendet/entwurf/geloescht), nor clarifies message_id format or origin.

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 ('Read one Postfach message') and adds scope detail ('including its history and attachment list'), so the agent knows exactly what comes back. It does not explicitly distinguish itself from close siblings like meineba_postfach (list) or meineba_postfach_attachment, so it falls short of a 5.

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?

There is no guidance on when to call this versus meineba_postfach or meineba_postfach_attachment, and no prerequisites such as login state. The 'may mark it as read' note is a behavioral disclosure, not a usage condition.

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 and open-world, so safety is covered. The description adds genuine context beyond them: it explains the domain mapping ('Agentur = AA, Jobcenter = JC') and the 'bezug' topics concept, which tells the agent what the payload contains and why openWorldHint matters 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?

Two sentences, front-loaded with what is returned and followed immediately by the prerequisite. No filler or restatement of the name.

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 spelled out, and the description covers what the agent needs: the recipient/topic structure and the prerequisite on meineba_postfach_send. The only gap is that the exact field names of the returned recipient objects are left entirely to the output schema.

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?

The tool takes zero parameters, so the baseline of 4 applies. There is nothing for the description to disambiguate at the parameter level.

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 (offices the user can write to) and resource (Postfach recipients) plus the topics each accepts, so the returned data shape is clear. It does not explicitly distinguish itself from sibling Postfach tools like meineba_postfach_read, but the noun 'recipients' is distinct enough not to be confused.

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?

'Needed before meineba_postfach_send' explicitly names the dependent sibling and the ordering condition, which is the key routing signal. There are no exclusions or alternative paths given, but for a zero-argument lookup tool that is a minor omission.

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 write (readOnlyHint=false), non-destructive, open-world framing. The description adds genuinely new behavioral context: the preview-vs-send two-phase flow and the fact that sent messages are binding and persisted to the local case file. It omits auth requirements and error behavior, so not 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.

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

Three short sentences with the core action front-loaded, then the preview/send distinction, then the consequence. No filler and nothing buried.

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 send tool with an output schema (which carries the preview payload) and annotations covering the write profile, the description supplies the confirmation protocol and side-effect note an agent needs. It leaves the sourcing of recipient_id/topic fields to the schema descriptions, which are present.

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 67% and the schema already explains confirm ('Must be true to actually send'), topic, recipient_id and recipient_name. The description's only parameter-relevant content restates the confirm flag, adding no format or sourcing detail for text/subject beyond the schema. Baseline 3 fits.

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 ('Send a message') and resource ('through the user's Postfach') with the target authority named. It implicitly separates itself from read-side siblings like meineba_postfach_read and meineba_postfach, but never names them explicitly, so it lands short of a 5.

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 confirm=true gating gives a clear when/when-not: without it the call is a harmless preview, with it the message is actually sent. It stops short of naming alternative tools or stating prerequisites such as login state or required recipient lookup via meineba_postfach_recipients.

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=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered by structured data. The description adds that the response covers session longevity and per-service offerings, which is mild supplementary context, but it does not state whether authentication is required to read login status or whether results are cached/stale.

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, covering the three main content areas. The phrase 'what each one offers' is somewhat vague but does not waste space.

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 describe return values, and it correctly summarises what the response contains. For a zero-parameter read-only tool this is nearly sufficient; only the ambiguity about whose session is being reported (current user vs. all services) leaves a small gap.

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?

The tool takes zero parameters, so the baseline of 4 applies. Schema description coverage is 100% and there is nothing for the description to disambiguate at the parameter level.

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 (Meine BA services login/session status) and enumerates three outputs: which services are logged in, session duration, and offered capabilities. However, it has no explicit verb and no differentiation from session-related siblings like meineba_login_start, meineba_login_finish, and meineba_logout, leaving the agent to infer whether this reads existing state or performs a login action.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The agent is not told, for example, whether this should be called before or after meineba_login_finish, nor whether it supersedes meineba_termine or meineba_verlauf for session-related queries.

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 openWorldHint, so the safety profile is covered by structured data. The description adds only the provenance of the data (Meine BA portal), and omits notable behavior such as the likely need for an authenticated Meine-BA session given the meineba_login_* siblings, and what the returned appointment set looks like.

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 compact sentence with no filler; the resource is front-loaded. It is arguably too terse to be maximally useful, but nothing in it is wasted.

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 listing tool with full schema coverage and no output schema, the description is minimally viable but incomplete: it says nothing about the authentication/session requirement implied by the meineba_login_*/meineba_logout siblings, nor about how results relate to the local list_appointments 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 coverage is 100% and the single optional 'now' parameter is fully documented in the schema as a YYYY-MM-DD reference date defaulting to today. The description adds nothing beyond that, 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?

The description names a specific resource (appointments booked with the Agentur für Arbeit / Jobcenter via Meine BA) but supplies no verb, leaving it ambiguous whether the tool lists, fetches, or syncs them. It also does not differentiate itself from the sibling 'list_appointments', which an agent could easily confuse with this one.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the alternative tools (list_appointments, add_appointment, update_appointment) that overlap in topic. The agent must infer the context entirely.

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=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered. The description adds the taxonomy of event types, which is useful context, but says nothing about pagination flow (implied only by the 'before' param) or volume/rate behavior. Given annotations carry safety, a 3 fits.

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 tight sentence with zero waste, front-loading the resource and its contents. It is appropriately sized, though the parenthetical could be trimmed slightly.

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 list tool whose annotations cover the safety profile, this is close to adequate, but with three parameters at 33% schema coverage and no output schema, the agent still lacks pagination and filter semantics. The description should do more to be complete.

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 only 33% (only 'before' is documented; 'limit' and 'search' are bare). The description adds no parameter meaning at all and does not compensate for the coverage gap, so the agent gets no guidance on what 'search' filters or what 'limit' bounds.

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 resource ('History of events in the user's account') and enumerates the event types it covers (applications, letters, decisions, documents). This is clear, but it never names or differentiates itself from the close sibling meineba_verlauf_eintrag, so an agent must infer the singular-vs-list distinction on its own.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as meineba_verlauf_eintrag for a single entry. The description only states what the tool is, leaving selection entirely to inference.

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=true, openWorldHint=true, and idempotentHint=true, so the safety profile is covered. The description adds that the response includes details and document links, a modest but real disclosure beyond the 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?

A single tight sentence with no filler that front-loads the resource and its returned content. It is arguably under-specified for a tool that has behavioral gaps to close, but the sentence itself 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?

For a simple one-param lookup with annotations covering the safety profile and no output schema, the description conveys the core content. It is missing the provenance/format of entry_id and does not connect itself to the listing tool, leaving a real gap.

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 0% and the single entry_id parameter is completely undocumented in both schema and description. The description never explains where entry_id comes from (presumably from meineba_verlauf) or its format.

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 resource (a single Verlauf entry) and what it returns (details and document links), which implicitly distinguishes it from the sibling meineba_verlauf list tool. It does not name that sibling explicitly, so it falls just short of a 5.

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?

No when-to-use, prerequisites, or alternatives are given. The agent must infer that this is the single-entry lookup counterpart to meineba_verlauf purely from the word 'One entry'.

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 (readOnlyHint, idempotentHint, openWorldHint=false), so the bar is lower. The description adds one behavioral fact beyond them – that the result includes 'step-by-step reasoning' – but says nothing about the 4-day postal delivery rule, the effect of a missing/incorrect legal remedy instruction, or how holidays are handled, all of which drive the computation.

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 sentence with no filler, and the core deliverable is front-loaded ahead of the legal citations and the reasoning note. Nothing needs to be trimmed, though it is doing less work than its length allows.

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, and annotations cover the read-only safety profile. For a legally nuanced deadline calculator with five parameters, however, the description omits the caveats (delivery rule, faulty legal remedy instruction) that make its answers trustworthy.

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 60%, so the schema documents most fields already (state, received_on, letter_date). The description contributes the legal framing of the deadline but no parameter-level meaning beyond what is in the schema, so the 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?

The description gives a specific deliverable ('Last day to file a Widerspruch against a Bescheid') plus the governing provisions (§ 84 SGG, § 37 SGB X), so the agent knows exactly what is being computed. It does not, however, distinguish itself from the sibling calculate_deadline, which superficially sounds like the same job.

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?

There is no explicit when-to-use statement, no prerequisites, and no routing away from the overlapping sibling calculate_deadline. Only the implied context (user has received a Bescheid and wants the objection deadline) tells the agent when to reach for this tool.

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?

The annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful context about what the dashboard aggregates (alerts, deadlines by category, quota progress), but says nothing about result volume, refresh/latency, or how the horizon affects the output. Adequate but not rich.

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; the enumeration is the most informative part and comes immediately after the resource. It is a noun phrase fragment rather than a full sentence, which is terse but acceptable for a dashboard 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?

An output schema exists, so return values need no explanation, and the annotations carry the safety profile; only one optional parameter needs documenting. What remains thin is routing — nothing tells the agent to start here versus calling the granular list_* tools — but the functional picture is otherwise complete.

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?

Single optional parameter with 100% schema description coverage ("Look-ahead for appointments"), so the schema already carries the semantics. The description does not mention horizon_days or clarify whether it governs appointments only or also deadlines, so it adds nothing over the schema — the baseline 3 for full coverage.

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 ("Dashboard of the case file") and enumerates its contents verbatim — alerts, upcoming appointments, open deadlines, application count vs. monthly requirement — so an agent knows what it returns. It is distinct in spirit from the granular list_appointments / list_tasks / list_applications siblings, but never explicitly contrasts itself with them, leaving the differentiation 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?

There is no explicit when-to-use or when-not-to-use statement, and no sibling is named despite a very large set of granular alternatives (list_appointments, list_tasks, proof_of_applications, etc.). However, the word "overview" plus the aggregation framing implicitly signals it as a summary entry point rather than a filtered detail query.

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 readOnlyHint=false, and the description explains exactly why: the tool returns the document but may additionally write it to a file, which is a side effect beyond the read-only baseline. It does not mention any eServices authentication/upload prerequisites, but with annotations already covering the safety profile this is a meaningful addition.

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 sentences, no filler, and the core action plus the deliverable are front-loaded before the optional file-write detail.

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, period, and the optional file output. It leaves the format choice and any eServices prerequisite implicit, but the essential calling information is complete.

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 75%, with since/until already documented with examples and output_path described in the schema. The description restates the period and the optional file write but adds no syntax or semantics beyond the schema, and it never mentions the format enum (markdown/csv), so 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 (Generate) and a precise, domain-specific resource ('Nachweis der Eigenbemühungen' / list of applications) scoped to a period, and explains the intent (submission in eServices). This is clearly distinguishable from siblings like list_applications, which merely enumerate entries rather than produce the official proof document.

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 clear usage context: generate the proof when it needs to be handed in or uploaded in the eServices. It does not, however, state exclusions or name the alternative tool (list_applications) for merely browsing applications, so the routing guidance is good but not complete.

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 openWorldHint=false, covering the safety profile for a lookup. The description adds nothing behavioral beyond that — no note on how state defaults are resolved, whether results are cached, or how nationwide vs. regional holidays are returned. An output schema exists, but the description still contributes no extra context.

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 with no filler and the resource front-loaded. It is efficient, though the terseness is close to under-specification rather than optimal conciseness.

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?

The tool is simple (two params, one required) and an output schema covers return values, so the bar is low. Still, the description omits that holidays are German/Bundesland-scoped and never mentions the year/state lookup, leaving the agent to reconstruct context from the schema alone.

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 only 50%: the 'year' parameter has no schema description and no documentation in the description, and the description doesn't explain the semantics of year or state either. With a low coverage rate the description should compensate but does not, so meaning is missing for half the inputs.

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 resource (public holidays) and ties it to a concrete use (deadline calculations), so an agent knows what it returns. It lacks a verb and doesn't contrast itself against siblings like calculate_deadline or registration_deadlines, but the resource is unambiguous enough to distinguish it.

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 phrase 'relevant for deadline calculations' hints at a use case but never states when to call this tool, in what order relative to calculate_deadline, or whether it should be used standalone. There are no exclusions or alternatives named, so the agent must infer the workflow.

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 openWorldHint=false, so the safety profile is covered. The description adds only domain framing (the two statutory bases), saying nothing about defaults, computation behavior, or how results relate to profile dates. With annotation coverage the bar is lower, so a 3 is appropriate.

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 sentence with zero filler, front-loading the resource before the statutory qualifiers. Nothing to trim.

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 needn't be explained, and both parameters are well documented in the schema. The description covers the tool's scope adequately; only the usage/exclusion guidance is absent.

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 both parameters (learned_on, employment_end) carry their own default behavior notes. The description adds no syntax or meaning 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 resource (registration deadlines) and splits it into two distinct legal cases, §§ 38 and 141 SGB III. An agent can tell it apart from siblings like objection_deadline, calculate_deadline, and unemployment_benefit_duration. It stops short of 5 because it doesn't explicitly contrast those siblings.

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 no when-to-use guidance, no prerequisites (e.g. that it needs an employment end date), and names no alternatives. Usage is only implied by the concept of registration deadlines.

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=true, idempotentHint=true and openWorldHint=false, so safety and determinism are covered structurally. The description adds that output is a plain-language summary with legal references, which is useful content context, but it says nothing about format, length, or language of the references.

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, tightly scoped sentence that front-loads the deliverable ('plain-language summary') and qualifies it with scope and added value ('with legal references'). 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?

An output schema exists and there is a single enum-constrained parameter, so return details need not be restated. What is missing is routing guidance against the overlapping siblings, but the core informational need is otherwise met.

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 topic parameter enumerates all 13 allowed values, so the schema fully documents the input. The description adds no syntax or selection meaning 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?

The description states a specific verb and output form: it produces a 'plain-language summary of the customer's rights and duties on a topic, with legal references.' That is clear and concrete, though the tool name 'rules' is generic and the description does not differentiate it from overlapping siblings like objection_deadline or registration_deadlines.

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?

There is no guidance on when to call this versus alternatives, despite siblings that clearly overlap thematically (registration_deadlines, objection_deadline, unemployment_benefit_duration, calculate_deadline). The agent must infer that this is the general explainer for a topic while those are narrower deadline calculators.

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, openWorldHint and idempotentHint, so the safety profile is covered. The description adds useful structural context (each offer carries up to five dated sessions and only a date id unlocks full detail), but says nothing about pagination behavior despite page/size parameters.

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 with no filler, and the core purpose is front-loaded. The stray line break is cosmetic rather than a comprehension problem.

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 not required, and the description correctly focuses on the get_course follow-up. Minor omissions remain around pagination defaults and result ordering, but nothing essential to invoking the tool 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 71%, so the schema already documents state, keyword, location, radius_km and remote_only. The description adds no syntax or format detail for any parameter and only alludes to date ids, which are not themselves an input here. 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?

Names a specific verb (search) and resource (further-training courses / Weiterbildungssuche of KURSNET), which is enough to separate it from search_jobs and search_professions by domain alone. It doesn't explicitly name a sibling for disambiguation, so it stops short of a 5.

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 usage context: results carry up to five dates each, and a date id should be passed to get_course for details like funding, costs, contacts and requirements. That is a concrete when-to-use chain, but there is no 'when not to use' or exclusion 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 readOnlyHint, idempotentHint and openWorldHint, so safety is covered. The description adds useful behavior beyond that: results are condensed offers carrying a reference_number, which tells the agent the response is not the full ad and implies a follow-up call. It omits pagination/rate-limit behavior, so not 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.

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

Two sentences, zero filler. The core purpose is front-loaded, followed immediately by the downstream routing and the reference_number linkage.

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 12-parameter, all-optional search tool with an output schema and annotations, the description covers purpose, result nature and next steps. Gaps are minor: no mention of pagination defaults or that all filters are optional, but the output schema and rich schema descriptions carry most of the load.

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 83% and the schema already documents what/where/employer/radius_km/offer_type/working_time etc. The description adds no parameter-level meaning (no syntax, defaults, or interaction hints such as radius requiring where), 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 (Search) and resource (the Jobbörse of the Bundesagentur für Arbeit), and enumerates the covered content types (jobs, apprenticeships, internships). It also names the sibling tools it is not (get_job, add_application), so an agent can distinguish it from related tools 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.

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

Explicitly routes the agent downstream: use get_job for the full ad and add_application to record an application. The Jobbörse scoping implicitly separates it from search_courses/search_professions, but it does not state when-not-to-use or compare against those siblings explicitly, so it falls 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 cover the safety profile (readOnly, idempotent, openWorld), so the description's added value is the note that results are IDs feeding get_profession. It says nothing about result limits, the size parameter's effect, or pagination behavior. With annotations carrying the safety burden, this is adequate but thin.

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 compact sentence with the core action front-loaded and the output relationship appended. No filler or redundancy.

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 structure needn't be explained. The description is essentially sufficient for a two-parameter read-only search, with only the 'size' parameter's behavior left implicit.

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 50%: 'query' is documented in the schema with examples, but 'size' is undocumented in both schema and description. The description adds no parameter meaning beyond what the schema provides, which is the baseline-3 case for this coverage level.

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 concrete verb+resource ('Find occupations in BERUFENET') and clarifies the output contract (returns profession ids to feed get_profession), which separates it from the downstream get_profession tool. It does not explicitly distinguish itself from other search_* siblings (search_jobs, search_courses), leaving slight ambiguity about scope.

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 mention that it 'returns profession ids for get_profession' implies a search-then-retrieve pattern, which is useful implied guidance. However, there is no explicit when-to-use/when-not statement or reference to alternative search tools, so usage must be inferred.

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 closed-world behavior, so safety is covered. The description's only added behavioral signal is the statutory basis (§ 147 SGB III), implying a deterministic, rule-based estimate rather than a lookup of the user's personal claim; it says nothing about whether results are binding, which claim prerequisites apply, or that it is an approximation only.

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 zero filler; the verb, resource and legal basis come first. 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 exists, so return values need not be described. However, for a statutory-benefit calculation tool, the description omits useful framing: that it applies § 147 thresholds, that inputs are insurance months, and that the result is an estimate rather than an entitlement decision. Adequate but thin.

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?

All three parameters are documented in the schema at 100% coverage, including the Rahmenfrist meaning of months_insured_last_30_months, so the schema carries the parameter burden. The description adds no parameter-level meaning (e.g., how age interacts with the raised duration thresholds under § 147), leaving it at the baseline 3.

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 states a specific verb ('Estimate') and a specific resource ('how long Arbeitslosengeld is paid'), plus the governing statute (§ 147 SGB III), which makes the tool's subject matter unambiguous among a large set of German employment-agency siblings. It does not explicitly contrast itself with neighboring tools like 'rules' or 'meineba_leistungen', so it stops short of a 5.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as 'rules' or 'meineba_leistungen'. The only implicit cue is that the tool answers duration questions about Arbeitslosengeld.

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=false, destructive=false, openWorld=false, so the safety profile is covered and 'Update' is consistent with them. However, the description omits the key behavioral trait that this is a partial update where unspecified nullable fields may be preserved or cleared, which an agent needs to know.

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 compact sentence with the verb and affected fields front-loaded and no filler. It is efficient, though the German value examples push it slightly toward being a list rather than a definition.

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, and annotations cover safety. But for a 10-parameter mutation with low schema coverage, the description should disclose partial-update semantics and the remaining fields, which it does not.

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 only 30% across 10 params, so the description must compensate. It covers status (with German example values that hint at the enum meanings), dates, and notes, but leaves channel, contact_person, and employer_address undocumented, so it only partially fills the gap.

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 ('Update') and resource ('an application') and enumerates the updatable categories (status, dates, notes). It is clearly distinct from add_application and list_applications by name, though it does not explicitly state the distinction.

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?

No guidance on when to use this versus add_application, delete_entry, or proof_of_applications, and no prerequisites (e.g., needing an existing application_id) or exclusions. Usage must be inferred purely from the verb.

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?

The annotations already declare readOnlyHint=false and destructiveHint=false, and 'Update' is consistent with that, so no contradiction. The description adds the useful status vocabulary but never states partial-update semantics (whether omitted fields are preserved or cleared), nor any permission/auth requirements, which is the key behavioral fact for an 8-field mutation tool.

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: the action, the status options, and the notes capability are all stated without padding. Nothing is redundant with the schema or annotations.

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 no explanation. However, for a mutation tool with 8 parameters and only 25% schema coverage, the description leaves several fields and the partial-update behavior undescribed, making it adequate but incomplete.

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 only 25% (just notes and starts_at), so the description must compensate. It does add meaning for the status enum by glossing 'wahrgenommen' as attended, but leaves abgesagt/verlegt/versaeumt unmapped and says nothing about purpose, location, bring, or with_whom, so it only partially closes the gap.

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 clear verb+resource ('Update an appointment') and enumerates the concrete status transitions (attended, cancelled, rescheduled, missed) plus note-taking, which cleanly separates it from add_appointment and list_appointments. It falls short of 5 only because it omits the other updatable fields (location, purpose, starts_at, bring, with_whom) that the schema exposes, so it understates the tool's scope.

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 agent can infer this is for modifying an existing appointment rather than creating one. There is no explicit when-to-use/when-not-to-use guidance and no named alternative such as add_appointment or list_appointments.

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, destructiveHint=false, openWorldHint=false), so mutation semantics are declared. The description adds nothing beyond this: no replacement behavior (which the schema's 'Replaces the notes' implies), no permission/auth needs, no handling of unspecified fields. With annotations carrying the load, the description still earns little credit.

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 zero filler; the verb and resource lead. It is efficient, though the brevity reflects under-specification rather than tight editing, which is penalized in other dimensions.

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 7-parameter mutation tool at 29% schema coverage, one sentence is inadequate. An output schema exists, so return values needn't be explained, but the description omits replacement semantics, optional-field behavior, and parameter meaning that the agent needs to call it 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 only 29% (2 of 7 params described), so the description is expected to compensate but does not. It mentions no parameter by name or format; only the oblique 'Widerspruch' reference loosely relates to objection_status. Five parameters (subject, summary, file_path, reference, entry_id) remain undocumented in both places.

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 ('Update a correspondence entry'), which separates it from log_correspondence and list_correspondence. The 'e.g. mark that a Widerspruch has been filed' example clarifies the intended scope. It stops short of explicitly naming sibling alternatives, so it's clear but not fully differentiated.

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 example ('mark that a Widerspruch has been filed') implies a usage scenario, giving an agent a concrete cue. However, it never states when to use this versus log_correspondence (new entries) or delete_entry, nor any prerequisites. Usage is implied rather than specified.

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=false and openWorldHint=false, so the safety profile is covered. The description adds no behavioral context beyond that: no auth requirements, no reversibility, and notably no mention that an empty string deletes a field (that behavior lives only in the schema).

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 an inline field list; no wasted prose. The trailing ellipsis slightly undercuts the enumeration but keeps it short.

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, full param coverage and safety annotations, most needs are met. Still thin for a mutation tool: it doesn't clarify the destructive delete behavior in its own text or route the agent to get_profile first, leaving those to the schema.

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 nested 'fields' object documents the delete-on-empty-string semantics and the get_profile reference, so the schema does the heavy lifting. The description's inline examples (name, address, Kundennummer, benefit type...) add color but no syntax or format detail beyond it.

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 (set/change) and resource (profile fields) and enumerates the field domain, which is more than a restatement of the name. It does not explicitly distinguish itself from the sibling get_profile, though the schema points there.

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 verb: use this to modify an existing profile. There is no explicit when-to-use/when-not guidance, no prerequisite (e.g. login) and no mention of the read counterpart get_profile as a prerequisite step.

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