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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds a genuine behavioral disclosure not in the annotations: no medical suitability or quality ranking is inferred, and unknown/not_listed values require direct confirmation. That tells the agent what the tool will and won't conclude.

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

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

Front-loaded with the core purpose and very compact. The telegraphic phrasing ('Unknown/not_listed needs direct confirmation') is slightly cryptic, but no sentence 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?

An output schema exists, so return values need not be explained. The description covers the two semantics the schema cannot convey: how requirements combine and the non-inference disclaimer. The only real omission is require_approbation, which is undocumented everywhere.

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 67%, so baseline expectations are moderate. The description adds the combination logic (OR within a field, AND across fields) that the schema does not express, but require_approbation is undocumented in both the schema and the description, leaving a real 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+resource combination ('Compare profiles against explicit directory facts'), which clearly separates it from siblings like search_therapists or get_therapist. It doesn't name those siblings explicitly, so sibling differentiation is implied rather than stated.

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

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

The OR-within-field / AND-across-fields rule effectively tells the agent how to construct a comparison, which is real usage guidance. However, there is no explicit when-to-use-this vs. get_therapist/search_therapists statement and no stated prerequisites for the profiles input.

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 mutation. The description's 'removing it from the due list' usefully confirms the record is retained rather than deleted, but adds little beyond what destructiveHint=false already conveys — no reversibility, idempotency, or auth detail.

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. It is efficient, though the brevity is partly under-specification rather than pure 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?

An output schema exists, so return values need not be described. However, for a mutation tool with an entirely undocumented required identifier, the description is thinner than it should be — it never explains which contact's follow-up is affected or what 'resolved' changes beyond list membership.

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 contact_id is undocumented in both schema and description. The description never says whose follow-up is being completed or what form the identifier takes, 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 specific verb and resource ('Mark a recorded follow-up as resolved') and adds the resulting state change ('removing it from the due list'). It is clearly distinguishable from sibling mutation tools like log_contact or record_appointment, though it never names an alternative 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 explicit when-to-use or when-not-to-use guidance, no prerequisites, and no named alternative (e.g. log_contact for creating a follow-up vs. completing one). The only hint of context is the incidental mention of the 'due 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 already declare destructiveHint=true and openWorldHint=false, so the safety profile is known. The description adds genuinely new behavioral context: the deletion cascades to notes, drafts and contacts, and it does not touch the upstream therapie.de record. It still omits irreversibility and whether a confirmation or auth scope is required.

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

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

Two short sentences, zero filler, with the destructive cascade front-loaded ahead of the scope boundary. 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?

An output schema exists, so return values need not be described, and the destructive cascade plus local-only scope cover the main agent concerns for a deletion tool. The gap is the unexplained required identifier and the absence of any irreversibility or confirmation guidance.

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 the single parameter profile_id, so the schema carries no meaning at all. The description does not mention profile_id, its format, or where to obtain it (e.g., from get_therapist or the shortlist), leaving the only required input entirely unexplained.

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 (Delete) and resource (local saved therapist) plus the cascading scope (notes, drafts, contacts), and explicitly bounds it against the remote service. An agent can distinguish it from save_therapist and update_saved_therapist without opening any schema.

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

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

The scope sentence ('Does not affect therapie.de') implicitly tells the agent this is a local-only operation, which helps route between local and remote actions. However, it never states when to prefer update_saved_therapist over deletion, nor any prerequisite or confirmation step before an irreversible action.

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 non-destructive, non-open-world, additive behavior; the description adds meaningful context beyond that: the draft is editable, it 'does not send or log a contact' (distinguishing it from log_contact), and it pulls local sender/insurance preferences. Strong value-add, though it doesn't cover rate limits or what the draft object contains.

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

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

Four sentences, each earning its place, with the core purpose front-loaded. Slightly more could be trimmed, but every sentence conveys actionable constraint 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?

