Growo child growth

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

Annotations already cover read-only/idempotent/non-destructive, so the bar is lower. The description adds genuinely useful clinical context beyond them: the output is a 'statistical classification and not a diagnosis', and it flags that the locale-selected disclaimer is a physician-authored safety text that should not be paraphrased. It doesn't discuss determinism or rate limits, 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?

Front-loads the core definition and each following sentence adds distinct value (scope distinction, concrete example, output/nature of result). Slightly long, but no sentence 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 no output schema, the description carries the return-value burden and does so: it names percentile, z-score, and SGA/AGA/LGA category, plus the interpretive caveat. Combined with 100%-covered inputs, an agent has everything needed to call and interpret the tool.

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 descriptions are rich (grams vs cm, obstetric vs corrected age, locale rationale), so the schema does the heavy lifting. The prose adds no additional parameter syntax or constraints beyond what the schema already states; 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?

Names a specific computation (birth measurement on the Olsen 2010 intrauterine curves) and a specific input dimension (completed weeks of pregnancy), and explicitly differentiates itself from the growth charts: 'not how a child grows over time, but how big they were on the day they were born'. This lets an agent separate it from growth_percentile/growth_trend siblings without opening a 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 clear context for when this tool applies versus the growth charts, including a worked contrast (2.2 kg at 34 weeks vs 40 weeks). It does not explicitly name the sibling tool (e.g. growth_percentile) it should be chosen over, so the alternative is implied rather than routed by name.

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, closed-world), so the bar is lower; the description still adds real value by disclosing the return shape (percentile range buckets from 24 months) and that it 'Returns no interpretation'. It does not, however, state behavior under 24 months or any error/edge-case handling.

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 computation and efficiently packed with domain detail across five tight sentences. There is minor redundancy in restating the CDC split ('the split the CDC advises') and the final sentence is a fragment, but overall it earns its length.

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 return-value burden and does so for the 24+ month case, explicitly noting the percentile buckets and the absence of interpretation. What a sub-24-month caller receives (e.g. z-score only) is left implicit, a small gap for a clinical tool.

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 baseline is 3; the description adds meaning by tying ageMonths to the WHO/CDC threshold and explaining that childhood BMI must be read against age and sex. It reinforces param semantics rather than merely restating them.

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 ('Computes BMI from weight and height, then places it on the BMI-for-age chart') and scopes it precisely by age band. An agent can distinguish this from generic growth_percentile or ponderal_index without opening any schema, because the output and chart basis are named.

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 clear contextual guidance: WHO under 24 months, CDC 2000 from 24 to 240 months, and explicitly warns not to read childhood BMI against adult 18.5–25 bands. It stops short of naming sibling tools (e.g. growth_percentile, zscore_percentile) or stating when those would be preferred.

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, so the safety profile is covered. The description adds real behavioral context beyond that: the prematurity exclusion and the YYYY-MM-DD date convention. It does not mention that output includes clinical disclaimer text, which the locale parameter hints at but the description never surfaces.

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, each load-bearing: what it returns, when to use it, and the key semantic caveat. The most important distinction (chronological vs corrected age) is front-loaded rather than buried.

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 correctly spells out the return shape (years/months/days plus totals). Combined with 100% schema coverage and clear annotations, an agent has everything needed to select and call it.

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 schema already documents birthDate, asOf and locale in detail, including the locale's clinical-safety rationale. The description only restates the date format, adding nothing beyond the structured fields. 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 verb and resource: it computes exact calendar age from a birth date, and enumerates the output components (whole years, months, leftover days, totals in months/weeks/days). It also explicitly separates itself from the corrected_age sibling, so an agent can identify 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?

Concrete trigger phrases are given ('how old is my baby in months', 'age in weeks') plus the when-not case ('not the age corrected for prematurity'). It stops short of naming corrected_age outright as the tool to use for preemies, so the routing is implied rather than fully explicit.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the safety bar is met. The description adds useful behavior beyond that: the conversion is to 'every common unit' and the stated purpose is downstream compatibility with growth tools, which tells the agent what to do with 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?

