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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds the specific scope (current plan) and time windows (7 and 28 days), which is useful context. It does not contradict annotations, and since the operation is read-only, no side effects need disclosure. However, it does not describe what happens if no plan exists or the interpretation of 'adherence,' but that is partially mitigated by the output schema.

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 a single, focused sentence with no filler. The key information—time windows and scope—is front-loaded, making it easy for an agent to parse quickly. Every word contributes to meaning.

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 simple read-only tool with an output schema, the description is mostly adequate, but the missing parameter explanation leaves a gap. The tool depends on a 'current plan' concept that is not defined (likely from plan_get_current), and the description does not clarify this dependency. The output schema covers return values, so that is not an issue. Overall, it is minimally complete but could benefit from a brief note about the as_of parameter.

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%, and the description does not mention the 'as_of' parameter at all. The agent must infer that it specifies the reference date for metrics, and its nullability/default are only in the schema. Since the description should compensate for low schema coverage, this is a significant gap, though the parameter is optional and not critical to the core operation.

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 returns adherence metrics over 7- and 28-day windows for the current plan. It identifies the resource (adherence metrics) and the specific timeframes, making it distinct from sibling tools like log_adherence (which logs) and plan_get_current (which retrieves the plan). However, it lacks an explicit verb like 'retrieve' or 'get,' though the intent is 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?

The description provides no guidance on when to use this tool versus alternatives. It does not mention that it is read-only (though annotations cover that) or contrast with log_adherence or plan_get_current. No conditions, exclusions, or prerequisites are stated, leaving the agent to infer usage from the tool name and description alone.

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?

Beyond the readOnlyHint annotation, the description discloses two important behaviors: the tool refuses to operate unless show_energy_estimates is enabled, and the output is never a prescription. This adds meaningful behavioral context beyond the structured 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?

The description is compact and front-loaded: the first sentence names the purpose and methods, and the second adds the key behavioral constraints. Every sentence earns its place with no filler or repetition.

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 read-only estimation tool with an output schema, the description covers the essential behavioral and usage constraints: opt-in requirement, refusal condition, method basis, and non-prescription framing. It is sufficient for correct invocation.

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 documents the 'workouts' parameter but leaves 'include_resting' mostly implicit. The description adds method context (Mifflin-St Jeor for resting, MET values for activities) that helps infer the parameter meanings, but it does not explicitly map parameters or describe all accepted activity key formats.

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 computes energy estimates using Mifflin-St Jeor resting energy and Compendium MET values, naming the specific verb and resource. It does not explicitly contrast with sibling tools, so it stops short of full differentiation.

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 gives clear context on when to use the tool: it is opt-in, requires the profile's show_energy_estimates setting, and produces estimates rather than prescriptions. It does not name alternatives or explicitly say when not to use it, but the context is unambiguous.

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, covering the safety and scope. The description adds two behavioral details beyond those: it defaults to profile home area and travel radius, and it 'Sends only coarse coordinates' – a privacy-relevant disclosure. These add value over the annotations, but it doesn't describe return behavior or error cases. Given the annotations cover the primary safety profile, a 4 is appropriate.

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 sentences with no filler. The first sentence front-loads the resource types, and the second covers defaults and privacy. Every word contributes to understanding the tool's scope and behavior. Excellent conciseness.

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?

Despite having an output schema, the description leaves parameter usage largely unexplained. With 5 optional parameters and 0% schema coverage, the agent cannot determine how to filter by kinds, set limits, or interpret the radius. The description is too sparse for the tool's complexity, even though the output schema exists. It needs more detail on parameter semantics to be complete.

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%, so the description must compensate for parameter explanations. It only vaguely references 'defaults to the profile home area and travel radius,' which hints at radius_m and lat/lon but does not explain kinds, limit, or the exact semantics of coordinates. An agent has no guidance on how to use the kinds enum or limit parameter. This is a significant gap for a 5-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?

The description clearly identifies the tool as listing fitness-related facilities from OpenStreetMap, enumerating specific types (gyms, sports centres, outdoor fitness stations, pools, tracks, parks). It distinguishes itself from siblings like find_sessions or find_meals by focusing on physical locations. The phrase 'from OpenStreetMap' gives a specific data source, making the purpose 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?