An output schema exists, so return values are documented elsewhere, and preconditions plus the no-send/no-log guarantee are captured. The one gap is parameter-level documentation for a 5-param tool, which is only partially compensated.

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 0% across 5 parameters, so the description must carry the load. It implicitly maps several ('saved therapist' for profile_id, 'follow-up drafts' for kind, 'health details' for additional_context, verified 'recipient'), but never explicitly explains kind/language enums or additional_context limits, leaving gaps it should have closed.

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 ('Create an editable email draft for a saved therapist') and clearly distinguishes itself from siblings like get_email_draft, update_email_draft, and export_email_draft via the creation verb and 'editable' qualifier. An agent can identify the operation 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?

Provides real preconditions: follow-up drafts require a recorded earlier enquiry, and a missing email requires a verified recipient. It also constrains input ('only include health details explicitly supplied'). It stops short of naming alternative siblings to route to, keeping it at a strong 4 rather than a 5.

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

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real value beyond them by clarifying that no booking or invitation is sent and that the file is private for manual import — a meaningful side-effect disclaimer for a read operation.

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

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

Two short sentences, zero filler, with the core action ('return a private .ics file') front-loaded and the side-effect disclaimer immediately after.

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 format need not be explained, and annotations carry the safety profile. For a single-param export tool the description is nearly complete, with the only gap being the appointment_id semantics.

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 the single required parameter appointment_id, and the description adds nothing about its format, source, or expected value. With one undocumented parameter, the description should have compensated 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?

States a specific verb and resource: 'Return a private .ics calendar file'. The 'export_appointment' name plus the .ics format clearly separates it from siblings like export_email_draft. It stops short of explicitly naming alternatives, so a 4 rather than 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?

Usage is implied rather than stated — the .ics-for-manual-import framing tells the agent the intent, and 'No booking or invitation is sent' rules out a misread, but there is no explicit when-to-use or when-to-prefer-a-sibling guidance.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and non-open-world behavior. The description adds genuinely useful side-effect boundaries: it produces .eml content and a mailto link but does not send or log a contact, which is meaningful context an agent could not derive from 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 tight sentences with zero filler. The primary output (.eml content and mailto link) is front-loaded, and the negative constraint follows immediately after.

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 enumerate return values, and it correctly focuses on the action and its side-effect limits. The only real gap is the absence of guidance on draft_id and on when to prefer this over the related get_email_draft/update_email_draft siblings.

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 never mentions draft_id or its expected format. With only one self-evident parameter the risk is low, so this is adequate rather than deficient, but no value is added beyond the schema.

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

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

The description states a specific verb and resource: it returns .eml file content plus a mailto link for the user's mail app. This is concrete enough for an agent to understand the export action. It stops short of explicitly contrasting with the sibling get_email_draft, so it is 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?

"Review and send there" implies the intended workflow (export, then send manually in a mail client), and it clarifies what the tool does not do. However, it never states when to choose this over get_email_draft or update_email_draft, leaving the sibling selection 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 destructiveHint=false, so safety is covered. The description adds beyond that by disclosing the return scope (full recipient, subject, body) and flagging that the draft is private/sensitive content, which matters for handling.

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 and returned fields front-loaded and zero padding. 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?

With an output schema present, return values need not be explained, and annotations carry the safety profile. Purpose, usage context, and sensitivity are covered; only draft_id semantics are 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 description coverage is 0% and the single required parameter (draft_id) is undocumented in both schema and description. The identifier is fairly self-evident, so this lands at the baseline rather than lower, but the description adds no format or scoping detail for 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 (Read) and resource (email draft) plus the exact fields returned (recipient, subject, body), which distinguishes it from update_email_draft and export_email_draft. An agent can tell what this fetches 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?