Two sentences: purpose and downstream reason front-loaded, then two worked examples. No filler, and the examples are placed where the agent needs them to encode compound measurements.

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 still conveys that the output is the measurement expressed in every common unit, which is enough to use it. It does not spell out the exact return shape, but combined with full param coverage and clear annotations, an agent has what it needs 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, but the description earns above that by demonstrating the awkward compound-input case the schema only abstracts: '7 lb 4 oz' maps to value 7, unit lb, extra 4. This clarifies the ambiguous 'extra' parameter beyond the schema's own wording.

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 verb (converts) and resource (weight in kg/g/lb/oz or length in cm/m/in/ft), and explicitly frames it as a utility feeding the growth tools. This clearly distinguishes it from the sibling percentile/age tools that consume the converted values.

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 when-to-use context: converting a measurement quoted in lb/oz or ft/in so it can enter 'the growth tools, which take kg and cm.' That is a clear motivating scenario, though it does not name a specific sibling tool or state any exclusions.

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. The description adds substantive domain behavior: correction typically stops around 24 months, before the due date there is no corrected age and the result reports days remaining. It doesn't explain error or edge behavior for out-of-range inputs, but adds meaningful context beyond annotations.

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 core definition, then use cases, then edge conditions and date format. Four sentences, each carrying information; no redundancy with the title beyond what is needed for precision.

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 calculation tool with no output schema, the description covers definition, use cases, edge cases (before due date and >=37 weeks), the output fields, and the date format. Enough for an agent to invoke correctly and interpret results.

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% with detailed parameter descriptions already present (asOf default and midnight caveat, locale purpose, birthDate, gestationalDays/week). The description mentions birthDate and gestationalWeeks and the concept of weeks early, which aligns with the schema, but adds no parameter-level detail beyond it. Baseline 3 is consistent with high schema coverage.

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 resource (corrected/adjusted age for premature babies), defines the calculation ('age since birth minus the weeks the baby was early'), and explicitly scopes that babies born at 37 weeks or later need no correction. This distinguishes it from child_age and other age-related 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 use cases: answering 'what is my preemie's corrected/adjusted age', reading milestones, and choosing the age at which to plot growth. States exclusions clearly (before due date no corrected age; 37 weeks or later no correction).

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 readOnly/idempotent/non-destructive, so safety is covered. The description adds real domain context: what an open/closed/not-yet-due window means and that a child inside the 1st–99th percentile window is within normal range. It does not mention the physician-authored disclaimer/clinician note that the locale parameter implies is returned, which is a minor gap.

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 front-loaded sentences with no filler; the core purpose (what windows are returned) leads, and the percentile interpretation follows. Slightly dense but every clause carries 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, the description does the necessary work of explaining what is returned (window states plus CDC checkpoint months) and how to read the percentile ranges. It leaves the physician disclaimer/clinician-note return value implicit, but is otherwise complete for a two-parameter read tool.

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 both ageMonths and locale are already fully documented at a high level of detail (corrected age, language intent, bounds). The description adds no syntax or format detail beyond the schema, 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?

Specific verb+resource: returns WHO motor-development windows (open/closed/not-yet-due) at a given age, plus nearest CDC checkpoint months. This clearly separates it from percentile/growth siblings like growth_percentile or bmi_percentile. 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 implied by 'at a given age,' but there is no explicit when-to-use guidance, no prerequisite statements, and no mention of alternatives among the many growth/percentile siblings. An agent must infer that this is the milestone-window tool versus the percentile 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 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 establish read-only, idempotent, closed-world, non-destructive behavior, so the bar is lower. The description still adds real context: it enumerates the returned quantities (percentile, z-score, 3rd–97th percentile cutoffs at that age), names the LMS table provenance, and explicitly states 'Returns no interpretation' — a meaningful scope boundary for a clinical tool. It stops short of out-of-range or failure behavior.

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, front-loaded with what the tool does before the return payload and the no-interpretation caveat. The percentile-value enumeration is slightly listy but earns its place by disclosing return content in the absence of an output schema.

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 return-value burden and does so by naming percentile, z-score, and reference cutoffs. Combined with the annotations covering safety and the fully documented schema, an agent has enough to call it correctly; only out-of-range/error behavior and the bmi_percentile overlap remain 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 four enums are fully annotated, so all parameter meaning already lives in the schema; baseline is 3. The description reinforces the WHO/CDC parameter choice in prose ('WHO or CDC growth reference chart') but adds no unit, format, or edge-case detail beyond what the schema says.

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-equivalent (compute placement) and resource (one child measurement against WHO/CDC references), and the phrase 'one measurement' implicitly separates it from trend tools. It never names a sibling, so the overlap with bmi_percentile and zscore_percentile is left for the agent to resolve. Clear purpose, but no explicit sibling differentiation.

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 the inputs (age + metric + value = one-shot percentile lookup), and the WHO vs CDC framing hints at when each standard applies. However, nothing states when to prefer this tool over the sibling bmi_percentile despite this tool accepting metric='bmi', nor when growth_trend or growth_reference_range is the better pick. Implied usage only.

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 openWorldHint=false, so the safety and determinism profile is fully covered. The description adds only the fact that no child measurement is consumed, which slightly clarifies behavior but adds little beyond the annotations.

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 what is returned before the usage hint, with zero 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 usefully states the return shape (the percentile band values). It omits any mention of locale or standard choice, though those are well covered in the schema, leaving only a minor gap for a read-only 5-parameter tool.

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% and the schema itself documents sex, locale, standard, and ageMonths (including corrected age and WHO/CDC semantics). The description mentions only age and sex generically, adding no meaning beyond the schema, 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 resource (percentile band at 3rd/15th/50th/85th/97th) for a given age and sex, and explicitly contrasts itself with measurement-based siblings by noting 'no child's measurement involved.' An agent can distinguish this from growth_percentile or bmi_percentile 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 a clear usage context — 'Use this to answer what is normal for this age' — which orients the agent toward reference-lookup intent rather than measurement classification. It does not name the specific alternative siblings or state exclusions, so it falls short of the 5 bar.

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, closed-world), so the bar is lower, and the description adds real value beyond them: it explains what band crossings mean clinically (one is common while a child settles onto their own curve; two downward is the pattern clinicians review) and discloses a scope limitation about velocity standards.

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 the tool reports, then adds the interpretive note on crossings, then the scope limitation. Three sentences, each carrying information, with no filler or repetition of the title/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?

