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 reasonably well: it discloses that output is a laid-out day schedule, that cadence depends on product (twice weekly vs weekly), that site rotation is applied, and that the interval derives from SmPC rather than individualized dosing. It omits the return shape (list of dates? table?) and behavior on invalid or past start dates, 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?

The purpose is front-loaded in the first clause, followed by product cadence, the default, and the safety caveat in a compact four-sentence block. The parenthetical cadence grouping is efficient, though the product list occupies substantial space that could have been a shorter reference to the schema enum.

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 three-parameter computation tool with no output schema, the description supplies everything needed to call it correctly: what it produces, the start-date anchor, the cadence per product, the weeks default, and the clinical caveat. No essential call-time information 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 67%, and the description fills the main gap: the product enum in the schema carries no per-value description, but the description groups all seven values into twice-weekly and weekly cadences, which is exactly the semantic needed to predict output. The default of 8 weeks is stated alongside the schema's own description of `weeks`, adding mild reinforcement rather than new meaning.

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 leads with a specific verb and resource: 'Lay out the change days for an HRT estradiol patch.' It also names the secondary action (rotating the application site) and enumerates the supported products, so an agent immediately knows this generates a patch-change schedule rather than checking supply, storage, or dosing. No sibling tool overlaps this function.

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 description gives clear preconditions ('from the day the first patch goes on') and an explicit scope exclusion ('SmPC change interval, not dosing advice'), which steers an agent away from presenting output as clinical dosing guidance. It does not name an alternative tool to use for actual dosing questions, but no sibling covers that, so the gap is minor.

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