"before editing or exporting" gives a clear context that routes the agent to this tool ahead of the update/export siblings, effectively naming the adjacent workflows. It stops short of an explicit when-not or a named-alternative clause, so it is strong but not fully exhaustive.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description earns credit by adding a privacy guarantee not expressible in annotations: the data is private and local, and nothing is transmitted to therapie.de.

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 the action, the resource scope and the privacy caveat with zero filler. 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?

An output schema exists, so return values need no explanation, and annotations carry the safety profile. For a zero-parameter read tool the description supplies everything an agent needs 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?

The tool takes zero parameters, so per the baseline this scores 4. There is no parameter semantics to add meaning to, and the schema fully covers the empty argument object.

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 (Read) and resource (local sender/contact/search preferences), and the scope qualifiers 'private' and 'local' precisely bound what is being read. It is clearly separable from the sibling update_preferences, which performs the mutation counterpart.

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 implies the tool is used to inspect stored preferences before acting on them, but it never states when to call this versus update_preferences or how it relates to get_search_filters. No exclusions or prerequisites are given, so the agent must infer the usage 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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context beyond them: labels are in German, values come from a live external form (so they can change), and the filter taxonomy is enumerated. It stops short of auth or refresh/rate-limit 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 sentences, front-loaded with the verb and resource, and the enumeration is compact. The trailing list of filter categories is somewhat redundant given a full output schema exists, which slightly dilutes efficiency but the text is far from bloated.

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 complete output schema and full annotations, the definition need not restate return format or safety. What remains under-covered is routing guidance: an agent must infer that this is a prerequisite for search_therapists and that it differs from get_preferences. Otherwise it is complete for a no-arg 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?

There are zero parameters, so per the rubric the baseline is 4. Nothing in the description would need to document inputs, and it correctly spends no space on them.

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+resource ('Get current filter IDs and German labels') and names the authoritative source ('the actual therapie.de search form'), which also implicitly distinguishes it from get_preferences (user-supplied preferences) and the search siblings. It even enumerates the filter categories returned, so an agent knows exactly what this tool yields.

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 phrase 'current filter IDs ... from the actual search form' suggests an agent should call this to learn valid filter values before constructing a search, but the description never states when to call it, what it should be called before, or any alternative tool. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful scope detail about what is returned (profiles, notes, contact history), but says nothing about ordering, pagination, or volume. 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?

One front-loaded sentence that names the verb, resource, and the optional filter with zero filler. Appropriately sized for a simple read 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 structure need not be explained, and the annotations carry the safety profile. For a one-optional-param read tool the description is close to sufficient; only ordering/pagination and the null-status default are unaddressed.

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 'status' parameter is undocumented beyond its enum. The description confirms the filter dimension ('filtered by status') and that it is optional, but adds no semantics about how multiple statuses combine or what the default (null) returns. Baseline 3 for a light single-param filter.

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 a composite resource (saved profiles, local notes, contact history), so an agent knows this returns the user's shortlisted therapists with their associated context. It does not name or differentiate itself from siblings like list_appointments or search_therapists, so the 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?

'Optionally filtered by status' implies the retrieval use case, but there is no explicit when-to-use guidance and no mention of alternatives (e.g., list_appointments for a schedule view). Usage is only implied.

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, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. The description adds only that the profile is 'public' and lists which fields come back, which the output schema likely already carries – modest added value, no contradictions.

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 naming the resource and then the payload fields. Every clause earns its place and there is no filler.

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

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

For a one-parameter read operation with an output schema documenting return values and annotations documenting behavior, the description covers what an agent needs to select and call it. Only the absence of explicit sibling routing keeps it from a 5.

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?