There is no output schema, so the description carries the burden of describing return content, and it does enumerate the returned components (percentile and z-score per point, positional shift, count of crossings). It stops short of defining the exact output shape or field names, leaving a small gap for a nested-input, multi-output tool.

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 high (83%), so the schema already documents sex, locale, standard, and the age/value fields, including corrected-age guidance. The description adds no syntax, format, or default details beyond what the schema provides, so the 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 verb and resource: what moved between two measurements, listing the concrete outputs (percentile and z-score at each point, position shift, band crossings). It explicitly distinguishes itself from the sibling growth_velocity by declaring that WHO Growth Velocity Standards are not implemented and that it never claims a percentile for rate of gain.

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 clear context for when the tool applies (comparing two attained-growth measurements) and explicitly carves out the velocity-percentile use case as out of scope, which implicitly routes that request to growth_velocity. It stops short of naming the alternative tool or stating required prerequisites, so it is not a full when/when-not/alternatives treatment.

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, closed-world). The description adds real behavioral context: units per metric, the date format, and the explicit limitation that no reference comparison is performed — which matters because the sibling tools do compare against references. It does not mention the disclaimer/clinician note that the locale parameter implies.

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 computed output and followed by usage examples and unit conventions. Each sentence carries information; only the unit/date restatement duplicates the schema slightly.

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 names the returned quantities (change, per-day, per-week, per-30-day rates), which is enough for an agent to relay results. The only gap is that the returned disclaimer/clinician note, hinted at by the locale parameter, is never described.

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%, with metric units, date format and positivity bounds all documented in the schema itself. The description restates the unit conventions and date format but adds no syntax or edge-case detail beyond that, 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 exactly what is computed: the change between two measurements plus rate per day, per week and per 30 days. It also differentiates itself from the percentile/reference siblings by saying it 'states the rate and does not compare it with a reference', so an agent can place it against growth_percentile, zscore_percentile and growth_trend.

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 user-phrasing triggers ('how many grams a day is my baby gaining', 'how many cm did my child grow') and a scope exclusion (no reference comparison). It stops short of naming an alternative sibling tool for when a percentile comparison is what the user actually wants.

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 readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description adds genuinely new behavioral context beyond that: it is pure arithmetic with no clinical interpretation, and it specifies the input unit convention (grams only, 3400 not 3.4), which is a real invocation trap.

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 core definition, then use-case phrases, then the scope caveat, then the unit constraint — a sensible ordering with little waste. The example-query list is slightly repetitive, keeping it short of maximal efficiency.

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 naming all three returned values. For a four-parameter, read-only arithmetic tool whose annotations carry the safety profile and whose schema fully documents parameters, nothing an agent needs in order 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 description coverage is 100% and the locale param even carries its own detailed rationale, so the baseline is 3. The description pushes past baseline by reinforcing units for birthWeightG/currentWeightG and by describing the computed outputs (grams, percent, at/above birth weight), which the schema cannot convey since there is no output 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 precise computation: the delta between a baby's current weight and birth weight, in grams and percent, plus regaining status. This is clearly distinguishable from siblings like growth_percentile, growth_velocity, and growth_trend, which track growth against references rather than a birth-weight baseline.

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 three concrete user phrasings that should trigger it ('how much weight has my newborn lost', 'newborn weight loss percentage', 'has my baby regained birth weight'), which is strong positive routing. It also adds a scope exclusion ('does not say whether the change is expected'), but never names an alternative sibling tool for the adjacent questions an agent might confuse it with.

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 a safe, read-only, idempotent, non-destructive operation, so the bar is lower. The description still adds real behavioral value by disclosing the return shape ('returns the number and does not place it against a range'), which is important with no output schema, but it does not mention the disclaimer/clinician note that the locale parameter implies is also 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?

