Growo child growth

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), and the description adds genuinely new behavioral context: what is returned (percentile, z-score, SGA/AGA/LGA), the caveat that this is a statistical classification not a diagnosis, and the locale behavior for paediatrician-authored disclaimer text. That is real disclosure beyond the structured fields.

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 is front-loaded and every sentence does work — the growth-chart contrast and the 2.2 kg example both earn their place. It runs slightly long for a single-purpose lookup tool, but nothing is 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?

With read-only annotations covering safety, a fully documented schema, and the description naming the returned quantities, an agent has nearly everything needed. The absence of an output schema leaves the exact result structure only described rather than specified, which is the one remaining 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 100% and the schema itself carries the important semantics (grams not kilograms, obstetric vs corrected age, 23-41 weeks, sex-specific charts). The description adds no parameter syntax beyond the schema, so a baseline of 3 is appropriate even though the underlying schema is excellent.

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 — where a birth measurement sits on the Olsen 2010 intrauterine curves — and explicitly distinguishes itself from the growth charts ('not how a child grows over time, but how big they were on the day they were born'). The 34-week vs 40-week example makes the distinct question concrete, so an agent can separate it from growth_percentile and growth_reference_range.

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 a clear when-to-use rule and names the conceptual alternative (the growth chart tools), including why WHO charts cannot answer this question. It does not name the sibling tools directly or state explicit exclusion conditions, so it stops just 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?

Annotations already cover the safe read-only, idempotent, non-destructive profile, so the bar is lower. The description adds genuine behavioral context beyond them: which chart applies at which age, that from 24 months a CDC percentile-range bucket is returned, and explicitly that no interpretation is produced.

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 action and the age-based standards; every sentence carries information. Slightly long, and the website attribution sentence is marginal, but nothing is padding.

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?

No output schema exists, so the description must cover returns — and it does, describing the percentile-range buckets and stating that no interpretation is included. Combined with the full schema coverage, an agent has everything needed 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?

Schema coverage is 100%, so the baseline is 3. The description goes beyond the schema by explaining why sex and age matter (charts published separately, WHO/CDC split at 24 months), giving the ageMonths parameter real interpretive 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?

States a specific verb+resource (computes BMI and places it on the BMI-for-age chart) and specifies the reference standards by age. This clearly separates it from siblings like growth_percentile and ponderal_index.

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 when-to-use context: WHO below 24 months, CDC 24–240 months, and warns that childhood BMI is never read against adult 18.5–25 bands. It does not, however, explicitly route the agent among sibling tools such as growth_percentile or zscore_percentile.

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=true, destructiveHint=false, idempotentHint=true, and openWorldHint=false, so safety and side-effect expectations are fully covered. The description adds that the calculation is calendar age since birth, not corrected age, which is meaningful behavioral context. However, it does not mention what the response looks like (no output schema), so the return shape remains opaque.

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 compact sentences front-load the result shape, then give usage examples, the prematurity exclusion, and the date format. No repetition or 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 an idempotent read-only age calculator with full schema coverage and no output schema, the description is nearly complete: purpose, triggers, exclusion, and date format are all present. The only gap is that it does not describe the return structure, though the schema's explicit total-in-units language partly compensates.

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 descriptions for asOf and locale are unusually rich, including the UTC midnight caveat and the clinical-safety rationale for locale. The description adds only the YYYY-MM-DD format reminder for birthDate, which the schema already states. Baseline 3 applies because the schema does the heavy lifting.

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 states a precise verb and resource: given a birth date, it computes exact calendar age broken into years, months, and leftover days, plus totals in months, weeks, and days. It also explicitly distinguishes itself from the sibling corrected_age by saying it is 'the age since birth, not the age corrected for prematurity'.

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 concrete trigger phrases ('how old is my baby in months', 'age in weeks') and explicitly names the excluded use case (corrected age for prematurity), routing the agent to corrected_age. The boundary between the two age tools is clear without opening schemas.

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 a safe, read-only, idempotent operation, so the bar is lower; the description still adds that output spans 'every common unit' rather than echoing the input unit. It does not describe the return shape (a table of converted values) or confirm rounding/precision, which leaves a modest gap for a tool with no output 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?

