mfp_get_measurements

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the tool's safety profile is clear. The description adds that it returns 'historical measurement data with dates and values' and mentions defaults for date parameters, which clarifies the tool's behavior beyond the annotations. No contradiction exists, and the added context (e.g., 'over a date range') enhances understanding without repeating structured metadata.

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 description is concise and well-structured: a two-sentence purpose statement followed by a clear 'Args' and 'Returns' section. It front-loads the primary purpose and keeps each sentence informative, avoiding fluff. The parameter list is neatly formatted and adds value without excessive length. It earns a high score for clarity and economy.

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?

The tool is moderately complex with a nested input object and a response_format option. The description covers parameter defaults and return type (str) but does not describe the exact structure of the returned data beyond 'dates and values'. While an output schema is reportedly present (not shown), its absence means the description should still clarify what the JSON or markdown output contains. The description is adequate but lacks detail on the output format specifics, leaving some ambiguity for an agent needing to parse the response.

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 0% per the signal, so the description must carry the burden of parameter explanation. It does: it enumerates all parameters (measurement, start_date, end_date, response_format) with their defaults and value ranges. It even notes the default measurement is 'Weight' and response_format is 'markdown' vs 'json'. While it does not list all valid measurement string options, it compensates for the absent schema descriptions effectively.

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 clearly states the tool's purpose: 'Get body measurements (weight, body fat, etc.) over a date range.' This specifies the verb (get), resource (body measurements), and scope (date range), distinguishing it from sibling tools like mfp_get_diary (food diary) and mfp_set_measurement (which sets rather than gets). The description is specific enough that an agent can immediately understand what data this tool returns.

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 provides context for when to use the tool ('Useful for tracking weight loss progress and body composition changes') but does not explicitly contrast it with alternatives. It does not mention exclusions or when to prefer mfp_get_report or mfp_get_diary. The guidance is implied through the focus on measurements but lacks direct comparative usage instructions.

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