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

No annotations are provided, so the description carries the full behavioral burden, yet it only hints at an unpublished-months caveat. It does not disclose whether the tool is read-only, what 'publisher gates' means operationally, or what the return behavior is.

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 only one sentence, but it is under-specified rather than efficient. The key caution is not front-loaded with enough context to make the sentence actionable.

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

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

With no annotations, no output schema, two undocumented parameters, and 0% schema description coverage, the description is far too sparse. It omits what the tool returns, how year and family affect coverage, and how to interpret unpublished months.

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 schema has 0% description coverage for the two parameters, year and family, and the description does not mention either one. The agent receives no explanation of what these parameters filter or how defaults should be interpreted.

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 does not state a clear verb and resource; 'Inventory and publisher gates' is cryptic, and 'never treat unpublished months as zero' is a warning rather than a purpose statement. It does not distinguish this tool from siblings such as dataset_info.

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

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

There is no guidance on when to call this tool versus alternatives. The unpublished-months caution is useful but does not tell the agent what conditions select dataset_coverage over dataset_info or other 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?

No annotations are provided, so the description carries the full disclosure burden. It usefully lists the returned attributes (vintage, units, privacy release, audit status), which is valuable given there is no output schema, but it never states that the operation is read-only/side-effect free, nor what 'privacy release' or 'audit status' actually mean or what form the response takes.

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 telegraphic clause with the most important instruction ('Call first') front-loaded and zero filler. Nothing could be removed without losing 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 no output schema and no annotations, the description must convey what the agent gets back, and it does so by enumerating the metadata categories. It falls short only in not defining the jargon terms or confirming read-only behavior, which is minor for a zero-parameter info call.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The description correctly spends no words on arguments and instead describes the return content.

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 implicitly (the dataset) and enumerates exactly what metadata it returns: coverage, vintage, units, privacy release and audit status. That is a clear purpose an agent can grasp without the schema. It does not, however, distinguish itself from the sibling 'dataset_coverage', which overlaps on the coverage dimension.

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?

'Call first' is an explicit, actionable ordering directive that tells the agent when to invoke this relative to the other tools. There are no when-not conditions or named alternatives, but for an entry-point metadata tool the sequencing guidance is the main thing needed.

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 must carry the full behavioral burden. Saying results are 'pre-reviewed fixed' hints that the data is curated/static rather than live, and 'not patient case finding' clarifies the aggregation level, but it says nothing about read-only behavior, permissions, result shape, or how the fixed dataset is scoped.

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?

It is a single front-loaded sentence with no filler, which is structurally efficient. The brevity, however, crosses into under-specification rather than useful concision.

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 four-parameter tool with no annotations, no output schema, and zero schema description coverage, the description leaves the agent without enough information to invoke it correctly. Critical details about parameter semantics and expected results are entirely absent.

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

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

Schema description coverage is 0%, and the description provides no information about the four parameters. It never explains what 'context', 'year', 'uf', or 'limit' mean or what values are expected, so it fails to compensate for 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?

The description names the resource ('ecological hits') and adds qualifiers ('pre-reviewed fixed multi-signal'), but supplies no verb and never explains what a 'hit' is or how it differs from the sibling tools. It is closer to an expanded restatement of the tool name than a clear statement of purpose.

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 'not patient case finding' gives an explicit when-not signal and implies this is for population/ecological-level analysis rather than individual case lookup. However, it names no sibling alternative and gives no positive when-to-use condition beyond that exclusion.

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 and no output schema mean the description carries full behavioral burden, but it only states a data-content nuance. It omits read-only status, permission needs, pagination/limit behavior, and return shape for a six-parameter retrieval 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?

It is a single front-loaded sentence with no filler, and the bed-type caveat is clearly attached. It is terse for a six-parameter tool, but that under-specification is better captured under contextual completeness than as verbosity.

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 six parameters, 0% schema description coverage, no annotations, and no output schema, the description is far too incomplete. It conveys the dataset subject but little of what an agent needs to invoke 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% across six parameters, so the description needed to explain uf, year, month, limit, family, and municipality. It adds only vague domain context ('facility', 'bed types') and leaves required parameters and abbreviations 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?