The description states that it 'Defaults to the profile home area and travel radius,' which tells the agent when no coordinates are provided. It implies that providing lat/lon overrides defaults, but it does not explicitly say when to use this tool versus geocode or other siblings. It gives context but lacks explicit exclusions or alternative routing, so it earns a 4.

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 provide readOnlyHint and openWorldHint, so the description only needs to add context beyond those. It adds useful source provenance ('OpenStreetMap and ORP provider menus'), but does not disclose behavior such as how location defaults work, what happens with no results, or how 'fit the diet' is determined.

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 a single, short sentence with no filler and the core resource front-loaded. It is concise, though its brevity contributes to the lack of parameter and usage detail.

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?

Given 6 optional parameters and only a vague noun phrase, the description leaves too much to inference. The output schema helps, but the description does not explain how to shape a query or what distinguishes this tool's behavior from related tools.

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%, and the description does not compensate. It mentions 'diet' vaguely but does not explain diet_pattern, cuisine, radius_m, limit, or how lat/lon are used. For a tool with 6 parameters, this is a significant gap.

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 identifies the resource ('places to eat') and the key constraint ('fit the diet'), which distinguishes it from siblings like find_facilities and food_lookup. It lacks an explicit verb like 'search' or 'find', but the tool name and noun-phrase description make the purpose reasonably clear.

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 implies when to use the tool: when the user needs places to eat that match a dietary pattern. However, it provides no explicit guidance about when not to use it or how it compares to related tools like food_lookup or find_facilities.

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 annotations already disclose that this is read-only and open-world, and the description adds source context. However, it does not describe behavioral details such as whether location parameters are filtering or required, whether results are live or cached, or how the OpenActive feeds are consumed. There is no contradiction with 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?

The description is a single, scannable phrase with no filler and places the core resource type first. It is appropriately terse, though this terseness contributes to the lack of usage and parameter guidance.

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 an output schema, read-only and open-world annotations, and all optional parameters, the description does not need to explain return values. But it omits meaningful context such as default behavior without location, what ORP/OpenActive mean in practice, and how this differs from find_facilities, leaving a moderate 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?

Only the activity parameter has a schema description, giving 20% schema coverage, and the description adds no parameter guidance. The agent must rely on parameter names and constraint ranges, so the description does not compensate for the low coverage.

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 identifies the resource as 'classes and bookable facility slots' and names specific sources ('ORP provider manifests and OpenActive feeds'). It is clear, but it relies on the tool name for the verb and does not explicitly contrast itself with the sibling find_facilities.

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?

No guidance is given about when to use find_sessions versus alternatives such as find_facilities or geocode. The intended use must be inferred entirely from the resource type.

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 annotations already declare readOnlyHint and openWorldHint, so the read-only and external-data behavior is covered. The description adds the useful context that data comes from Open Food Facts, but it does not explain barcode-versus-query precedence, no-result behavior, or result variability beyond what openWorldHint implies. There is no contradiction with 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?

The description is a single front-loaded sentence with no filler. It states the scope, source, and lookup modes efficiently, which is appropriate for a small read-only lookup tool.

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 simple three-optional-parameter read-only tool with an output schema, the core facts are present. But the description is terse about query-versus-barcode behavior and gives no explicit usage guidance, so an agent would mostly be relying on inference. It is adequate but not fully complete.

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 has 0% description coverage, so the description must compensate. It does map 'barcode' to barcode lookup and 'query' to name search, which adds real meaning. However, it does not describe the limit parameter or how query and barcode interact when both are provided, leaving part of the semantics to inference.

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 identifies a concrete resource (packaged-food information), a specific source (Open Food Facts), and the two lookup modes (barcode or name), so an agent can infer what the tool does. It lacks an explicit verb, relying on the tool name 'food_lookup' to convey the retrieval action, and it does not explicitly differentiate it from siblings like find_meals.

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 context is implied: an agent should use this when it needs packaged-food details from Open Food Facts, with barcode or name as the search route. However, the description gives no explicit when-to-use or when-not-to-use guidance, and it does not mention alternatives among the sibling tools.

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?

