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

With no annotations, the description carries the full burden and does well: it discloses data provenance and staleness ('official monthly statistics, latest month usually 2-3 months back, provisional'), aggregation limits, and the institution-to-ULS remapping side effect of the institution argument. It does not explicitly state read-only/safe semantics or pagination/size limits, which is the remaining gap for a zero-annotation tool.

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

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

Purpose and metric come first, then usage triggers, caveats, and an Args block — a sensible front-loaded order with no filler sentences. It is somewhat dense with unexplained domain acronyms (CTH/SIGA, TMRG) and the terse return-field notation in the middle paragraph is compact to the point of being cryptic.

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, yet the description still sketches the returned shape (consultations_in_month / _year_to_date broken out by total, first, subsequent, plus the within-max-time percentage) and adds the data-freshness caveat an agent needs to interpret it. Nothing needed to call this correctly is missing.

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

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

Schema description coverage is 0%, so the description must compensate, and it fully does: institution is described with its ULS mapping behavior, region with its five accepted values and the explicit 'ignored if institution is given' rule, period with its YYYY-MM format and default, and months with its default and max of 24.

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 opening sentence names the specific resource (hospital outpatient consultations per month) and the key derived metric (% of first consultations within the guaranteed maximum time). It is clearly distinct from the sibling wait/emergency tools by resource and metric, so an agent can disambiguate 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?

It supplies concrete trigger questions ('how long is the wait for a first hospital appointment at X?') and states a real limitation (no breakdown by specialty in the open data) plus the institution-vs-region precedence rule. Defaults and the -2/-3 month latency expectation are given, leaving little to infer.

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?

No annotations exist, so the description carries the full burden and does so: it warns the latest month is usually 2-3 months back and provisional, explains the institution→ULS mapping and the `scope` field to verify it, and documents default/max behaviour for period and months. Those are the traits that actually change how an agent interprets and presents results.

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 example queries, then scope, then args — a good ordering with no filler sentences. It is on the long side, and the emergency-contacts disclaimer (112 / SNS 24) is an emergency-response message that contributes little to tool selection or invocation.

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 0-required-param statistics tool with an output schema, the definition covers everything that remains open: geographic scope semantics, time-window semantics, freshness caveats, and what the returned fields mean (visit types, triage colours and their clinical meanings, share percentages). Nothing needed to call it correctly is missing.

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

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

Schema coverage is 0%, and the description fully compensates: it gives the accepted region vocabulary (Norte | Centro | LVT (Lisboa) | Alentejo | Algarve), states region is ignored when institution is supplied, defines period as 'YYYY-MM' with newest-available default, and gives months default 6 / max 24 plus accent-insensitive institution examples. This exceeds what the bare schema conveys.

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

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

States a specific resource and breakdown precisely: monthly emergency-department visits by visit type and by Manchester triage colour. It also contrasts itself with the nearest confusable thing (live queue / waiting-time tools) and with the sibling wait-stats family, so the agent can pick it without opening the schema.

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

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

Gives concrete trigger phrasings ('how busy is the ER at X?', 'how many emergency visits in the Algarve last month?'), states an explicit when-not ('OFFICIAL MONTHLY STATISTICS ONLY — not the live queue'), and routes the out-of-scope case to https://tempos.min-saude.pt. The exclusion plus redirect is exactly what an agent needs.

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 behavioral burden and does so: it discloses the exact result fields, the caveat that statistics are per ULS/group rather than per building, the non-obvious rule that umbrella ULS entries are skipped when only lat/lon is given, and that live wait times are out of scope.

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-loads the purpose and the when-to-use rule before the result shape and an Args block, so an agent can stop reading early. Slightly long, and the result-shape sentence overlaps with the existing output schema, but nothing is wasted 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?

Covers purpose, ordering relative to siblings, all parameters, result contents, and the important domain caveat that stats attach to ULS/groups. An output schema exists, so the brief return summary is bonus rather than a gap.

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

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

Schema description coverage is 0%, so the description must compensate, and it does for all five parameters: query is accent-insensitive with examples, lat/lon are WGS84 with a worked example and a behavioral side effect, emergency_only is defined as 'only places that report emergency-department data', and limit gives default and max.

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 SNS hospitals / local health units (ULS)') with both lookup modes — by name or by proximity to a coordinate. It is clearly distinguishable from the sibling *_stats tools, which it explicitly routes to rather than duplicating.

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

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

