GLØDI

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

Annotations already declare readOnly, idempotent, closed-world, so safety is covered and the description correctly spends its words on content instead: it discloses that the response is an index of public pages with counts and slug-bearing taxonomies. It omits any note on response size or whether every section is always present, which keeps it from 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?

A single dense sentence that front-loads the payload inventory, with the secondary sections (contact facts, glodi.no plans) trailing correctly. It is efficient, though the stacked parentheticals and the fragment 'The map of everything public here' cost some readability.

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 no-required-parameter browse tool with an output schema and full safety annotations, the description covers the substantive question of what content the browse surfaces. Nothing critical is missing, though a hint about when to prefer it over read_public_page would close the loop.

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 one optional parameter (locale) and schema coverage is 100%, so the schema already fully documents it, including the enum. The description does not reference locale or the answer language at all, so it adds nothing beyond structured data — the baseline 3 for high coverage 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 precisely what the tool returns: a site map of public list pages with counts, plus treatment categories, body areas and skin concerns with slugs, contact facts, and GLØDI clinic plans. That is a specific resource with enumerated contents, though no verb is used and the siblings (read_public_page, search_treatments, get_treatment) are never named for contrast.

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 'for vague needs ("pigmentering", "acne")' gives one concrete when-to-use signal, implying a discovery entry point before narrower lookups. However no alternative tool is named and no when-not condition is stated, so the agent must infer that find_clinics / search_treatments are for already-known targets.

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, idempotent, non-destructive behavior. The description adds useful context beyond that: results are sorted nearest first, include phone channels, hours, open status, rating, and price when treatment_id is used.

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 with no waste. Purpose and ordering come first, followed by returned fields and accepted inputs, making the definition easy to scan.

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

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

Given 10 parameters, an output schema, and read-only annotations, the description covers the core purpose, key inputs, and return contents. It omits pagination and some filter semantics, but the schema and output schema fill those 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 80%, so most parameter meaning is already in structured fields. The description adds some value by explaining the near/place alternative and treatment_id's price output, but it does not clarify other parameters like page, radius_km, open_on, or open_now.

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 (find clinics) with clear scope: near a place, in a town, or by name, nearest first. It also previews returned fields. It does not explicitly differentiate itself from siblings like get_clinic or find_practitioners, 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?

It explains that you should give near or place and that treatment_id narrows to clinics offering that treatment now. However, it gives no explicit when-to-use versus alternatives (e.g., get_clinic for a single clinic) and no when-not 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, so the safety bar is covered. The description adds genuine behavioral context beyond that: the 60-day cap, the 'three nearest clinics' fallback around near/place, and the fact that no free day yields a waitlist_url. It stops short of describing result ordering or pagination.

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 dense sentences with no filler, and the core resource/scoping information is front-loaded. The grammar is telegraphic ('Which days have a free time'), which is efficient but slightly harder to parse.

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 9 parameters, nested objects, and an output schema present, the description covers the key constraints an agent needs (option_id anchor, scope of clinics, practitioner choice, waitlist fallback). Return format needn't be explained since an output schema exists. Minor gaps in ordering/pagination keep 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?

Schema description coverage is 100%, so the required baseline is 3. The description restates a few parameter relationships (three nearest clinics, add_on_ids lengthening the visit) that the schema already documents, adding little new semantic meaning beyond what structured fields provide.

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 resource (days with free time) tied to a specific option_id, and adds scope detail (clinic_id / three nearest clinics, one practitioner or anyone). It clearly conveys what the tool returns, but it never names or contrasts with the obvious sibling find_free_times, leaving the day-vs-time distinction 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?

It provides usage conditions (up to 60 days, clinic_id OR three nearest to near/place, practitioner_id vs anyone), which is more than nothing. But it gives no explicit 'use this instead of find_free_times' routing and no exclusion guidance, so usage is implied rather than directed.

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, closed-world. The description adds genuinely useful behavior beyond that: a time is not held until the person books it, and every result carries a booking_url that opens a prefilled lightbox. That holding/booking semantics is real added value not in the annotations.

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

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

Three sentences, front-loaded with the core capability, followed by return-content and booking-semantics details. Every sentence is relevant, though the lightbox mechanics sentence is slightly verbose.

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

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

