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

Annotations already declare readOnlyHint, openWorldHint=false, and idempotentHint, covering safety. The description adds that the distance is straight-line (not route) and based on latest position(s), which is useful behavioral context but still leaves return format, error behavior, and multi-device semantics unstated.

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 sentence that states exactly what the tool does with no filler. Every phrase contributes to understanding the operation.

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 a full output schema and annotations covering safety, the description needs only to convey the core concept. It does so adequately for a read-only computation, though it could briefly clarify how multiple latest positions are combined.

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 each parameter (lat, lon, user, device) is fully documented in the schema. The description adds no parameter-specific syntax or meaning beyond what the schema already provides, so the baseline 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?

States a specific operation: compute straight-line distance from latest positions to a target point or home. The resource and calculation type are clear, but the description does not explicitly differentiate it from siblings like get_last_location or get_location_history.

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 on when to use this tool versus alternatives, nor any prerequisites or exclusions. The phrase 'or to the configured home' implies one usage mode but does not route the agent 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?

Annotations already declare readOnly/idempotent/non-open-world, so safety is covered. The description adds a conditional behavior ('address if the Recorder geocodes') and a presentation requirement ('always mention how old the position is'), but the rest of the return list is behavioral filler given an output schema exists.

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?

Front-loaded with the core purpose, then output summary and one actionable instruction. It is short and earns most of its space, though the output enumeration is partially redundant with the output 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 two-param read tool with full schema coverage, annotations, and an output schema, the description supplies everything needed to call it correctly, plus a presentation hint. Only the lack of sibling routing keeps it from being 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?

Schema description coverage is 100%, so both parameters are already documented, including the 'me'/omit semantics. The description's 'or of everyone if no user is given' duplicates schema text rather than adding syntax or format detail, 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 ('Current (most recent) position of a user/device') and adds the scope behavior when no user is supplied. The word 'current/most recent' implicitly separates it from get_location_history, so an agent can distinguish it from its 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 'or of everyone if no user is given' clause gives a usage condition, but it largely restates the schema default. No sibling tool (get_location_history, owntracks_status, reverse_geocode) is named as an alternative, so the when-to-use routing is only implied.

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 readOnly, idempotent, and non-open-world behavior, so the safety profile is covered. The description still adds genuine context the annotations lack: results are expressed in the configured local time zone and the payload separates stays from raw points. It does not mention auth or rate limits, but this is a read tool where that gap is minor.

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 short sentences, front-loaded with the resource definition and followed by output-usage and time-zone notes; nothing is wasted. The clipped opening fragment ('Route/track of a device...') is slightly terse but still readable.

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 a full output schema and rich annotations, the description only needs to add orientation, and it does: what the payload contains, how to use each list, and the time-zone convention. It is essentially complete, lacking only sibling-routing 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 all six parameters (start, end, user, device, max_points, stay_min_minutes) are already documented with formats, defaults, and bounds in the schema. The description adds nothing parameter-specific, 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?

The description states a specific resource and scope: the route/track of a device over a time range, plus distance travelled and stays. That is far more informative than the bare tool name, though it does not explicitly contrast itself with siblings like get_last_location or get_distance, which an agent must infer.

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?

It gives real guidance on how to consume the result ('stays' for where-was-X questions, 'points' for the route), which is useful routing advice. However, it says nothing about when to choose this tool over get_last_location, get_distance, or owntracks_status, and lists no preconditions.

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, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds the useful scoping fact that results are limited to devices 'known to the Recorder,' but says nothing about pagination, ordering, or result size.

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 sentence with no filler; every word contributes to identifying the resource and its scope.

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-value explanation is not needed, and the tool is a simple no-argument read. The one remaining gap is routing guidance versus sibling tools, which is not strictly required for correct invocation but would help selection.

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 per the rubric the baseline is 4; there is nothing for the description to document, and it correctly avoids inventing parameter details.

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 gives a specific verb ('List') and a clear resource ('OwnTracks users and their devices'), and the 'known to the Recorder' qualifier scopes the result set. It is distinguishable from siblings like get_last_location or get_location_history, though it does not explicitly name what distinguishes it from owntracks_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?

Usage is only implied: an agent can infer this is the tool for enumerating devices, but there is no explicit when-to-use statement, no reference to alternative siblings, and no note about prerequisites or empty results.

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, idempotentHint, and openWorldHint=false, so the safety profile is covered. The description's only added behavioral detail is '(no secrets)', which usefully tells the agent the configuration output is safe to surface, but it omits failure/error semantics and response shape.

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 sentence that front-loads the primary action and appends the configuration detail with no waste. Every clause 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 values need not be described, annotations cover the safety profile, and there are no parameters. The only mild gap is what a 'connection check' failure communicates, but that is reasonably delegated to the output 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?

The tool takes zero parameters, which is the baseline-4 case. There is nothing for the description to clarify, and the 100% schema coverage confirms no semantic gaps.

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 ('Check the connection') and resource ('OwnTracks Recorder') plus a secondary action of showing active configuration. It is clearly distinct from the location-oriented siblings (list_devices, get_last_location, etc.), though it doesn't explicitly name them.

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 diagnostic framing implies this is used to verify recorder connectivity or inspect current configuration, but there is no explicit when-to-use guidance, no prerequisites, and no reference to alternatives. Usage 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 cover safety (readOnlyHint, idempotentHint, openWorldHint=false), so the extra bar is lower. The description adds genuinely useful context beyond them: the lookup is scoped to a local geocache of previously seen places, which signals that unknown coordinates may yield no result. It does not say what happens on a cache miss (empty result vs error).

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 sentence with the operation front-loaded and the critical scope constraint parenthetically attached; every clause earns its place and there is 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?

An output schema exists, so return-value documentation is not required, and annotations cover the safety profile. The remaining gap is the cache-miss behavior, which the description hints at ('only already-seen places') but never resolves.

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 carries the burden, and it largely does not: it only implies the two numbers are coordinates. Units, precision, and coordinate ordering are left entirely to the agent's prior knowledge, though the -90/90 and -180/180 bounds in the schema mitigate this somewhat.

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 ('Look up an address for coordinates') and adds a scope qualifier ('in the Recorder's geocache (only already-seen places)') that makes it functionally distinct from the sibling location tools. It does not explicitly name a sibling it is confused with, so it falls short of the 5 bar.

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?

'Only already-seen places' implies a usage boundary (it will not resolve arbitrary coordinates), but the description never states when to reach for this versus the other location tools, nor what to do when the coordinate is not cached. Usage is implied rather than stated.

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