Two sentences, front-loaded with the formula and scope, then the return contract. Every clause carries information; nothing is padding or repetition of the name/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?

For a pure calculation with no output schema and full annotation coverage, the description is nearly complete: formula, scope, alternative, and return semantics are all present. The only gap is that it describes the return as just the number while the locale parameter signals an accompanying disclaimer and clinician note, leaving that part of the response undisclosed.

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 spelling out the unit algebra (grams and cm cubed versus kg per cubic metre), clarifying how weightKg and lengthCm are consumed and reported. It adds nothing about the locale parameter, which the schema already handles well.

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 with its exact formula (100 x weight in grams / length in cm cubed), names the resource, and explicitly scopes it as a newborn proportion measure rather than a general growth metric. It is easily separable from bmi_percentile and growth_percentile siblings because it declares what it does not do (place the value against a 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?

Provides clear context for when it applies ('newborn proportion measure') and names the alternative for the excluded case ('BMI-for-age is the usual measure for older children'). It lacks explicit prerequisites or input-format guidance beyond what the schema supplies, so it falls just short of full routing instructions.

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 cover the safety profile (readOnly, idempotent, non-destructive), and the description goes well beyond them: it discloses the >5 SD entry-error refusal, the conditional activation of the CDC projection when age and height are supplied, the cm-only input constraint with a conversion example, and the reasoning behind the locale field. That is exactly the extra behavioral context the annotations cannot provide.

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?

Dense but well front-loaded: purpose and formula first, then usage triggers, then the optional CDC mode, then the units caveat. Every sentence carries information, though the parenthetical unit example and the disclaimer rationale make it longer than strictly necessary for a single-parameter-set 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 still tells the agent what comes back (a target height with an 8.5 cm range, plus an optional CDC z-score projection with a one-SD range) and what gets refused. Nothing needed to call the tool correctly at either the required-only or optional-extended level 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%, so the schema already documents each parameter; the description nonetheless adds real semantics beyond it — what the sex enum does to the formula, that childHeightCm and childAgeMonths must be supplied together, and the cm-only unit requirement. It does not restate the numeric bounds, which the schema handles.

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 a specific computation — expected adult height from both parents' heights via Tanner's mid-parental method — and even reproduces the formula, so the agent knows exactly what the tool returns. It is clearly separable from siblings like growth_percentile, growth_trend, and zscore_percentile, which concern a child's measured growth rather than a parental-height projection.

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 trigger phrasings ('how tall will my child be', 'mid-parental height', 'child height predictor') and draws a boundary — it 'says nothing about the child's height today' — which implicitly routes current-height questions elsewhere. It stops short of naming the sibling tools that should be used instead, so it is clear context without full alternative routing.

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 readOnly, idempotent, non-destructive, closed-world behavior, so the bar is lower. The description adds genuinely useful scope disclosure: it is a pure numeric conversion and deliberately excludes clinical interpretation, which prevents misuse as an assessment 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?

Two sentences, zero filler, with the conversion direction and the exclusivity rule front-loaded and the scope caveat last. Every sentence carries distinct 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?

For a 3-param, no-output-schema tool, the description covers direction, exclusivity, and scope. Minor gap: it does not mention that the response may include a physician-written disclaimer/clinician note keyed by locale, which is an observable output the caller should expect.

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 baseline is 3, but the description adds a constraint the schema does not encode: exactly one of zScore/percentile must be supplied (no oneOf/anyOf in the schema). The locale disclaimer/clinician-note behavior is left to the schema description rather than echoed here.

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 verb+resource (z-score ↔ percentile on the normal curve) and scopes it as the growth-chart relationship, which cleanly separates it from siblings like growth_percentile or birth_size_percentile that compute percentiles from measurements. An agent can distinguish 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 a clear invocation rule ('Pass exactly one of zScore or percentile') and an implicit when-not: it converts numbers but 'does not say what it means for a child', steering clinical interpretation to other tools. It never names a specific alternative sibling, so it stops 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.