Skip to main content
Glama

get_daily_heart_rate

Read-only

Retrieve daily heart rate data for a chosen calendar date, helping you review heart rate trends and support health tracking.

Instructions

每日心率。与官方客户端 get_daily_heart_rate 一一对应。参数和日期限制沿用官方接口。Return daily heart rate data for a calendar date.

Input Schema

NameRequiredDescriptionDefault
calendar_dateYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds only that 'date limits follow the official interface' — it acknowledges a real behavioral constraint (limited date ranges) but never discloses what that limit actually is, leaving the agent to fail at call time.

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

Conciseness3/5

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

Short overall, but the Chinese sentence '与官方客户端 get_daily_heart_rate 一一对应' merely restates the tool name and adds nothing. The actionable content (what it returns) is buried after two filler sentences.

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

Completeness2/5

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

For a one-parameter read tool this should be trivially completable, but the agent still cannot construct a valid call: the date format and the actual date-range restriction are both unspecified, and there is no output schema to fall back on for the return shape.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must carry the single calendar_date parameter. It only says 'for a calendar date' — no format (e.g. YYYY-MM-DD vs epoch), no allowed range, no timezone semantics, and the referenced 'date limits' are left unspecified.

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

Purpose4/5

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

States the specific resource (daily heart rate data) and scopes it to a calendar date, and the sibling list makes the distinction from get_daily_steps, get_daily_hrv, get_heart_rate_zones, etc. obvious. It never explicitly says how it differs from siblings like get_heart_rate_zones, but the resource naming is clear enough.

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

Usage Guidelines2/5

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

No guidance on when to use this versus get_heart_rate_zones or get_daily_summaries, and no prerequisites stated. The line '参数和日期限制沿用官方接口' gestures at date constraints but defers to an external 'official interface' the agent cannot see, which is not usable guidance.

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