With annotations readOnlyHint and openWorldHint already present, the description adds valuable context by naming the external service (Nominatim) and stating that only the label is sent. This clarifies the tool's external dependency and privacy-relevant behavior beyond the annotation hints.

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 core action and followed by the key behavioral note. Every word earns its place and no extraneous detail is included.

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 simple, the output schema exists to define return values, and annotations cover side effects. The description supplies the essential external-service and privacy context, so an agent can invoke it correctly. Minor gaps remain around rate limits or exact coordinate precision, but these are not critical for a coarse-geocoding call.

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 input schema already documents both parameters with 100% coverage, so the baseline is 3. The description does not add meaningful parameter-specific detail, though the phrase 'Sends only the label' hints that the query is the main payload.

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 uses a specific verb ('Turn') and a clear resource ('a place label') to describe the outcome: coarse coordinates. It also names the provider (Nominatim), making the tool's role unambiguous and distinct from sibling tools like find_facilities or food_lookup.

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 use case is implied by the definition: if an agent needs coarse coordinates from a place label, this is the tool. However, there is no explicit guidance about when not to use it or how it compares to alternatives such as find_facilities or estimate_energy.

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 indicate readOnlyHint=false (write operation) and destructiveHint=false (non-destructive). The description adds the behavioral trait 'append-only', which clarifies that entries cannot be modified or deleted, going slightly beyond the annotations. However, it does not disclose potential side effects, validation rules, or failure modes, and the output schema is not described.

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 a single, efficient sentence with zero waste. The core action is front-loaded, and the append-only caveat is placed parenthetically, which is appropriate. It earns its place without unnecessary elaboration.

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 tool with 5 parameters (2 required), the description is inadequate. It does not explain the meaning or purpose of the parameters, any required preconditions (e.g., existing plan item), or how the tool interacts with other tools like adherence_summary. While an output schema exists, the description leaves the agent guessing about parameter semantics and usage context, making it incomplete for correct invocation.

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%, so the description provides no information about the parameters. The schema itself is somewhat self-explanatory (plan_item_id as string, status enum), but the description fails to add any domain meaning, such as what 'perceived_effort' represents or how 'timestamp' should be formatted. It does not compensate for the lack of schema coverage at all.

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 action ('Append an entry') and the target resource ('the adherence log'). The phrase 'append-only' distinguishes it from potential modification or deletion tools. However, it doesn't explicitly contrast with the sibling adherence_summary, which presumably reads adherence data, leaving some ambiguity about when to use this tool versus reading the log.

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, what conditions warrant logging an adherence entry, or any prerequisites (e.g., valid plan_item_id). It also doesn't mention alternatives like adherence_summary for reading. The description is purely declarative with no usage context.

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 read-only nature is known. The description adds the behavioral detail that it may return null, which is useful. It does not contradict annotations, and the openWorldHint is not addressed, but that is a minor omission.

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 a single concise sentence, front-loaded with the action and resource, and includes the null case without verbosity. Every word earns its place.

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 zero-parameter getter with an output schema, the description is complete: it states what is returned and the null condition. There is nothing else an agent needs to know to call it correctly.

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?

There are zero parameters, and the schema coverage is 100% (since there are no parameters). The baseline for 0 parameters is 4, and the description correctly omits any parameter explanation, which 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 ('Return') and resource ('current plan'), and explicitly mentions the null return case. It clearly distinguishes from siblings like plan_save (mutation), plan_validate (validation), and plan_suggest_adjustments (suggestion) by implying a simple getter of the active plan.

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?