With an output schema present and full schema coverage, the description needn't explain return values, yet it still summarizes them (practitioners, prices, booking_url). Combined with the holding caveat, an agent has enough to call it correctly; only explicit sibling routing 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% with rich per-parameter descriptions (including provenance hints like 'option_id get_treatment returns'). The description only restates option_id, clinic_id, and the 7-day cap, so it adds little beyond the fully documented schema – 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?

States a specific verb (find) and resource (free times) with clear scope: one option_id at a clinic, single date or up to 7 days. It distinguishes the resource from find_free_days and find_practitioners by clarifying it returns times plus practitioners and prices, 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?

Usage is implied through the parameters (clinic_id, option_id) and the note that clinic_id comes from find_clinics, but there is no explicit when-to-use/when-not guidance nor a named alternative such as find_free_days for day-level availability.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds the useful behavioral detail that results are availability-scoped ('booked now') and include associated clinics, but it does not mention pagination or result-size limits.

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

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

Two sentences with no waste: the core behavior is front-loaded, followed immediately by the alternative-tool routing. Nothing could be removed without losing selection-relevant information.

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

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

With an output schema present, return values need not be explained, and annotations carry the safety profile. The description covers purpose, availability scoping, and the key alternative, though it leaves paging behavior and some parameter semantics 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 description coverage is only 60%, so the description should compensate but mostly repeats the query constraint ('at least two letters') already documented in the schema. It says nothing about page, page_size, clinic_id, or locale semantics beyond what the schema provides.

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 ('Find a practitioner by name') and adds scope ('the clinics where each can be booked now'), which distinguishes it from get_booking_choices. An agent can identify the tool's job 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?

Explicitly routes treatment-option lookups with prices to get_booking_choices, naming the alternative and the condition that selects it. It does not state exclusions (e.g., when to use find_clinics instead), so it falls short of full when/when-not 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 closed-world, so the safety profile is covered. The description adds the mode-dependent shape of the result, but says nothing about auth needs, empty-result behavior, pagination, or why near beats place. With annotations carrying the load, 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 sentences, front-loaded with the scope and then the two conditional branches; little waste. Minor deduction for the undefined term 'booking lightbox', which assumes domain context an agent may not have.

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, the return values do not need spelling out, yet the description still sketches each mode's payload, which aids selection. What is missing is edge-case behavior (option with no bookable clinics, invalid option_id) — modest gaps for an otherwise well-specified 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?

