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

No annotations exist, so the description carries the full burden and does so well: it names the three distinct Infarmed datasets queried, states that latest versions are found automatically, enumerates the possible status values, and warns that a negative result is not proof of availability. It omits operational traits such as authentication, rate limits, or latency, 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?

Front-loaded with a one-line statement of what it answers, followed by usage triggers, then the enumerated data sources. The trailing Args block largely restates the schema, and the three-bullet source list is dense, but each element carries genuine information for the caller.

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 two-parameter lookup with an output schema present, the description supplies everything needed: data provenance, the meaning of every possible status value, the caveat about false negatives, and input formatting guidance. No behavioural or interpretive gap remains for an agent deciding whether to trust a negative result.

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 description fully compensates: 'medicine' is explained as brand or active substance with optional strength/form, with concrete Portuguese examples ("quetiapina", "Ozempic", "ácido acetilsalicílico") and a narrowing example. 'limit' is clarified as max rows per list with its default, which is more precise than the bare integer 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: answers whether a medicine is in shortage in Portugal, sourced from Infarmed. The opening question form plus the explicit source make it immediately distinguishable from siblings like find_medicine_near and pharmacies, which address where to obtain a medicine rather than whether it is in shortage.

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

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

Gives concrete trigger conditions ("Use when someone can't find a medicine, or asks whether X is in shortage") including the Portuguese keywords users actually type. It also sets expectations about coverage ("No issue" does not prove availability; the full shortage search is not queried). It does not explicitly name a sibling as the alternative when this tool is the wrong choice, so it stops short of a 5.

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

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

With no annotations supplied, the description carries the burden and does it well: it discloses exactly what is returned (shortage status, on-duty and currently-open pharmacies, help lines Linha 1400/SNS 24/112, next steps) and a critical behavioral caveat — it never asserts a pharmacy has the medicine because stock is not public. It omits any note on auth, rate limits, or failure behavior for unknown cities.

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 question it answers, then the internal composition, then the return payload, then a clean Args block — a logical order with no filler sentences. Slightly verbose in the returns enumeration, but every clause conveys usable information.

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

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

For a five-parameter composite tool with an output schema, the description covers inputs, upstream sources, return contents, and the key limitation on what it can claim about stock. An agent has everything needed to select and invoke it correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: all five parameters are explained with examples (medicine as brand name or active substance, e.g. "quetiapina"/"Brufen 400"; city as municipality; lat/lon as optional position that triggers distance sorting; limit as max pharmacies with default 8). The city-vs-lat/lon substitution rule adds meaning the schema cannot express.

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 user question it answers and explicitly names the two underlying operations it wraps (availability and pharmacies), so an agent can see it is a composite orchestrator rather than a primitive. The resource (medicine availability + pharmacy locations in Portugal) is unambiguous.

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

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

The framing "One-shot answer to 'I need medicine X in city Y — what do I do?'" gives clear usage context, and the Args section explicitly says to supply city OR lat/lon. It stops short of explicitly telling the agent to prefer this over calling availability and pharmacies separately, though that is strongly implied by listing them as internal steps.

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

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

With no annotations, the description carries the full burden and does so: it discloses the returned fields, the sort order (on-duty, then open-now, then distance), the duty-day boundary definition (09:00–09:00), that on_duty comes from an official roster, and the lat/lon-without-city fallback behavior. These are non-obvious traits an agent could not infer from the schema.

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

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

Front-loaded with purpose, then uses cases, then return shape and caveat, then args — a sensible order with no filler. The Args block is long but justified at 0% schema coverage; minor duplication with the earlier field list is the only waste.

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 optional-everything seven-parameter tool with no annotations and no schema descriptions still leaves no ambiguity: all params, their interactions, the sort order, and the correctness caveat about stock are covered. The output schema means the return-value enumeration is a bonus rather than a necessity.

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 is the sole documentation and it fully compensates: every one of the seven parameters is explained, city includes disambiguation examples, radius_km is tied to lat/lon availability, and limit states the default 20 / max 100. The dependency rules (radius requires position) are stated explicitly.

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

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

Opens with a specific verb+resource+scope: pharmacies within a Portuguese municipality, with duty status and open-now status. It is clearly distinguishable from stock-oriented siblings (medicine_availability, find_medicine_near) because it explicitly states stock is not public.

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

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

Gives concrete trigger phrases ("farmácia de serviço em X", "pharmacy open now near me", "list pharmacies to call") and an explicit when-not: never claim a pharmacy stocks a medicine. That exclusion routes the agent away from the wrong use without needing the sibling 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?

With no annotations, the description carries the behavioral burden. It usefully states that the lines are verified and include source-checking details and hours where published, but it does not explicitly describe the operation as static/read-only or clarify freshness guarantees beyond the word 'verified'.

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

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

The description is compact and front-loaded: it first states the resource and covered lines, then the use cases, then the returned detail. Every sentence contributes without 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 zero-parameter informational tool with an output schema, the description provides enough context about purpose, activation scenarios, and record contents. A minor gap is the absence of explicit sibling routing or exclusions, but the core task is clear.

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

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

The tool has zero parameters, so the baseline is 4. There are no parameter semantics to explain, and the description does not need to compensate for an input 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 clearly identifies the resource as verified medicine help lines in Portugal and names the specific lines covered. It is readily distinguishable from siblings like find_medicine_near and pharmacies, though it uses a noun phrase rather than an explicit verb such as 'list' or 'return'.

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 gives explicit usage contexts: when someone cannot find a medicine, needs urgent advice, or asks who to call. It does not name alternatives or state when not to use this tool versus find_medicine_near, availability, or pharmacies.

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