Waist size health check (Indian cutoffs) and the waist size to stay under.
Scored across 2 tools
waist_check evaluates a supplied waist measurement for risk, while waist_target returns a recommended healthy target from height/sex; these are directionally distinct (input-evaluation vs output-recommendation). They do overlap in domain and both reference the Indian cutoff, so an agent could occasionally misfire on ambiguous phrasing like 'what waist should I be'.
Both tools follow the same snake_case noun_action pattern (waist_check, waist_target) with a shared 'waist' prefix, making the set highly predictable and readable.
Only two tools for the server, which is borderline thin per the calibration band. For this very narrow single-purpose domain it is defensible, but the surface feels minimal and leaves little room for adjacent operations.
The domain—adult waist-risk assessment and healthy-target recommendation—is covered for both 'is my waist risky' and 'what should my waist be' flows, including unit and waist-to-height inputs. Minor gaps exist (no explicit unit-conversion or sex/ethnicity variants beyond the Indian cutoff) but core workflows are covered.
Use this when an adult asks whether their waist or belly size is too big or risky, such as "is 36 inch waist bad for a man", "waist 88 cm woman", "waist to height ratio 92 cm 170 cm" or "belly fat cutoff for Indians". Do not use for children, pregnancy, diagnosis of a disease, or treatment and medication questions.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | Yes | Sex, since cutoffs differ | |
| waist_cm | No | Waist in centimetres, measured at the belly button after breathing out | |
| waist_in | No | Waist in inches, if not using centimetres | |
| height_cm | No | Height in centimetres (for waist-to-height ratio) | |
| height_ft | No | Height feet part, if not using centimetres | |
| height_in | No | Height inches part, used with height_ft |
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 non-structured context: it is a screening/risk-check tool, not a diagnostic or treatment tool, and it is scoped to adults. It still says nothing about what the result conveys (cutoff values, ratio interpretation), which would be the next useful disclosure.
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 trigger condition and closed with the exclusion list. The inline example phrases are slightly verbose but they do real routing work, so the length is justified.
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, closed-world tool with no output schema, the description covers who it applies to, what questions it answers, and what it must not be used for. The only real gap is that it never indicates what the returned assessment contains or whether height is optional for a waist-only check.
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 even explains the measurement protocol (at the belly button, after breathing out), so the baseline is 3. The description's examples hint at the cm/inch and waist-to-height variants but add no unit, range, or requiredness information 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?
The description states a specific resource and scope: evaluating whether an adult's waist/belly size is risky, with concrete query examples. It never names the sibling waist_target, so an agent must infer the boundary between 'check my waist' and 'what should my waist be' from the names alone.
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 when-to-use triggers with four representative phrasings and an explicit when-not-to-use list (children, pregnancy, disease diagnosis, treatment/medication). This is exactly the routing information an agent needs, leaving little to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Use this when someone asks what waist size is healthy for their height or sex, such as "healthy waist size for 5 ft 8 man", "ideal waist for 160 cm woman" or "what should my waist be". Gives half your height and the Indian cutoff. Do not use for children, pregnancy, or medical diagnosis.
| Name | Required | Description | Default |
|---|---|---|---|
| sex | Yes | Sex, since cutoffs differ | |
| height_cm | No | Height in centimetres (for waist-to-height ratio) | |
| height_ft | No | Height feet part, if not using centimetres | |
| height_in | No | Height inches part, used with height_ft |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish the safe-read profile (readOnly, idempotent, non-destructive, closed-world), so the description only needs to add beyond that. It does add real value by disclosing the returned content (half-height figure and the Indian cutoff) and the scope exclusions, which is meaningful given there is no output schema. It does not say what happens when height is omitted, even though only sex is required.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The trigger condition is front-loaded, followed by the output and then the exclusions in a single compact passage. The three example phrasings consume space but are doing routing work for natural-language queries. Little is wasted.
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 saying what comes back, and it does ('half your height and the Indian cutoff'). Exclusions are covered. The remaining gap is behavioral: only sex is required, so an agent is not told whether height is truly optional or what is returned without 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 sex, height_cm, height_ft and height_in, including the unit and the paired use of feet/inches. The description's examples imply the input shapes but add no syntax or validation detail beyond the schema. 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?
The description states a specific verb+resource: it returns a healthy waist-size target, computed as half the height plus the Indian cutoff. That is concrete and distinguishable from a check-style tool. It does not, however, name or contrast itself with the sibling waist_check, leaving that differentiation to inference.
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 context is given concretely through example queries ('healthy waist size for 5 ft 8 man', 'ideal waist for 160 cm woman'), and explicit exclusions are provided (children, pregnancy, medical diagnosis). What is missing is the alternative: it never says 'if the user already has a waist measurement, use waist_check instead', which is exactly the sibling it should route against.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
waist_checkwaist_targetBMI check with Indian (Asian) cutoffs and a healthy weight range for any height.
Daily protein need by weight and goal, with a sample Indian food plan to hit it.
Body composition for AI: BMI, body fat, FFMI, waist-to-height, plus saved measurement trends.
Calories burned by a step count, and steps needed to walk off a food.
Add one secure layer between your agents and this server.