No guidance is provided on when to use this tool versus alternatives. The description is purely functional and gives no context about scenarios where this getter is preferred over plan_validate or other plan-related tools. It leaves usage entirely 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that the tool re-validates the plan and refuses invalid inputs. This adds useful behavioral context, though it could more explicitly state what happens to the existing current plan when a new one is saved.

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 a single, tightly written sentence with no filler. The core action ('store as current plan') is front-loaded, and the refusal behavior is added as a concise second clause.

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 single-parameter tool with an output schema, the description covers the essential behavior: validating, storing, and refusing invalid plans. The main gap is that the structure and provenance of an 'ORP plan' rely on domain knowledge, but this is a minor omission given the output schema and sibling tools.

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%, with the 'plan' parameter described as 'A valid ORP plan'. The description adds no further parameter-level meaning beyond what is already in the schema, so the baseline of 3 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 uses a specific verb ('store') and resource ('the plan as the current plan'), and immediately clarifies it rejects invalid plans. This distinguishes it from plan_validate, which presumably only validates without persisting, and from plan_get_current, which only reads.

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 implies the tool is used when a plan should be validated and persisted as the current plan. However, it does not explicitly state when to prefer this over sibling tools like plan_validate, nor does it mention any exclusions or 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. The description reinforces non-mutation ('Never changes the stored plan') and adds the approval-required behavior. It does not disclose potential external data pulls (openWorldHint) or rate limits, but given the annotation coverage, the added approval context is valuable. No contradiction with 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 sentences, front-loaded with the core purpose, followed by the critical non-mutation and approval requirement. No wasted words; every sentence earns its place.

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?