The description names the resource and dimension: registered capacity by facility, with inpatient/complementary bed types kept separate. It lacks an explicit action verb and sibling contrast, but the purpose is still clear enough for an agent to recognize the dataset.

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

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

There is no statement of when to use this tool instead of siblings like dataset_info, dataset_coverage, or geographic_signals, and no exclusions or prerequisites. Scope is only implied by 'by facility' and the bed-type note.

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 are provided, so the description carries the full behavioral burden, yet it never clarifies whether this is a read, whether results are paginated (the limit parameter defaults to 30), what the default ordering is, or what the response contains. 'Reviewed' weakly implies a read, but nothing about permissions, side effects, or result shape is disclosed.

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

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

Two short sentences with no filler, but the brevity is under-specification rather than economy: the text is front-loaded with a vague verdict-like phrase instead of the operation and scope an agent needs first.

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?

A five-parameter, three-required query tool with no annotations, no output schema, and no enum constraints needs the description to carry nearly everything, and it carries almost nothing. The agent has no basis to choose this tool over ecological_hits or geographic_signals, or to construct a valid call.

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

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

Schema description coverage is 0% across five parameters, including three required ones (proxy, year, uf) plus limit and municipality, and the description explains none of them. The agent gets no guidance on format for year or uf, no meaning for proxy, and no hint that limit controls page size.

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?

"Reviewed fixed ecological proxy cells" restates the tool name in obscure domain jargon without a clear operation or resource outcome, and an agent cannot tell what it would actually receive. The only differentiating statement is a negative ('No flexible CID/procedure intersections') that references a sibling tool which does not exist in the provided list.

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

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

There is no when-to-use guidance, no prerequisites, and no routing to any of the six listed siblings (dataset_coverage, ecological_hits, geographic_signals, etc.). The single exclusion clause hints at a scope boundary but does not tell the agent which conditions should select this tool.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that small cells are omitted and that the unit is activity intervals rather than patients, but it says nothing about permissions, query behavior, defaults, pagination, or result format.

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

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

The description is compact and front-loaded, with no wasted sentences, but its terseness comes at the cost of clarity rather than being optimally informative. It is appropriately brief for a short definition but under-explains the 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?

For a five-parameter query tool with no annotations and no output schema, the description is far too thin. It gives one important caveat about small-cell suppression but leaves usage, parameters, and expected output largely unexplained.

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 provides no information about any of the five parameters (uf, year, limit, family, cid_prefix). The parameter meanings are left entirely to the bare schema titles.

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 domain resource ('annual municipal diagnosis activity intervals') and distinguishes it from patient-level data, but it never states a clear action such as 'retrieve' or 'list' and remains ambiguous about what the tool actually returns. An agent cannot confidently tell from this text what geographic_signals does beyond producing some activity-interval aggregation.

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

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

There is no explicit guidance on when to use this tool versus siblings such as fixed_proxy_activity or ecological_hits. The phrase 'not patients' hints at a unit-of-analysis distinction, but no alternatives or exclusion conditions are named.

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 are provided, so the description must carry the full behavioral burden. It usefully rules out diagnosis and patient eligibility, but says nothing about whether this is read-only or mutating, what permissions are needed, what side effects occur, or what the response 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?

The description is one terse sentence with no filler, and the negative constraint is front-loaded. However, it is a fragment rather than structured guidance, and its brevity comes at the cost of necessary detail for a three-parameter 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?

For a tool with three required undocumented parameters and no output schema, the description is far too thin. It states only a scope exclusion and leaves the agent without the positive purpose, input semantics, or expected 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?

All three required parameters (disease, procedure, competence) have 0% schema description coverage, and the description mentions none of them. It provides no explanation of what values to supply or how the parameters combine to form an association.

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 is a fragment that names a resource ('Dated protocol/billing association') and a negative scope ('never diagnosis or patient eligibility'), but it never states a clear action or what the association produces. It does not distinguish this tool from any sibling, all of which appear unrelated.

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 only guidance is a negative exclusion: 'never diagnosis or patient eligibility'. There is no positive statement of when to use this tool, what problem it solves, or which sibling to use instead, so an agent must guess the triggering context.

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