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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds the single-vs-range retrieval modes but says nothing about pagination, rate limits, auth, or how large ranges behave — the traits an agent most needs beyond the annotations.

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?

Two tight sentences, zero filler, with the scope declared first and the retrieval modes second. Every clause carries information.

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?

For a 9-parameter, multi-route tool with no output schema, the description covers the main usage shape but its collection list is incomplete relative to the schema enum (it omits enhanced_tag, ring_battery_level, and personal_info), which could mislead an agent about availability. Pagination and response shape are unaddressed but partially implied by limit in the schema.

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 89%, so the schema already documents limit, fields, latest, dates, and document_id. The description only re-summarizes the collection list and the document_id/date-range dichotomy, adding little syntax or format detail beyond the schema. 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 concrete verb ('Read') and resource ('any Oura v2 collection') and enumerates the collection families, which makes the tool's scope unmistakable. It stops short of naming how it differs from siblings like get_daily or get_recent_summary, so an agent must infer the boundary.

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 sentence 'One document via document_id, or a date range' communicates the two invocation modes, which is real usage guidance. It offers no when-to-use/when-not-to-use framing against get_daily, get_recent_summary, or list_collections, and no prerequisites.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds no behavioral context beyond the enumeration of data types: nothing about date-range defaults, pagination, whether missing days are returned, or what the response looks like, which matters for an open-world data source.

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?

Two short sentences, front-loaded with the resource, followed by a concrete usage exemplar. Nothing is wasted and nothing is buried.

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 five parameters, no output schema, and no annotations about behavior, the description is adequate for invocation but thin on completeness: it never explains the return shape or what the date range does by default, leaving the agent to infer output structure from the data-type names alone.

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 80%, so start_date, end_date, limit, and data_type are already documented in the schema. The description merely restates the same data-type list and adds no format or semantics beyond it; 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?

Names a specific resource ('daily summaries') and enumerates the seven supported data types, which maps precisely onto the data_type enum. An agent can distinguish this from get_collection or list_collections, though it never explicitly contrasts with the close sibling get_recent_summary.

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 line 'Best for questions like how did I sleep this week?' gives an implied usage context, which is more than nothing. However, there is no explicit when-not guidance and no named alternative for nearby cases such as get_recent_summary, so routing between the two is left to inference.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description goes beyond them by disclosing the required OAuth scopes (personal, email), which is real authorization context an agent needs before planning a call. It does not cover error behavior if a scope is missing, but the added scope information is substantive.

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?

Two short sentences: first the resource and its contents, then the auth scopes. Nothing is padded and the most important information leads.

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?

For a no-parameter read with annotations already declaring read-only and no output schema, the description covers what the tool returns (age, weight, height, email) and what it requires to run (scopes). That is everything an agent needs to select and invoke it.

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 tool takes zero parameters, so the baseline is 4 and there is nothing the description could add about inputs. It instead documents the shape of the returned profile fields, which is useful given there is no output schema.

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?

Names the specific resource (the user's Oura profile) and enumerates the fields returned, so an agent knows exactly what data comes back. The verb is only implied by the tool name, and no sibling is named, but the resource is distinct enough from get_daily/get_recent_summary to be unambiguous.

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?

Usage is implied: this is the only profile/metadata tool among data-retrieval siblings, so an agent can infer when to reach for it. There is no explicit 'use this when' or exclusion statement, and no mention of what to use instead for body-composition time series (a plausible confusion point with weight data).

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

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

Annotations already cover read-only and open-world traits, so the description only needs to add what they don't. It does: the key behavior is batching five domain summaries into a single call, and it enumerates which domains come back. It says nothing about response shape or payload size, which matters for the 90-day max, but the core behavior is disclosed.

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?

A single front-loaded clause covers what it does, which domains it includes, and a usage example. Every element earns its place, and nothing is padded.

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 one optional parameter, no output schema, and annotations covering safety, the remaining burden is telling the agent what comes back. The domain list does that adequately; a brief note on return granularity (daily-per-domain) would close the last gap.

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 coverage is 100%, and the schema already documents the default of 7 and the max of 90. The description's 'last N days' only restates the parameter, so the 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 and resource: a one-call aggregated overview over the last N days spanning five named domains (sleep, readiness, activity, stress, spo2). That is clearly distinct from get_daily, though the description never names the sibling to make the contrast explicit.

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?

Gives a concrete triggering scenario ('how was my week?') that tells the agent when to reach for this aggregated tool. It stops short of an explicit exclusion such as 'use get_daily for a single day', so the boundary is inferred rather than stated.

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

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

The readOnlyHint annotation already establishes this as a safe read. The description adds useful context by saying each collection's required OAuth scope is included, but it does not describe return shape, pagination, or ordering.

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?

A single efficient sentence, front-loaded with the action and resource, with no filler.

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?

For a no-parameter, read-only list tool, the description is nearly complete: it says what is listed and that OAuth scope metadata is included. Minor gaps around return structure are acceptable given the simple contract and readOnly annotation.

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 tool has zero parameters, so there are no parameter semantics to explain beyond what the schema already provides. Baseline is appropriate.

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: 'List every Oura collection this server can read.' It is distinguishable from the singular sibling get_collection, but it does not explicitly name the alternative or clarify the boundary beyond 'every'.

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?

Usage is implied as a discovery/list operation for Oura collections, but there is no explicit guidance on when to use this versus get_collection or other siblings.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered; the description adds genuinely new context by specifying the check is purely local and makes no network call, telling the agent it is fast and does not validate credentials against the API. It omits what the result looks like (boolean vs error), which keeps it below a 5.

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?

One short sentence, front-loaded with the action and immediately qualified by the surprising constraint (no network call). Nothing is wasted.

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?

For a trivial zero-arg status check with annotations covering safety, the description is nearly sufficient. The one gap is the return shape — a status check's usefulness depends on knowing whether it yields a boolean, an enum, or an error — which neither the description nor an output schema provides.

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 tool takes zero parameters, so there is nothing to disambiguate and the schema is fully self-describing. Baseline 4 applies for a no-parameter tool.

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 and resource — checking whether Oura credentials are configured — and adds the scoping qualifier 'no network call', which separates it from the data-fetching siblings like get_daily and get_personal_info. It does not name a sibling explicitly, so it falls just short of a 5.

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?

Usage is only implied: an agent can infer this is a pre-flight/auth check to run before the get_* tools, but the description never says when to call it or what to do with the result. No explicit alternatives or exclusions are given.

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