Gives explicit sequencing: 'Use this first when the user names a hospital or a place', with two concrete example queries, then instructs passing `stats_entity` into emergency_stats / surgery_wait_stats / consultation_wait_stats. It also states an exclusion — no live waiting times, send the user to the external URL instead.

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 whole burden and does substantial work: it discloses the YTD-cumulative semantics of the `tempo` field (December = annual total, single month = delta), which is a genuine data-shape trap an agent would otherwise fall into. It also states limits (default 20, max 100) and that this is official statistics, not live data. It stops short of stating read-only/safety or error behavior explicitly, keeping it just below 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 purpose and use-condition, then clause reference, then args — good ordering with no repetition of the schema. The clause examples are long but each demonstrates syntax the schema cannot express; the leftover argparse-style 'Args:' block is mildly redundant given the schema fields exist.

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 exists, so return-format explanation is unnecessary; the description instead supplies what the schema can't — query language semantics, dataset discovery path, field conventions (`tempo`, `regiao`, `instituicao`/`entidade`), and the cumulative-value caveat. Nothing essential for a correct call is missing.

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

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

Schema description coverage is 0%, so the description must compensate entirely, and it does: each ODSQL clause gets a concrete example (`instituicao like "santa maria" and tempo >= date'2026-01-01'`) including the non-obvious case/accent-insensitive `like` and date literal syntax, plus aggregate form for select. limit/offset/dataset_id semantics and paging purpose are all spelled out.

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 — 'Run an ODSQL query on any SNS Transparency portal dataset' — and names the API behind it (Opendatasoft Explore API v2.1). It also distinguishes itself from the curated siblings ('anything the curated tools don't cover'), so an agent can route correctly without opening other 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?

'Use after search_datasets for anything the curated tools don't cover' gives an explicit precondition plus the alternative tools it supersedes. The dataset_id arg reinforces the ordering by pointing back to search_datasets as the discovery step.

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 well: it discloses Portuguese-language content, accent-insensitive matching, empty-query behavior, and that limit is ignored when listing all datasets. It could still state explicitly that this is a read-only search with no side effects, but the behavior is otherwise well explained.

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 front-loaded with purpose and usage, then gives concrete example keywords and parameter semantics. Although longer than a minimal description, every section earns its place because the schema itself has no parameter descriptions.

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 details are not required. The description still explains the search scope, language behavior, empty-query listing behavior, limit semantics, and the follow-up query_dataset call, making it complete for an agent to use 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: query is explained as Portuguese keywords with examples and an empty value listing all datasets; limit is explained with default 10, max 50, and ignored-when-listing-all behavior. This adds substantial meaning beyond 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?

States a specific verb and resource: search the SNS Transparency portal's ~150 datasets. It clearly distinguishes itself from curated siblings by saying to use it when curated tools do not cover the question, and it names query_dataset as the follow-up step.

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 defines when to use this tool versus the curated alternatives: when the curated tools do not cover the question, with concrete example domains such as hospital bed occupancy, births, INEM calls, and medicines spending. It also states the next action: call query_dataset with the returned dataset_id and field 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?

With no annotations, the description carries the behavioral burden and does well: it discloses that the data are official monthly statistics, usually 2-3 months behind, provisional, and lacking specialty/procedure breakdown. It also defines key metrics such as TMRG and clarifies that mean days before surgery is not waiting-list time. It does not explicitly state read-only/access constraints, but the statistical nature makes that largely inferable.

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 long but well-structured and front-loaded: purpose and use cases first, then metric definitions, then argument semantics. Given the complexity of the indicators and the lack of schema descriptions, every section earns its place.

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

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

An output schema exists, so return values need not be explained in the description. The description covers data vintage, provisional status, metric definitions, limitations, and all four parameters, leaving an agent with enough context to call the tool correctly.

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

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

Schema description coverage is 0%, so the description must compensate, and it does: institution examples and ULS mapping, region enum values with the rule that region is ignored when institution is given, period format/default, and months default/max are all documented. This adds substantial meaning beyond the bare schema types and defaults.

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 and metric set: monthly surgery access indicators including waiting list, TMRG compliance, mean days to surgery, and surgeries performed. It is clearly distinguishable from siblings such as emergency_stats and consultation_wait_stats by its surgery-specific scope.

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

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

It gives explicit example questions ("how long is the wait for surgery at X?", "how many operations did hospital Y do?") and a clear limitation about no specialty/procedure breakdown. It would be stronger if it explicitly named alternatives such as consultation_wait_stats for consultation waits or find_institutions for resolving institution names.

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