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

Annotations already declare readOnly/idempotent/closed-world, but the description adds substantial behavior beyond them: the dataset is a hand-compiled incomplete sample, an unknown county returns an empty list with a note rather than a guess, and it enumerates the return payload (county, facilities, note, emergency numbers, source label). This is exactly the kind of disclosure that prevents an agent from over-trusting the result.

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 trigger, then caveats, then return shape; nearly every clause carries new information. Slightly dense and the trailing 'Read-only.' repeats the readOnlyHint annotation, but overall 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?

Even though an output schema exists and return details are technically redundant, the description covers the one thing the schema cannot: the dataset's incompleteness and the empty-list-not-guess contract. Nothing an agent needs to call or interpret this tool correctly is missing.

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

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

Schema coverage is 100% and the schema already documents both the county examples and the level mapping (4/5/6/0). The description's level legend duplicates the schema text verbatim, adding no meaning beyond it, so the baseline 3 applies.

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

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

States a specific verb and resource ('Find sample public health facilities in a Kenyan county') plus the optional KEPH-level scoping. The domain is clearly disjoint from the sibling tools (contributions, maternal protocol, health rights), so an agent can route without opening any schema.

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

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

'Use when someone asks where to go for care' gives an explicit trigger, and the KMHFL caveat implicitly scopes it as a small sample rather than an authoritative lookup. No sibling alternative is named, but none is needed since the use cases don't overlap.

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

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

Annotations already declare readOnlyHint, idempotentHint and a closed world, so the 'Read-only' sentence is partly redundant. The description does add real behavioral context beyond the annotations: unknown topics return an error listing valid topics, and a not-legal-advice disclaimer with a source pointer (kenyalaw.org).

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

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

Four short, front-loaded sentences with the scope stated first and the caveat last; little waste. The trailing 'Read-only.' duplicates the annotation and could be dropped, but overall it is tight.

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, the definition covers trigger, valid values, error behavior, return shape and a legal disclaimer. Nothing essential is missing; only cross-tool routing to get_maternal_protocol is left unaddressed.

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

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

Schema description coverage is 100% and the topic values are already enumerated in the schema, so the description's restatement of 'healthcare, maternal or emergency' adds little. The language parameter is not discussed at all in the description, so it neither compensates nor detracts.

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 ('Kenya's constitutional health rights under Article 43 ... by topic') and names the return content (the right, its legal basis, related articles). It is clearly distinguishable from the contribution/facility siblings, though it never acknowledges the topical overlap with get_maternal_protocol.

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 when someone asks what they are entitled to' gives a clear triggering context, and the error-on-unknown-topic note tells the agent the value space is finite. There is no explicit when-not guidance, which matters given get_maternal_protocol covers a topic this tool also accepts.

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 cover read-only/idempotent/open-world, so the bar is lower, and the description adds real value beyond them: it flags that coverage notes are "reported, not verified here," names the source (Ministry of Health Kenya), and disclaims "general information, not medical advice." Those provenance and reliability caveats are exactly the kind of behavioral context annotations cannot express.

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 purpose is front-loaded, followed by usage, then return contents and caveats, so an agent can stop reading early. There is mild redundancy in "Takes no arguments" and "Read-only," both of which restate structured data (empty schema, readOnlyHint), which keeps it just short of a 5.

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-argument informational lookup, the description covers what the tool is, when to use it, what it returns, the data source, and the reliability/disclaimer caveats. An output schema exists so return values need not be enumerated, and annotations carry the safety profile, leaving nothing an agent needs in order to call it correctly.

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

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

The tool has zero parameters, so per the rubric the baseline is 4. The description reinforces this with "Takes no arguments," which matches the empty, additionalProperties:false 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 a specific resource (Kenya's antenatal care schedule, postnatal care, newborn vaccines, birth registration) and its scope is narrow enough that an agent can tell instantly it is not get_shif_contribution, get_nhif_contribution, find_facility or get_health_right. It also states explicitly that it takes no arguments, so there is no ambiguity about invocation shape.

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 when someone asks what care to expect in pregnancy and after birth" gives a clear triggering condition, and the topical scope effectively routes the agent away from the contribution and rights siblings. It stops short of naming an alternative or an explicit when-not-to-use condition, so it is strong context rather than a full routing rule.

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

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

Annotations already cover read-only/idempotent/no-network behavior, and the description adds substantial value on top: the exact computation (2.75% of gross, min KES 300, no cap, employee only), the deprecated extra field, and the rate-verification note. Only gap is that it restates 'Read-only' already carried by readOnlyHint, and says nothing about error behavior for invalid salary values.

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 deprecation warning and preferred alternative are front-loaded, which is the right ordering for an alias tool. It is dense and largely a single run-on sentence, but every clause carries information the agent needs.

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

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

For a one-parameter, output-schema-backed calculation tool, the description covers the deprecation status, the alternative, the formula, the boundaries, and the source caveat. 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 100% and the single parameter is fully documented, so the baseline is 3. The description goes beyond it by tying the parameter to its calculation semantics (2.75% of gross, minimum KES 300, no cap), which clarifies what the input actually means in practice.

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

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

Names the resource (NHIF/SHIF contribution), states exactly what it returns, and explicitly frames itself as a deprecated alias of get_shif_contribution. An agent can distinguish it from the sibling 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 an explicit when-to-use condition ('when a client still refers to NHIF') and an explicit preference ('prefer get_shif_contribution'), naming the alternative. Routing is unambiguous.

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 mark this read-only, idempotent and closed-world, and the description goes well beyond them: it discloses the exact rate (2.75%), the KES 300 floor, the absence of a cap, that the employee pays alone with zero employer match, the legal source with a checked-on date, and a caveat to verify current rates. That is unusually rich behavioral context for a lookup 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?

The description is front-loaded with purpose, trigger, then the rules and return shape, so an agent gets the essentials in the first two sentences. It runs long and the enumerated return fields are partially redundant with the output schema, and 'Read-only' repeats the annotation.

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 single-parameter calculator with an output schema and annotations already covering safety, every piece an agent needs is present: the trigger, the formula and floor, the payer, the provenance, and a freshness caveat. Nothing material 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 100% and the single parameter already documents 'Gross monthly salary in KES.' The description restates the same meaning ('for a gross monthly salary in KES') without adding format, bounds, or edge-case handling, so the baseline of 3 applies.

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

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

States a specific verb (Calculate) and resource (monthly SHIF contribution) with the input unit (gross monthly salary in KES). The mention that 'SHIF replaced NHIF in October 2024' implicitly separates it from the sibling get_nhif_contribution, so an agent can route between them.

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 when someone asks what SHIF takes from their pay' gives a clear triggering context, which is stronger than most tools. However, it never names get_nhif_contribution as the alternative for pre-October-2024 periods, so the when-not/alternative routing is left to inference.

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