Two sentences, front-loaded with the capability and its purpose, followed by the two examples that resolve the only genuinely ambiguous part of the call. No filler or repetition of annotation-covered facts.

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, no-output-schema tool, the definition covers purpose, unit coverage and compound-input handling, which is enough for correct invocation; it never mentions the locale parameter's existence or that output enumerates all units, though the schema carries both adequately.

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%, so the baseline is 3, but the worked examples ('7 lb 4 oz' -> value 7, unit lb, extra 4) add genuine meaning beyond the schema's prose by showing exactly how compound imperial quantities map onto the value/unit/extra triple. The locale parameter's clinical-safety rationale is left to the schema, but that is already well covered there.

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 opens with a specific verb and resource ('Converts a weight ... or a length ... to every common unit') and enumerates the supported unit families, so it is immediately distinguishable from the growth/percentile siblings. It even states the downstream motivation (getting measurements into growth tools that take kg and cm), which no sibling does.

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 clearly states the triggering context: a measurement quoted in '7 lb 4 oz' or '2 ft 3 in' needs to be fed into growth tools that accept kg and cm. That is strong when-to-use guidance, but it stops short of naming which specific sibling to call next or any explicit when-not-to-use condition.

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 the read-only, idempotent, non-destructive profile, and the description adds far more: the return fields, the pre-due-date edge case where no corrected age exists and days remaining are reported, the ~24-month cut-off, and the calendar-date 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?

Front-loaded with the definition and formula before usage and edge cases; five dense sentences with no filler, though the milestone/plotting enumeration is slightly longer than needed given sibling tools cover those areas.

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, the description compensates by enumerating the returned values and the pre-due-date/no-correction edge cases, so an agent knows exactly what it will get and when the result is undefined.

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%, so asOf, locale, gestationalDays and gestationalWeeks are already documented in the schema. The description only restates that it takes birth date and gestational age and that dates are YYYY-MM-DD, adding little beyond the structured fields — baseline 3.

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 precise verb+resource (computes the corrected/adjusted age) and gives the exact formula ('age since birth minus the weeks the baby was early'), which distinguishes it from generic sibling tools like child_age or growth_percentile.

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?