Schema coverage is 100%, so all five parameters including the nested near/place pair are documented in the schema. The description adds real semantics for clinic_id by explaining that it changes the result set from clinics to practitioners, but contributes nothing for near, place, or locale. Baseline 3 holds.

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 (the booking choices for one option_id) and splits the result into two clearly scoped modes. An agent can distinguish it from get_treatment (upstream option data) and find_practitioners (a flat practitioner search) without opening the schema. It loses a point only because the head phrase is a noun clause rather than a verb+resource statement.

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 'Without a clinic... With clinic_id...' phrasing gives implicit guidance on when to pass clinic_id, which is genuinely useful. However, it never names alternatives (find_practitioners, find_clinics, get_treatment) or states when not to call it, so routing still requires inference from sibling names.

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, closed-world behavior, so the safety profile is covered. The description adds value by scoping exactly what content is returned, but says nothing about behavior when clinic_id is omitted (site context) or when an id is invalid/unknown.

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 ('One clinic's facts:') followed by a compact enumeration. Every listed item signals retrievable data, though the long run-on list could be grouped more scannably.

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 re-explained, and annotations cover the safety profile; the description's content inventory is a helpful supplement. The remaining gap is selection guidance relative to find_clinics and the fact that clinic_id is optional, which an agent must infer from 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%, so both parameters (locale enum with default, clinic_id with the find_clinics warning) are fully documented in the schema. The description adds no parameter meaning of its own, which is the baseline case 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 a specific resource (one clinic) and enumerates the concrete facts it returns — address, phones, opening hours, parking, team, prices, offers, payment methods. That is clearly distinguishable from list/search siblings such as find_clinics or list_offers. It stops short of explicitly contrasting itself with those siblings, which keeps it at 4.

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: nothing says to call find_clinics first to obtain the id, or that this is the detail lookup after a search. The one useful routing hint ('The clinic_id find_clinics returns... A clinic site needs none') lives only in the schema, not the description.

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 one genuinely new behavioral guarantee ('Every option has a booking_url') and the payload breadth, but says nothing about missing/invalid treatment_id behavior or how location inputs change the returned clinics and reviews.

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, front-loaded with the resource, with no filler. It is list-like but every clause names a distinct section of the payload, so little could be cut without losing 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 the lengthy return-value enumeration is largely redundant, while the genuinely ambiguous behavior — whether clinic_id/near/place filter the clinics list and reviews, and whether they affect the option list — goes unaddressed for a 5-parameter tool with a nested object.

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

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

Schema description coverage is 100%, so the schema already documents near, place, locale, clinic_id and treatment_id, including 'near wins over place'. The description mentions option_id, price and booking_url, but those are response fields rather than inputs, so it contributes little input-side meaning 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 title supplies the verb ('Get one treatment') and the description enumerates exactly what the single-treatment payload contains (procedure, recovery, sessions, options, clinics, reviews). This clearly separates it from search_treatments and get_clinic, though the description itself never names 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?

Use is only implied: you fetch a treatment you already have an id for. It never says when to call this instead of search_treatments (which presumably also returns treatment data) or list_offers, and it gives no condition for supplying near/place vs clinic_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, non-destructive and closed-world, so the safety profile needs no restatement. The description adds useful content context about what each row surfaces, but says nothing about pagination limits, whether event_id mode ignores filters, or default date behavior beyond what the schema carries.

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 listing scope before the single-event mode, and no filler. The compressed phrasing ('Upcoming arrangements and courses, GLØDI's own and the clinics'') borders on cryptic but stays efficient.

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 little explanation, and the description dutifully covers them. For a seven-parameter tool with pagination and a mode switch, it leaves real gaps: no guidance on page_size behavior, no statement of how event_id interacts with type/date/clinic filters.

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 71%, so most parameters are already documented. The description does add meaning to event_id beyond the schema's brief 'One event with its program' by promising prerequisites and price tiers, but page/page_size, type, locale and from_date get no treatment, and how filters combine in event_id mode is unstated.

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 and enumerates what the listing carries (sessions, seats left, price from, registration state), plus a second mode where event_id reads a single event with program, prerequisites and price tiers. It distinguishes listing from single-read within the same tool, though it never states an explicit verb or names a sibling such as list_offers or search_treatments, so differentiation from siblings is left 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 phrase 'event_id reads one event with its program...' implies a mode switch and is the only usage cue given. There is no statement of when to prefer this tool over list_offers or search_treatments, and no exclusions or prerequisites beyond what the schema already says about clinic_id coming from find_clinics.

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, openWorldHint=false, so safety is covered. The description adds that only 'live' offers appear and that validity windows are included, which is useful behavioral context, but says nothing about pagination or how page/page_size interact. With annotations doing the heavy lifting, this lands at an adequate 3.

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 stating the resource, its payload, and the filter/mode options, with no padding. It is dense enough that the pagination story is squeezed out, but 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?

An output schema exists, so return shape needn't be re-explained, and the description still summarizes the key fields. For a 7-param, none-required read tool the main gap is pagination behavior and locale handling, which is a modest omission rather than a blocking one.

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 71%, so the schema already documents locale, clinic_id, item_slug, item_type and offer_id. The description restates the same filter names without adding format or semantics, and it omits page/page_size entirely (the undocumented ones in 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+resource ('The live offers (campaigns)') and clarifies the payload (each treatment or product, price before/after, validity). It also disambiguates the dual mode by noting 'offer_id reads one offer', separating list from single-fetch. It stops short of distinguishing itself from siblings like search_treatments or search_products.

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 filter set (clinic_id, item_type, item_slug) and the offer_id single-read path imply when to use it, but there is no explicit when-not or comparison to sibling search/browse tools. An agent must infer that this is for live pricing rather than catalogue discovery.

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 safety is covered. The description adds that only *published* reviews are returned, which is real behavioral context, but says nothing about pagination behavior, default result size, or what happens when multiple filters are combined.

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 sentence with no filler, and the returned content is front-loaded before the scoping clause. Efficient, though the parenthetical could be tightened.

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-shape explanation is unnecessary, and the description covers what is returned and how to scope it. The remaining gap is the absence of pagination and filter-combination behavior for an 8-parameter, zero-required 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 50%, and the description names four of the eight parameters (clinic_id, practitioner, treatment_id, product_id) and frames them as alternative scopes, which is meaning beyond the schema. It says nothing about page/page_size or how rating interacts with the scope filters.

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 the resource (published reviews plus an aggregate summary of average, count and distribution) and the four scoping dimensions. It is clear what the tool returns, though it never uses an explicit verb like 'list' and doesn't name a contrasting sibling.

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 'for one clinic_id, practitioner, treatment_id or product_id' hints that these are mutually exclusive scoping options, which is genuinely useful. However, it gives no when-to-use/when-not guidance, no mention of what happens with no filter at all, and no reference to any alternative 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?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is fully carried by structured fields. The description adds only that output includes typed data keyed to page types, which is largely return-value information duplicated by the existing output schema; nothing extra on permissions, 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 with zero preamble, though the trailing page-type enumeration makes it dense. It earns most of its length but the long parenthetical could be trimmed.

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

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

With an output schema present and both parameters documented, the description need only convey purpose and scope, which it does. The remaining gap is the lack of differentiation from browse_site, a sibling with overlapping intent.

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 fully documented in the schema, and the description adds no format or constraint details beyond it. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb ('Read') and resource ('one public page') and enumerates the content returned (text sections, links, schema.org facts, typed data) plus the supported page types. It is clearly distinct from search/list siblings, though it never names the closest alternative, browse_site, which an agent must disambiguate 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?

'Normally a URL another answer returned' gives a usable trigger condition for when to reach for this tool. However, there is no when-not guidance and no mention of browse_site, the obvious sibling alternative, so the usage boundary 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 read-only, idempotent, closed-world profile, so the bar is lower. The description adds real behavioral context beyond them: two distinct data sources and the fact that product_id returns rich detail (description, sellers, subscriptions, treatments, reviews). Pagination behavior is not mentioned, keeping it from 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 with the resource and its scope front-loaded, then the product_id detail mode. Slightly compressed but no wasted clauses.

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 still previews the product_id payload. For a 9-parameter, no-required-args search tool it covers modes and scope adequately; only pagination/limits are absent, and those are in 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 78%, so baseline is 3; the description adds value by explaining that product_id yields a full product record with sellers and related entities, which the schema only summarizes as 'One product with its sellers.' Brand/category/in_stock filtering is confirmed but not elaborated.

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

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

Specific verb (search) and resource (skincare/retail products) with scope: GLØDI's marketplace plus individual clinic shops. It also clarifies the dual mode (filter-list vs single product read via product_id). It does not name a sibling tool, so it stops short of 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?

Filtering dimensions (brand, category, stock) are stated, implying when this tool applies, but there is no explicit contrast with search_treatments, get_treatment, or browse_site. The choice between marketplace vs clinic context is left to the schema's clinic_id note rather than the description.

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 read-only/idempotent safety. The description adds valuable behavior beyond that: bilingual matching with fuzzy/compound handling, default exclusion of unbookable treatments, the result field set (price from-to, offer price, duration, clinic count, nearest clinics with near/place), and fallback suggestions on no match.

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 dense sentences, front-loaded with what the tool does and its differentiating search behavior. Slightly compressed (result field list is a run-on), but 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?

For a 13-param, 0-required search tool with an output schema, the description covers search semantics, filter sources, exclusion defaults, and the no-match path. Output schema covers returns; minor gaps around pagination behavior are acceptable.

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 85%, so the schema carries most parameter docs. The description nonetheless adds meaning: filters are category/body_area/skin_concern sourced from browse_site, and near/place enrich results with nearest clinics. Adds moderate value over schema.

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

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

States a specific verb+resource (search treatments) with distinguishing traits: bilingual search with typo and compound-word handling. This clearly separates it from browse_site (which lists categories) and get_treatment (single item lookup).

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?

Explains when results are excluded (unbookable unless include_unbookable) and where filter slugs come from (browse_site), and covers the no-match path. Lacks explicit guidance on when to use find_clinics or get_treatment instead, but usage context is clear.

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