get_activity_data_audit

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

Adds context beyond annotations: 'Facts and counts, no verdict', and an explicit cost signal ('1-3 API requests'), plus a pointer to the methodology guide. The 'read-only' restatement duplicates readOnlyHint, but the request-count and no-verdict framing are genuinely useful behavioral disclosures.

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?

Three dense paragraphs, front-loaded with the primary 'use to' clause and the mode split before the enumeration. Long but essentially every clause carries content; the method/guide pointer is minor overhead.

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?

There is no output schema, so the description carries the return-value burden and does so thoroughly: it specifies what is reported for a single activity and for a period, the default window and max range, and the request cost. An agent can call it correctly in either mode without further context.

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 every parameter including the activity_id mode switch and detail_level semantics. The description reinforces the period defaults but introduces no syntax or format detail the schema lacks, so 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?

States a specific verb+resource: auditing where an activity's data came from and what is missing, with an explicit dual mode (single activity vs period coverage). It enumerates the concrete things reported (sync/source, stops, laps vs intervals, sensors, coverage), which separates it from generic readers like get_activity_streams and get_activity_details, though it never names a sibling directly.

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?

Opens with 'Use to check...' and gives the selecting condition between the two modes (with activity_id = one activity, without = period completeness). It omits explicit exclusions or named alternatives, so it falls short of a 5.

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