Names concrete use cases (answering 'my preemie's corrected age', reading milestones, choosing the plotting age) and an implicit exclusion ('a baby born at 37 weeks or later needs no correction'), but never names an alternative sibling such as child_age or growth_percentile to route term babies to.

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 the safety profile (readOnly, idempotent, non-destructive), but the description adds real value beyond them: it defines what a returned window means (1st–99th percentile from the WHO Motor Development Study) and that inside-window = normal range. It stops short of noting any clinical caveats (e.g. that the locale param carries a paediatrician-authored disclaimer), so not 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?

Two dense sentences, front-loaded with what is returned and followed by the interpretive definition of a percentile window. No filler; every clause 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?

With no output schema, the description must convey what comes back, and it does so well (window states plus CDC checkpoints and the normal-range interpretation). It could go further on return shape (e.g. per-milestone entries) but the safety profile is already covered by annotations.

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 both parameters are well documented in-schema, including the corrected-age hint and the locale rationale. The description adds only the roundabout 'at a given age' wording, so 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 resource and return set: WHO motor-development windows (open/closed/not-yet-due) at a given age plus nearest CDC checkpoint months. This is clearly distinct from the percentile/growth siblings, and no sibling competes on milestones, so an agent can select 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?

Usage is only implied by the tool name and the phrase 'at a given age'; there is no explicit when-to-use, when-not-to-use, or named alternative among the many growth siblings. It does not tell the agent how it relates to corrected_age or child_age, which would be the natural pairing.

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, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuine value beyond them by disclosing the result format (Markdown full text) and that the page url is included, which matters because there is no output 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?

Two short sentences, no filler, with the action and resource front-loaded and the return-format detail placed after. Every clause 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?

For a single-parameter read tool with full annotation coverage and no output schema, the description supplies what the schema cannot: the content format and the fact that the url is returned. It stops short of noting behavior for an invalid or stale id, but is otherwise complete.

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 id parameter is documented in the schema as a page path with an example, so the schema carries the burden. The description only repeats that the id comes from search, adding no syntax or format detail beyond the 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 (Retrieve) plus resource (full text of a Growo article or calculator page) and the return format (Markdown). It also ties the input to the search tool ('the id that search returned'), which separates it from sibling tools that compute values rather than read pages.

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?

Implies the workflow ('by the id that search returned'), so an agent can infer it is used after search to fetch page content. However, it never explicitly states when to use this versus the calculator/measurement siblings, nor any exclusion or prerequisite.

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 readOnly, idempotent and non-destructive, so the safety profile is covered. The description still adds useful context: exactly what comes back (percentile, z-score, 3rd/15th/50th/85th/97th percentile values) and the notable constraint that no interpretation is included.

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?

Three compact sentences with the core purpose front-loaded and no wasted phrasing. The usegrowo.com/LMS reference is marginally promotional but does establish reference-table fidelity, so it 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?

With no output schema, the description usefully enumerates the return payload and notes the absence of interpretation. It does not cover edge cases such as out-of-range ages or which reference standard applies at boundaries, but the schema handles the standard and corrected-age guidance.

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 every parameter (sex, value, locale, metric, standard, ageMonths) is already well documented in the schema. The description adds no parameter-level detail beyond what the schema provides, 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?

The description states a specific computation (where one measurement sits on the WHO/CDC reference) and enumerates the outputs (percentile, z-score, percentile cut values). The phrase 'one measurement' implicitly distinguishes it from trend/velocity siblings, though no sibling is named explicitly.

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?

Usage is implied by scope rather than stated: 'one measurement' signals this is for a single point, not a series, and 'returns no interpretation' tells the model not to editorialize. There is no explicit when-to-use/when-not guidance or routing to alternatives such as zscore_percentile or bmi_percentile.

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 readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is covered. The description adds the scoping constraint (no child's measurement involved) but says nothing about validity ranges, boundary behavior, or output format beyond the percentile list.

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 compact sentences, front-loaded with what the tool returns and followed by the usage cue. Every clause earns its place with no redundancy.

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 read-only reference lookup with rich annotations, 80% schema coverage and no output schema, the description is nearly sufficient: it names the returned percentile band and the scope. It could still note output shape or edge cases, but the core is covered.

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 80%, so the schema already carries most parameter meaning (sex, locale, standard, ageMonths are all documented there). The description only echoes 'age and sex' and adds no syntax or constraint detail beyond what the schema provides, so 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 specifically what it returns (the 3rd/15th/50th/85th/97th percentile values for an age and sex) and clarifies the scope as 'the reference band itself, with no child's measurement involved'. This functionally distinguishes it from measurement-based siblings like growth_percentile or bmi_percentile, though it does not name one directly.

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 usage: "Use this to answer 'what is normal for this age'." That is a clear condition for when to use it, but there are no explicit when-not statements or named alternatives for the adjacent measurement tools.

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/destructiveHint=false, so the safety profile is covered; the description adds substantive non-structured context about what is actually reported and a clear scope limitation (WHO Growth Velocity Standards are not implemented, no percentile is claimed for rate of gain). It does not cover error behavior, but for a pure computation tool this is solid added value.

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?

Three sentences, front-loaded with the return content before the interpretive rule and the exclusion. Dense but every clause carries information; the em-dash aside on band crossings is the only slightly expansive part.

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 six parameters including nested measurement objects, the description usefully previews what comes back (two percentiles, two z-scores, a shift, a band-crossing count). Since the output schema is absent, it could be a touch more explicit about the response shape, but the essentials are present.

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 83%, so the standard, locale, sex, metric and age fields are already documented in-schema. The description mentions band lines (3rd/15th/50th/85th/97th) and 'same child' but adds no syntax or format meaning for the actual parameters, so 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 computation on a specific resource ('what moved between two measurements of the same child') and enumerates the outputs: percentile and z-score at each point, positional shift, and band lines crossed. It also explicitly distinguishes itself from the sibling growth_velocity by denying it is a velocity percentile, so an agent can route without opening either 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 real selection context: band crossings are the clinically meaningful unit, one crossing is common while two downward is the pattern clinicians review, and it rules out the velocity-percentile use case (which points at the growth_velocity sibling). It stops short of naming that sibling or stating prerequisites explicitly, so no full 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?

Annotations already declare readOnly, idempotent and non-destructive, so the safety profile is covered. The description adds real value beyond that: it declares the exact output set (change, rate per day/week/30 days) and explicitly scopes out reference comparison, preventing misuse as a percentile 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?

Front-loads what is computed, then examples, then units, then the scope limitation. Three tight sentences with no filler and no repetition.

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, the description must describe returns, and it does so explicitly (change plus per-day, per-week, per-30-day rates). Units, date format and the no-reference-comparison boundary are all stated, so an agent can invoke and interpret this 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 100%, including the detailed locale rationale, so the schema already carries parameter meaning. The description restates units (grams, cm, YYYY-MM-DD dates), which mostly duplicates the enum and format descriptions rather than adding syntax or ordering semantics. Baseline 3 is appropriate.

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 computation on a specific resource ('how fast a child grew between two measurements') and enumerates the outputs it produces. The closing clause 'does not compare it with a reference' cleanly separates it from growth_percentile and growth_trend among the siblings.

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 triggering utterances ('how many grams a day is my baby gaining', 'how many cm did my child grow') and an explicit exclusion ('does not compare it with a reference'). It stops short of naming the sibling to use instead for reference-based comparisons, so routing is implied rather than spelled out.

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 readOnly, idempotent, non-destructive, and closed-world, so safety is covered. The description adds real behavioral context beyond them: the output contents, the explicit limitation that no clinical expectation is expressed, and the grams-not-kilograms input convention that commonly causes wrong calls.

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 definition, then triggers, then the scope caveat, then the unit warning. Four sentences, each carrying distinct information, with no filler or restatement of the title.

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?

There is no output schema, and the description compensates by enumerating the return contents (gram delta, percent delta, regained-birth-weight flag). Combined with full schema coverage for the four parameters, an agent has everything needed to call and interpret this 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 100%, so the baseline is 3. The description goes beyond the schema by flagging the exact unit failure mode ('Grams only: 3400, not 3.4'), which is the highest-risk ambiguity for the two required numeric weights, and it defines what the echoed ageDays means implicitly via the later-weight framing.

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 computation on a specific resource: the delta between current and birth weight in grams and percent, plus whether birth weight has been regained. It is clearly distinguishable from siblings like growth_trend, growth_velocity, and ponderal_index, which track change over time or normalize by length rather than comparing two weights.

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?

Three concrete user-phrasing examples ('how much weight has my newborn lost', 'newborn weight loss percentage', 'has my baby regained birth weight') map directly to invocation triggers. It also bounds scope by stating it is arithmetic and does not judge whether the change is expected, though it names no alternative sibling for the clinical-interpretation case.

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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavioral context: the return is a bare number with no range or reference comparison ('does not place it against a range'), which tells the agent not to expect a percentile or interpretation.

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?

Three compact clauses: definition/formula first, then scope, then the return-value caveat. Every sentence earns its place, though the formula clause is dense enough that it could be split for faster scanning.

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?

There is no output schema, so the description carries the burden of describing the return value, and it does so explicitly. With full annotation coverage and a simple deterministic calculation, little else is needed; only edge behavior at the weight/length bounds is left to the schema.

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 units, ranges and locale enum are all documented in the schema itself. The description's formula adds a small amount of unit context (grams vs kg per cubic metre) but nothing about how to pass locale or handle the min/max bounds, so this is the baseline 3.

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 exact measure (Rohrer's ponderal index), the inputs it derives from (weight and length), and the formula, so there is no ambiguity about what is computed. It also scopes the tool to newborn proportions, which separates it from the percentile siblings such as bmi_percentile and growth_percentile.

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 states the population this is for ('a newborn proportion measure') and names the alternative measure and the condition that selects it ('BMI-for-age is the usual measure for older children'), which maps directly onto the sibling tools. An agent can route between this and bmi_percentile without opening either schema.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description still adds real value by disclosing the return shape (id, title, page URL) and an important caveat that results are educational, not medical advice.

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?

Three sentences, front-loaded with the purpose and scope, then return shape, then the disclaimer. Every sentence carries information; the topical enumeration is slightly long but directly aids query construction.

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, the description compensates by describing the returned fields, and annotations cover the safety profile. What remains unstated (pagination behavior, ranking, empty-result handling) is minor for a simple search tool with a small default limit.

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%, so `query`, `limit`, and `locale` are already fully documented in the schema. The description's topic list hints at useful query phrasing but adds no syntax or format detail beyond what the schema provides, making the baseline 3 appropriate.

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 (Search) and resource (Growo's articles and calculators), then enumerates the topical scope. It implicitly distinguishes itself from the read-oriented sibling `fetch` by noting that ids must be fetched separately.

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 tells the agent what to do after searching ('Each id can be read in full with fetch'), which routes to the right sibling. It does not, however, say when to prefer the many growth/percentile calculators over a search, leaving that boundary implicit.

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 readOnly/idempotent/non-destructive/closed-world, so the safety profile is covered. The description adds genuine context beyond that: the cm-only input constraint with a conversion example, and the interpretive caveat that the output is a statistical range (±8.5 cm) rather than an individual prediction.

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 dense paragraph, front-loaded with the core definition before triggers, caveats and unit rules. Nearly every clause earns its place, though the formula and the three trigger phrases make it slightly long for a single-operation 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?

With no output schema, the description carries the burden of describing the result and does so at a high level (an expected height with a ±8.5 cm range). The locale/clinical-disclaimer behaviour is documented in the schema, so the remaining gap is minor.

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%, so the baseline is 3, and the schema itself explains the sex param's ±13 cm role. The description goes further by fixing inputs to centimetres and showing a feet/inches conversion (5 ft 10 in = 177.8 cm), which resolves ambiguity the numeric schema alone leaves open.

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 computation (expected adult height) and the exact method (Tanner's mid-parental method), including the formula. An agent can distinguish it from siblings like growth_percentile or child_age 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?

It gives explicit trigger phrasings ('how tall will my child be', 'mid-parental height', 'child height predictor') and equally explicit exclusions: it is a statistical range, not a forecast for one child, and says nothing about the child's current height. That cleanly routes the agent away from current-stature tools.

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 establish read-only, idempotent, non-destructive, non-open-world behavior, so the description's job is lighter. It adds genuine semantic context: the conversion is mathematical only and carries no paediatric meaning, which prevents the agent from over-reading the result. It does not state what happens on invalid input or when both/neither parameter is supplied.

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?

Three short sentences, front-loaded with the core transformation, then the invocation rule, then the scope boundary. Every sentence carries distinct information and nothing is repeated from the schema or annotations.

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, the description does convey that the tool returns the counterpart value (percentile from z-score and vice versa), and the parameter descriptions confirm directionality. For a stateless two-way converter with read-only annotations, that is nearly sufficient; only the invalid-input/edge-case behavior is left unstated.

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%, so the baseline is 3 and the schema already documents zScore, percentile and the locale disclaimer text. The description adds real value beyond the schema by declaring the mutual-exclusivity constraint (exactly one of zScore or percentile), which the schema does not encode via oneOf. No error behavior for violating that rule is given.

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 bidirectional transformation (z-score ↔ percentile) on the normal curve, and explicitly scopes it as a pure numeric conversion rather than a child-specific clinical measure. This distinguishes it from siblings like growth_percentile, bmi_percentile and growth_reference_range 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?

Gives an explicit invocation rule ('Pass exactly one of zScore or percentile') and a negative scope statement ('does not say what it means for a child'), which steers the agent away from using it for clinical interpretation. It never names the alternative tools to use when child-specific interpretation is wanted, so it falls short of a full when/when-not/alternative mapping.

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