Retrieve blood pressure readings from Garmin Connect for a chosen date range to track cardiovascular health and training readiness.
Get blood pressure data
Args: start_date: Start date in YYYY-MM-DD format end_date: End date in YYYY-MM-DD format
| Name | Required | Description | Default |
|---|---|---|---|
| end_date | Yes | ||
| start_date | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the behavioral disclosure burden. It only says 'Get blood pressure data' and lists parameter formats; it does not disclose read-only behavior, date-range inclusivity, timezone handling, or response shape. The agent cannot infer side effects or edge-case 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?
The description is short and free of irrelevant content. The core purpose is front-loaded and the argument details are listed cleanly. It could use a sentence or two more of behavioral context, but as written it is economical.
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 only two required date parameters and an output schema present, the tool does not need an explanation of return fields. Yet the complete lack of usage guidance and behavioral transparency leaves gaps: the agent is not told how to interpret the date range, whether results are aggregated or raw, or whether there are any constraints. This is a minimal viable description, not a complete one.
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?
The schema provides only parameter names and string types, so the description adds the YYYY-MM-DD format for both date arguments. This is helpful but minimal: it still omits whether the date range is inclusive, what time of day applies, or how invalid dates are handled. For a tool with 0% schema coverage, the compensation is partial.
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 and resource ('Get blood pressure data'), and the resource name distinguishes it from sibling tools like set_blood_pressure. However, it does not go beyond the tool name to describe what the returned blood pressure data contains or how it is scoped, so it is clear but minimally informative.
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?
There is no guidance on when to use this tool versus alternatives, nor any exclusions or prerequisites. Sibling tools include several health-data getters and set_blood_pressure, but the description does not help the agent choose this one over those or clarify whether it is the only blood-pressure read query.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.