An output schema exists, so return details are covered. The description covers the action, the non-mutating nature, and the follow-up step. It does not mention prerequisites (e.g., a plan must exist) or error conditions, but for a suggestion tool these are minor gaps.

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%, so the description must explain parameters. It mentions 'wearable aggregates' which hints that use_wearables toggles that, but it never explicitly describes as_of or how use_wearables behaves. The description does not compensate for the missing schema documentation.

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 action ('Evaluate the current plan's adjustment_rules against adherence and wearable aggregates') and clearly defines the output ('proposal (JSON Patch + proposed plan)'). It also names the next step (plan_save), distinguishing it from the save tool. The purpose is unambiguous and distinct from siblings.

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 gives explicit usage guidance: it is a non-mutating tool that produces a proposal, and the user must be asked for approval before calling plan_save. It implies when to use it (before saving changes) but does not explicitly contrast with plan_validate or other analysis tools. Still, the workflow is clear.

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 description adds some context beyond annotations by naming the three validation criteria (schema, readiness gate, safety guardrails), but it does not explain what happens on failure, whether it returns pass/fail details, or any side effects. Since readOnlyHint is already true, the read-only nature is covered. The description is consistent with annotations, so no contradiction, but it stops short of fully disclosing validation outcomes.

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 a single, efficient sentence that front-loads the action and scope. Every word contributes to the meaning, with no fluff or redundancy. It is appropriately sized for the tool's simplicity.

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?

Although an output schema exists, the description is incomplete for practical use. It does not explain when to invoke validation (e.g., before saving) or what the validation criteria entail (e.g., what the readiness gate or safety guardrails are). An agent may not understand the domain-specific terms or the tool's role in the workflow, leaving significant gaps for a tool with a nested plan object.

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 description coverage is 100%, with both 'plan' and 'compare_with_current' already documented. The description itself does not add any additional meaning about the parameters, such as how the plan is structured or what the comparison entails. It relies entirely on the schema, which is adequate for a baseline score.

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 action (validate) and the object (a plan), and specifies what it validates against: the schema, readiness gate, and safety guardrails. This distinguishes it from siblings like plan_save or plan_get_current, which perform different actions. The verb is precise and the resource is 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?

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention that it should be called before saving a plan, or that it complements plan_save or plan_suggest_adjustments. No exclusions or alternative tools are referenced, leaving the agent to infer its role.

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 read-only nature is known. The description adds 'local' and 'readiness gate status' as behavioral scope, which is useful but modest. It does not describe output format or side effects, though the output schema covers return values.

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 clear sentence that front-loads the verb and resource. Every word earns its place; there is no filler or redundancy.

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 zero-parameter read-only tool with an output schema and readOnlyHint annotation, the description is complete. An agent knows what the tool does, that it is safe, and can rely on the output schema for return structure.

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 the description does not need to explain parameter behavior. Schema description coverage is 100%, and no parameter-level semantics are required.

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 the verb 'Read' explicitly and names the exact resources: the local ORP profile and the readiness gate status. It is clearly distinguished from siblings like profile_update (which mutates) and readiness_questions (which asks questions rather than reading the gate status).

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?

No guidance is given on when to use this tool versus alternatives such as profile_update or readiness_questions. The description states what it reads but does not indicate the intended use context or mention any exclusions.

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 establish that this is a readOnlyHint=false, destructiveHint=false operation, and the description confirms the write nature ('Create or patch') without contradicting them. It adds the 'local profile' scope and the prohibited-content guardrail, but does not disclose side effects such as overwrite behavior or persistence beyond what the schema's JSON Merge Patch detail implies.

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 entire description is two short sentences: one front-loaded with the action and resource, the second an imperative safety rule. There is no filler or redundant restatement of the schema.

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 one-parameter tool with a rich patch schema, an output schema, and safety annotations, the description plus schema provides what an agent needs to invoke it correctly. The main omission is explicit routing relative to profile_get, but that is a usage-guidance issue and does not leave the invocation ambiguous.

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 covers the single required parameter 'patch' at 100%, including the RFC 7386 merge-patch semantics and the complete-profile rule for new profiles. The tool definition itself adds no parameter-level meaning beyond 'Create or patch', which matches the baseline of 3 for high schema coverage.

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 opens with the specific verb phrase 'Create or patch' and names the 'local profile' as the resource, which makes the tool's mutating purpose clear. It does not explicitly name sibling profile_get as a read alternative, so it misses the top level of differentiation.

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?

'Never include diagnoses, medications or conditions' is an explicit content restriction and helps an agent avoid harmful payloads. However, the description gives no when-to-use guidance versus profile_get or other siblings, and the create-vs-patch condition is left to the schema's parameter description.

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 communicates that this is a read-only operation, and the description adds useful content-level context by naming the screening items, wellness disclaimer, and red-flag notice. There is no contradiction between the description and 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?

The description is short and gets straight to the content of the tool with no filler. It is somewhat telegraphic because it is a noun phrase rather than a complete sentence, but it remains concise and scannable.

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 simple, has full parameter documentation in the schema, has an output schema, and carries a readOnlyHint, so much of the needed context is already provided elsewhere. Still, the description does not explicitly state what action the tool performs or when it should be used, leaving a moderate 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?

The schema description coverage is 100% because the only parameter, locale, is already documented with the allowed values 'en' or 'es-ES'. The tool description adds nothing about parameters, which is acceptable given the schema already covers them.

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 identifies the resource: generic pre-activity screening items, the wellness disclaimer, and the red-flag notice. It lacks an explicit verb such as 'returns' or 'retrieves,' and it does not distinguish this tool from its siblings, so it stops 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?

No guidance is given about when to use this tool versus alternatives. The name and description loosely imply pre-activity screening, but there is no explicit context, prerequisite, or exclusionary condition.

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 and openWorldHint. The description adds meaningful behavioral context beyond that: data is opt-in, sourced from the user's own instance, and returned only as aggregates rather than raw records. This clarifies privacy and scope expectations without contradicting 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?

The description is compact with data types front-loaded, and the second sentence adds a clarifying constraint. There is minor redundancy between 'Aggregated' and 'returns aggregates only', but overall every sentence earns its place and the tool is easy to scan.

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 simple read-only tool with an output schema, the description covers the source, privacy condition, and aggregate nature of the data well. The main gap is the undocumented 'days' parameter, which leaves the caller without full information about how the aggregation window is controlled. It remains callable with defaults, so this is a moderate rather than fatal omission.

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?

There is one parameter, 'days', and schema description coverage is 0%. The description does not mention or explain this parameter at all. The title 'Days' plus default/min/max give some hint that it controls the aggregation window, but the description was expected to compensate for low schema coverage and does not clarify whether it is a rolling window, calendar days, or something else.

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 identifies a specific resource ('the user's own Open Wearables instance') and enumerates the exact data domains covered: sleep, resting heart rate, steps, and workouts. 'Returns aggregates only' supplies the action and distinguishes it from sibling tools that handle profiles, plans, and adherence. It could be slightly more explicit about being a summary/retrieval operation, but the intent is clear.

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 gives clear context: this is appropriate when the agent needs aggregate wearable metrics from the user's own opted-in Open Wearables data. It also implies a limitation (only aggregates, no raw records) and a prerequisite (opt-in). It does not name alternatives or explicitly say when not to use it, but the context is sufficiently concrete.

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