One parameter at 100% schema description coverage, and the schema already explains the accepted formats (profile ID from search results or a therapie.de profil URL). The description contributes nothing about the parameter, 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 (Get) and resource (a therapist's public profile) and enumerates the content returned: contact, qualifications, billing, methods, focuses, availability. That is enough to distinguish it from search_therapists (list/discovery) and save_therapist (mutation), though it never names a sibling explicitly.

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

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

Usage is only implied: an agent infers this is the detail lookup you call after search_therapists surfaces a profile ID. There is no explicit when-to-use, when-not-to-use, or alternative named (e.g. compare_therapists for multi-profile comparison).

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds useful behavioral detail (chronological ordering, local data source), but omits a meaningful trait: the include_cancelled default of false means cancelled appointments are silently excluded unless requested.

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 scope and ordering front-loaded and no filler. It is not bloated, though it is arguably over-compressed given the undocumented parameters.

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 not be explained, and annotations cover the safety profile. What remains missing is parameter meaning and usage context, which for a two-parameter list tool leaves an agent under-informed about filtering 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 0% and the description says nothing about either parameter. It never explains that profile_id scopes results to a profile or that include_cancelled defaults to false, so an agent gets no semantic meaning for the two knobs it must reason about.

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 ... appointments') plus a distinguishing scope ('locally recorded') and ordering ('chronological order'). This separates it from siblings like record_appointment and update_appointment, though no sibling is named 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 guidance on when to use this versus alternatives, nor any mention of prerequisites or the natural pairing with record_appointment. The agent must infer that this is the read-side counterpart to the mutation 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 establish it is a non-read-only but non-destructive, non-open-world write. The description adds meaningful behavioral context: it must reflect a real contact rather than a fabricated send, and follow-up dates use YYYY-MM-DD. It does not add auth or idempotency details, but the annotations already carry the safety profile.

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 no filler, and the core action plus the critical misuse warning are front-loaded. 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?

Output schema and annotations cover return values and safety, so the description needn't explain those. It is still incomplete for a 6-param mutation tool: parameter meanings are unaddressed and sibling differentiation from record_appointment/complete_follow_up is ambiguous given the 'appointment' overlap.

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 6 parameters, so the description must compensate. It only specifies the format for follow_up_on (YYYY-MM-DD) and leaves profile_id, channel, outcome, notes, and occurred_on semantics entirely undocumented.

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: 'Record an actual contact/reply/appointment'. The exclusion clause ('Never use this to pretend a draft was sent') sharply distinguishes it from the draft-related siblings, so an agent can separate this from draft_enquiry/get_email_draft without opening schemas.

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

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

Provides an explicit negative usage rule ('Never use this to pretend a draft was sent'), which clearly routes the agent away from draft tools. However, it does not name the alternative tools or clarify when to prefer this over close siblings like record_appointment or complete_follow_up.

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; the description reinforces this by stating it records 'locally' and does not book or contact anyone, which tells the agent there are no external side effects. It also discloses the input contract for time (ISO local time plus IANA zone or explicit offset), which is behaviorally relevant. It stops short of saying what happens on duplicate or conflicting entries.

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, each carrying distinct information: purpose/scope first, then the time-format contract, then the exclusion. Nothing is padded and nothing important is 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?

An output schema exists, so return values need not be described, and annotations cover the safety profile. Still, for a 7-parameter write tool the definition leaves real gaps: which profile_id to pass, how the timezone parameter resolves against an offset in starts_at, and default title 'Termin' semantics are all unaddressed.

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 0%, so the description must compensate, and it only partially does: it clarifies the critical, non-obvious format of starts_at (ISO local time with either an IANA zone or an explicit offset). The other six parameters — including the required profile_id and the interaction between the separate timezone parameter (default Europe/Berlin) and an offset embedded in starts_at — are left entirely to the bare 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?

Names a specific verb and resource ('Record a ... appointment') and pins the scope with 'locally', which separates it from network-facing siblings like draft_enquiry or log_contact. It does not explicitly distinguish itself from update_appointment, list_appointments, or export_appointment, so an agent must infer the create-vs-modify-vs-list split.

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 'user-arranged appointment' implies the use case (the user already made the appointment; the tool just stores it) and 'Does not book/contact anyone' gives one clear exclusion. However, no sibling is named as the alternative for booking, editing, or listing, so the when-to-use-vs-what guidance is only implied.

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 the operation is non-destructive and not read-only, so the safety profile is covered. The description adds real value beyond that by disclosing merge semantics: existing notes/status survive the call unless notes are supplied. It omits permission/auth requirements and any mention that notes overwrite rather than append.

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, with the core action stated first and the preservation caveat second. Every clause carries information an agent needs.

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 merge behavior is covered. What is missing for a write-style shortlist operation is the identity/format of the required 'profile' argument and whether the call is idempotent on repeat saves.

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 parameter meaning. It does explain the effect of supplying 'notes' (overwrites the preserved value), but says nothing about 'profile' — whether it is a URL, slug, or opaque ID — which is the single required parameter.

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 concrete verb pair (fetch + save/refresh) and the target resource (the private shortlist), which separates it from a plain read such as get_therapist or search_therapists. It stops short of explicitly naming which sibling to prefer (e.g., update_saved_therapist for an already-saved entry), so it is 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 implicit use case is 'save a public profile into the shortlist', but there is no explicit statement of when to use this versus get_therapist, update_saved_therapist, or delete_saved_therapist, and no stated prerequisites. The merge rule hints at usage context but is not framed as 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 the safe read-only, idempotent, open-world profile, so the bar is lower. The description adds genuinely useful behavior beyond them: exactly one website page is returned per call, how to advance pages, and the caveat that reported availability is not a booking guarantee.

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 sentences, front-loaded with the core action and result contents, then filter sourcing, then pagination and the availability caveat. No filler or repetition.

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 the filter-value convention and pagination loop. Slightly thin on how radius interacts with location or on result ordering, but nothing an agent needs in order to call it correctly is missing.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the cross-cutting convention that filter parameters accept either an ID or an exact German label sourced from get_search_filters, which is the key non-obvious semantic for the eight filter params. It does not add anything for location, radius_km, or page beyond the schema.

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

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

States a specific verb and resource ('Search public therapist listings') plus what the result set contains (contact details, distances, source URLs, pagination). This clearly separates it from sibling retrieval tools like get_therapist, compare_therapists, and get_shortlist.

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 to get_search_filters for filter IDs/labels and explains the pagination protocol (one page per call, follow next_page_url). It gives clear context for use but names no explicit when-not-to-use case or alternative search path.

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 a non-read-only, non-destructive, non-open-world mutation. The description adds genuinely new context beyond that: the change is confined to a local record and no external party (the practice) is alerted. It still omits partial-update semantics (are omitted fields left unchanged?) and permission requirements, 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 short sentences with zero padding; the primary purpose is front-loaded and the caveat follows. 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?

An output schema exists so return values need no explanation, and annotations cover the safety profile. However, for a 7-parameter mutation with 0% schema coverage, the description does not tell the agent how the optional fields behave or what a successful update implies.

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 7 parameters, so the description carries the full burden and adds almost nothing: 'reschedule' faintly implies starts_at/duration, but status, notes, location, and timezone go unmentioned. Patch-style semantics (only appointment_id is required, everything else defaults to null) are never 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+resource ('update a local appointment record') and clarifies the operation is a local record change. It does not explicitly differentiate itself from siblings like record_appointment or list_appointments, which is the only reason 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?

No when-to-use guidance, no prerequisites (e.g., appointment must exist), and no alternatives named. 'Does not notify the practice' hints at the boundary between this and any notification/sync path, but that is inference, not stated 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=false, destructiveHint=false and openWorldHint=false, so the safety profile is largely covered. The description adds one genuinely non-annotated fact — that no email is dispatched — but says nothing about partial-update behavior (what happens to fields not passed, e.g. maxLength limits, whether omitted fields are cleared) or permission needs.

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

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

Two short sentences, zero filler, with the action and its field scope front-loaded before the reassurance about sending. 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 no explanation, and annotations cover the safety profile. For a mutation tool with 4 parameters and 0% schema coverage, the description is adequate but leaves gaps around draft_id, partial-update semantics, and length limits.

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 parameter meaning. It names three of the four parameters (recipient, subject, body) and their role, which is real added value, but omits draft_id entirely and gives no format/length or null/default semantics for the rest.

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 verb and resource ('Edit a draft') and enumerates the editable fields (recipient, subject, body), which cleanly separates it from get_email_draft and export_email_draft. It stops short of naming any sibling or drawing an explicit boundary with draft_enquiry, so it is 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?

'Nothing is sent' implies this is the staging/edit path rather than a send path, which is useful when-to-use context. However, it never states when to prefer this over draft_enquiry or get_email_draft, nor any prerequisites (e.g. draft must already exist), leaving usage only implied.

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=false and openWorldHint=false, so the safety profile is covered. The description adds genuine behavioral value beyond that by disclosing that the store is 'local' and that passing null removes a field, which is non-obvious mutation semantics.

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 the field inventory and the null convention front-loaded; nothing is padded. Slightly telegraphic wording ('local') leaves minor ambiguity.

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 null-removal is covered. However, for a mutation tool it omits whether omitted fields are left unchanged (merge vs replace), persistence scope, and any permission requirements.

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 0% and the schema is an opaque additionalProperties map, so the description carries the full burden. It names the allowed keys and explains the null-means-remove convention, substantially compensating for the gap, though value formats/types are still unspecified.

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 (save) plus the resource (local preferences) and enumerates the concrete fields, so an agent knows exactly what gets written. It is distinguishable from get_preferences by the read/write verb, though it never names that counterpart.

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 mention of get_preferences as the read alternative or update_saved_therapist/update_appointment as siblings that also mutate. The agent must infer the invocation 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 openWorldHint=false and destructiveHint=false, so 'without contacting the therapist' largely restates the structured signal that no external side effect occurs. The description adds nothing about partial-update behavior, whether null notes/status clears a field, or what the write returns.

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 the action, the target data, and the key boundary condition with 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 so return values need not be explained, but for a mutation tool with 0% parameter documentation the description leaves null-handling and partial-update semantics unspecified. Adequate, not 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%, so the description must carry parameter meaning; it names 'notes/status' (two of three params) but says nothing about profile_id or about how null values are interpreted for either field. Partial compensation for a 3-parameter 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 gives a specific verb (update) and resource (the user's local shortlist notes/status) and scopes it as local-only, which separates it from write-heavy siblings like save_therapist and delete_saved_therapist. It does not name an alternative sibling outright, 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?

Usage is implied rather than stated: the phrase 'without contacting the therapist' hints that contact-logging tools (log_contact, draft_enquiry) are the wrong choice for note/status bookkeeping. There is no explicit when-to-use or when-not-to-use rule.

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

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

Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuinely useful context beyond that: the data is local and 'nothing is sent to the directory,' confirming no external side effects. It does not discuss freshness or scope limits of the summary.

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

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

Two short sentences, zero waste, with the content enumeration front-loaded and the side-effect caveat second. 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?

With an output schema present, return-shape detail is unnecessary, and the rich annotations plus the privacy statement cover the behavioral gap. The only shortfall is that the description doesn't clarify how this aggregate relates to the narrower sibling getters, which matters for routing in a 20-tool set.

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 no parameter semantics to explain — this earns the baseline of 4. Nothing in the description contradicts or confuses the empty schema.

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

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

States a specific verb ('Show') and enumerates the resources aggregated: local preferences, saved therapists, drafts, and due follow-ups. This distinguishes it as a composite overview rather than a single-resource getter, though it never explicitly contrasts itself with siblings like get_preferences or list_appointments.

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 by the aggregate framing — an agent can infer this is a starting-point summary, but no when-to-use, when-not-to-use, or named alternatives are given. The closing privacy note is not usage guidance.

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