Microapp

protein-intake-calculator

Read-onlyIdempotent

Daily protein intake recommendation (grams/day and grams/kg) from body weight, activity level, and goal. References: ISSN position stand on protein and exercise (Jäger et al. 2017) and Helms et al. (JISSN 2014) for protein during a caloric deficit.

Input Schema

TableJSON Schema

Name	Required	Description
`goal`	Yes	Body-composition goal. 'maintain' = current weight + recovery. 'build-muscle' = caloric surplus + hypertrophy training. 'lose-fat' = caloric deficit while preserving lean mass.
`weight`	Yes	Body weight as a positive number, in the unit specified by weight_unit.
`weight_unit`	Yes	Unit for the weight input. 'kg' = kilograms, 'lb' = pounds.
`activity_level`	Yes	Self-reported activity. 'sedentary' = desk job, no training. 'moderately-active' = exercise 3-5×/week. 'very-active' = daily training. 'athlete' = competitive, multiple sessions/day.

Output Schema

TableJSON Schema

Name	Required	Description
`basis`	Yes	Plain-English label for which band was used (e.g. 'Build muscle: 1.6-2.2 g/kg'). Useful for UI captions.
`weight_kg`	Yes	Body weight in kilograms (converted if input was lb).
`g_per_kg_low`	Yes	Lower bound of the recommended protein-per-kg range.
`g_per_kg_high`	Yes	Upper bound of the recommended protein-per-kg range.
`g_per_kg_midpoint`	Yes	Midpoint of the g/kg range — the single number to aim for.
`grams_per_day_low`	Yes	Daily protein in grams at the low end of the range.
`grams_per_day_high`	Yes	Daily protein in grams at the high end of the range.
`grams_per_day_midpoint`	Yes	Daily protein in grams at the midpoint — the recommended target.

Schema Changelog

Changes observed during successful MCP inspections.

AddedMay 21, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is well-covered. The description adds context about output units and scientific references, but does not disclose potential limitations (e.g., applicability to healthy adults only) or justify assumptions. It is sufficient but not rich in behavioral detail.

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

Conciseness5/5

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

The description is two sentences: the first front-loads the purpose and outputs, the second adds credible references. There is no fluff, and every word contributes to understanding.

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

Completeness5/5

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

Given the simplicity of a calculator tool with complete schema descriptions and an output schema, the description is fully adequate. It states outputs, references, and inputs, leaving no essential gaps.

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

Parameters3/5

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

The input schema provides 100% coverage of parameter descriptions, including enums and unit meanings. The description adds no parameter-specific details beyond what the schema already states, so a baseline score of 3 is appropriate.

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

Purpose5/5

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

The description clearly states the tool's purpose: to calculate daily protein intake recommendation in grams/day and grams/kg based on body weight, activity level, and goal. It uses a specific verb ('recommendation') and identifies the resource (protein intake) and inputs, distinguishing it from any calculator sibling.

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

Usage Guidelines4/5

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

The description implicitly tells the agent when to use this tool—whenever a protein intake recommendation is needed—and there are no competing sibling tools for this domain. However, it lacks explicit 'when not to use' or alternative tool references, so it doesn't fully meet the highest bar.

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

All Microapp tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?