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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the closing "Read-only" merely repeats structured data and adds nothing. The description discloses no additional behavior such as currency/units of the amount, empty-month behavior, or account scoping.

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 action and period format. The trailing "Read-only" is redundant with annotations but costs almost nothing.

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. Still, for a monthly amount tool the description leaves the unit/currency and the account identity undefined, and gives no signal on how it differs from the other monthly/account siblings.

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 0% and the schema gives only a bare untyped-description "Month" string, so the description's "YYYY-MM" is the sole source of format guidance and genuinely compensates for the gap. It does not cover edge cases like timezone or invalid-month handling, keeping it short of 5.

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 verb (Return) and a resource (account amount data) scoped to a month, which is enough to know it is a monthly read. However, "amount data" is vague about what is being measured, and nothing distinguishes it from siblings like recharge_month or account_profile, which also deal with monetary/account data.

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?

"Read-only" is a safety statement, not usage guidance. There is no indication of when to call this instead of account_profile or recharge_month, nor any prerequisite about which account is targeted.

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 destructiveHint=false, so the trailing 'Read-only' sentence largely repeats structured data rather than adding new behavioral detail. The only added signal is that the record belongs to the authenticated owner (no user identifier needed), which is useful but thin for a tool with this annotation coverage.

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 purpose. The second sentence is redundant with the readOnlyHint annotation, so it does not fully earn its place, keeping this just below the top mark.

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 of a known resource with an output schema present, the description covers what an agent needs in order to call it correctly. Missing only sibling-level guidance and any hint of what the profile record contains.

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. There is nothing for the description to disambiguate beyond the fact that no user/ID argument is required, which the 'signed-in owner' phrasing loosely conveys.

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 ('Return') and resource ('profile/account record') with the scope 'signed-in owner'. It implicitly distinguishes itself from sibling tools that cover rides, passes, and recharge history, though it never names an alternative explicitly.

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 it should call this when it needs the current user's account details. There is no statement of when to prefer this over siblings like account_month_amount or owned_passes, and no prerequisites or 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the trailing 'Read-only' sentence merely restates structured data without adding anything. No added context is given on the fee rule model, whether results are cached, or when rules change.

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 with the core purpose front-loaded and no padding. However, the second sentence duplicates the annotations rather than earning its place, so it is not maximally efficient.

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?

Because an output schema exists, the return format need not be described, and the read-only nature is covered by annotations. The remaining gaps are the undocumented city_id and the absence of any usage context, which leaves the definition at a minimal-but-adequate level.

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 only parameter, city_id, has 0% schema description coverage and the description never mentions it, so there is no guidance on where the city id comes from or its expected scope. With one undocumented required parameter, the description fails to compensate for the schema 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 gives a specific verb+resource ('Return fee/fare rules for a city'), which is clear enough to distinguish from siblings like current_ride or pass_catalogue. It stops short of explicitly differentiating itself from any sibling, but the resource is distinct within this API surface.

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 call this versus other sibling tools, no prerequisites, and no mention of how it relates to ride_order or account_month_amount where fees might also surface. The agent is left to infer usage entirely from the name.

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 cover the safety profile (readOnlyHint=false, idempotentHint=false, destructiveHint=false), so the bar is lower. The description adds a genuine behavioral guarantee not present in the structured fields: 'never sends account credentials', which is meaningful auth-context for an agent. It does not mention error behavior if the URL is invalid.

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 sentence, front-loaded with the action, then the required argument source. Both clauses earn their place with no filler; it is well sized for a single-parameter 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?

An output schema exists, so return values need not be explained, and the tool takes one parameter. What is present (action, URL source, credential safety) covers the essentials; only edge cases like repeat-close or invalid-URL behavior are unstated.

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 single param has 0% schema description coverage, so the description carries the load. It explains that 'url' is the exact URL returned by the dashboard, which is semantics the bare 'string/Url' schema does not convey.

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?

Specific verb+resource: 'Stop a local dashboard', which cleanly separates it from siblings like open_stats and prepare_stats. It does not explicitly name a sibling to route against, but the action 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?

'using its exact returned URL' tells the agent both the precondition (a URL previously returned, presumably by open_stats) and the constraint (must be exact). It stops short of stating when-not to use it or what to do if the dashboard is already closed.

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 destructiveHint=false, fully covering the safety profile. The description's 'never starts, ends, or alters' reinforces that profile but adds no new behavioral detail such as auth requirements, rate limits, or output format, so it only modestly exceeds the structured data.

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 action and resource, then immediately scopes the behavior. Every clause earns its place 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?

With no parameters, existing output schema, and annotations covering the safety profile, the description is complete enough for an agent to call it correctly. It states both what is returned and that the operation is non-mutating.

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 baseline is 4 per the rubric. The description appropriately avoids inventing parameter semantics where none exist.

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 ('Return') and resource ('current ride status only'), and immediately clarifies it does not start, end, or alter a ride. This distinguishes it from mutation-oriented siblings such as ride_order and from broader read tools like ride_detail or list_rides.

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 ('current ride status only') and an explicit when-not clause ('never starts, ends, or alters a ride'). However, it does not name alternative tools for related reads, which keeps it short of the explicit when/when-not/alternatives requirement for a 5.

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 destructiveHint=false, so the safety profile is covered. The description adds useful scope context (only completed rides, dates are inclusive, omission returns full history) but says nothing about result size, ordering, or pagination behavior for a potentially unbounded listing.

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 with no filler; the purpose is front-loaded and the date-format/default note follows immediately. 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 two-parameter read tool with an output schema, the description covers scope, parameter format, and default behavior adequately. The only real gap is no hint about result volume or ordering when all history is requested, which is minor given the output schema exists.

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 and largely does: it gives the YYYY-MM-DD format, states that both bounds are inclusive, and explains that omitting the dates returns all available history, covering the null/default semantics of both parameters.

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 ("List completed rides") and narrows scope to completed rides, which distinguishes it from current_ride and ride_detail. It stops short of explicitly naming which sibling to use for other ride views, so sibling differentiation is only implied.

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 rather than stated: the tool is for completed rides and omitting dates returns all history. There is no explicit guidance on when to prefer this over ride_summary, ride_detail, or current_ride, and no 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 declare readOnlyHint=false, idempotentHint=false, destructiveHint=false, so the agent knows this is a non-idempotent mutation-like operation. The description adds genuinely new context beyond that: it is a background job producing a URL, and the browser opens only on the MCP host, which is a non-obvious side effect.

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 core action and then the follow-up polling instruction and side-effect caveat. Nothing is padded, though the phrasing is terse to the point of being cryptic.

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-format detail is not needed, and the multi-step job/poll flow is captured. However, with 6 undocumented parameters and no auth or permission notes, the definition is adequate rather than 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% across 6 parameters, so the description carries the full burden. It only clarifies refresh (false = cached data) and implicitly open_browser; ttl, start, end, and include_sensitive_location are entirely unexplained.

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: 'Start a background fetch-and-open job' for stats. It distinguishes itself from the sibling stats_job_status by naming it as the polling counterpart, so an agent can place it in the workflow without opening either schema.

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 clear routing context: the agent should poll stats_job_status for the resulting URL, and refresh=false opens cached data immediately, which tells the agent when to accept stale data. It does not explicitly contrast with prepare_stats or close_stats, so the when-not is left 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 declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the scoping constraint that only active/current passes are returned and that scope is the signed-in account, but says nothing about expiry semantics, pagination, or result volume.

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 zero waste, front-loading the verb and the two scoping qualifiers that actually distinguish the result set.

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 present plus rich read-only annotations and no parameters, the description covers nearly everything an agent needs to select and call the tool. Only the precise meaning of 'active' (unexpired vs. currently valid) is left unstated.

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 schema can carry no semantics and there is nothing for the description to compensate for. Baseline of 4 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 ('Return') and a clearly scoped resource ('active/current passes owned by the signed-in account'), so the agent knows it is not the full catalogue. It never names the sibling pass_catalogue, leaving the contrast to inference.

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 phrase 'owned by the signed-in account' implicitly signals this is the personal-passes lookup rather than the catalogue, but there is no explicit when-to-use, when-not, or named alternative among the many 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, idempotentHint=true and destructiveHint=false, so safety behavior is covered. The description adds that the catalogue is 'current' and enumerates the kinds of data returned (products, prices, allowances, validity), which is useful but modest additional context beyond the structured fields.

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 names the resource and its scope with no filler or redundancy. Every phrase 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-shape detail is unnecessary here, and the safety profile comes from annotations. The definition is nearly complete for a one-parameter read tool, with the city_id input format the only notable 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?

Schema description coverage is 0%, so the description must carry the burden for city_id; it only implies a city scope via 'for a city' and gives no format, ID source, or whether an integer city identifier is expected. This is a real gap for the single required parameter.

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 a concrete resource set (RidePass products, prices, allowances, validity) scoped to a single city. It is clearly distinguishable from owned_passes in substance, but never names or contrasts a sibling explicitly.

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 when-to-use, when-not-to-use, or alternative guidance. With siblings such as owned_passes and recommend_ridepass covering adjacent territory, an agent gets no help deciding between browsing the catalogue, viewing owned passes, or requesting a recommendation.

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=false, idempotentHint=false, destructiveHint=false, so the safety profile is partly covered. The description adds meaningful behavior: the operation is asynchronous, resumable, and returns a job_id for polling, plus a consent gate. It does not explain the consequence of the non-idempotent hint (e.g., whether repeat calls spawn duplicate jobs).

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 front-loaded clauses with zero filler: the primary action and the follow-up step come first, with the consent caveat last. Every phrase 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?

An output schema exists, so return values need not be described, and the job_id reference is sufficient. However, for a 3-parameter export tool with 0% schema description coverage, the description leaves date-range and consent-flag semantics underspecified.

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 for all three parameters. It only indirectly gestures at include_sensitive_location through the consent sentence and says nothing about the format or expected values of start and end, leaving most parameter semantics undocumented.

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 action and mode ('Start a resumable background export') and names the sibling used to monitor it (stats_job_status), so it is distinguishable from the poller and from open_stats/close_stats. It does not specify what data is exported (rides, account, time range), which keeps it 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?

Gives clear continuation guidance ('poll stats_job_status with the returned job_id') and a precondition for a specific input ('Route GPS requires explicit consent'). No explicit when-not or alternative-tool exclusion is stated, but the invocation path is well defined.

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 destructiveHint=false, and the description's 'Read-only' merely restates them. It adds no new behavioral context such as error handling for an unknown ID, authentication needs, or whether the receipt is a stable snapshot.

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, with the core action front-loaded. The trailing 'Read-only' clause earns little since annotations already state it, but nothing is bloated or 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?

For a single-parameter lookup with an output schema present, the description covers what is returned and by what key; return-value detail is correctly left to the output schema. It could say more about failure behavior for an invalid ID, but nothing essential to invoking it is missing.

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 schema documents nothing about recharge_id. The description clarifies that the identifier refers to a recharge/pass receipt, which is slightly more than the parameter name, but gives no format, source, or example of the ID.

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 ('Return one recharge/pass receipt') plus the lookup key ('by its recharge ID'), which clearly distinguishes a single-record fetch from the list-style siblings like recharge_history. It stops short of naming the sibling it is not, so the differentiation is implied rather than 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?

The singular 'one ... receipt by its recharge ID' implies this is the lookup tool used when an ID is already known, as opposed to recharge_history for browsing. However, there is no explicit when-to-use statement, no mention of what to do without an ID, and no named alternative.

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 destructiveHint=false, so the safety profile is covered. The description adds one genuine behavioral fact beyond that: all_pages may issue multiple read-only requests, which signals extra latency/request volume. It says nothing about pagination behavior, ordering, or result size, so it adds only modest value over 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 short sentences with the core purpose front-loaded and zero filler. The second sentence is terse to the point of being under-developed rather than verbose, which is the opposite failure mode.

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, zero-required-parameter tool with no output schema, the description is only minimally complete. It covers what is returned and one flag's side effect, but leaves pagination semantics (page vs all_pages interaction) and the distinction from sibling history tools to inference.

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 carry the parameter burden. It explains all_pages only indirectly ("may make multiple read-only requests") and never mentions the page parameter's paging semantics, so one of the two parameters remains undocumented in both places.

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 and resource: "Return pass/recharge purchase history." That is clearly distinguishable in kind from write-oriented siblings like ride_order. However, it does not differentiate itself from the closely named siblings recharge_detail, recharge_month, or vipps_payment_history, which is exactly where a routing hint would matter.

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 statement of when to use this tool rather than recharge_detail, recharge_month, or vipps_payment_history, and no prerequisites or exclusion conditions. The only usage-flavored sentence concerns the all_pages flag, not tool selection.

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, idempotentHint, and destructiveHint=false, so 'Read-only' merely restates structured data rather than adding anything. No further behavioral context (auth, rate limits, error conditions) is disclosed, so the description contributes little beyond what the annotations already carry.

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 that are front-loaded with the operation and scope. Efficient and wasted little space, though 'Read-only' duplicates the annotation and thus doesn't earn 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 needn't be spelled out, and the tool is simple with one parameter. Still, the lack of any differentiation from the recharge_* siblings leaves a real gap for an agent choosing among twenty 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% for the single month parameter, so the description carries the burden of clarifying it. The 'YYYY-MM' hint usefully specifies the expected format beyond the bare 'string' schema, but no further detail (valid ranges, timezone, etc.) is given, so it only partially compensates.

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 clear verb (Return) and resource (recharge data) scoped to a month, so the basic operation is unambiguous. However, it does nothing to distinguish itself from siblings like recharge_history, recharge_detail, or account_month_amount, leaving the agent to infer which recharge tool applies when.

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 statement of when to use this tool versus alternatives, no prerequisites, and no exclusions. The description offers only what the tool returns, not the context that would select it over its many 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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The phrase 'with stated conservative assumptions' hints at the comparison methodology but never explains what those assumptions are, what period is analyzed, or how costs are computed, so it adds only modest value 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?

A single front-loaded sentence with no filler or repetition. It is efficient, though arguably too terse for a tool whose schema carries no field-level documentation.

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. But with 0% parameter coverage and no explanation of the 'conservative assumptions,' scope of rides considered, or time-window behavior, the agent lacks enough context to call this tool confidently.

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 any parameter. 'Current city' loosely implies city_id, but the meaning and accepted format of start/end (optional, nullable strings) are unexplained in both schema and description, leaving the agent to guess at the time-window semantics.

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 concrete verb and two resources ('Compare current city RidePasses against observed rides'), which tells the agent this is an analysis/comparison tool rather than a lookup. However, it never distinguishes itself from plausible siblings like pass_catalogue, owned_passes, or ride_summary, and the actual deliverable (a recommendation, per the name) is only implied.

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 when-to-use statement, no prerequisites, and no named alternative among the 19 sibling tools, several of which (pass_catalogue, owned_passes) overlap in subject matter. The agent is left to infer the calling context entirely.

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 destructiveHint=false, so 'Read-only.' merely restates structured data rather than adding to it. The only novel behavioral content is the 'completed ride' scope restriction; nothing is disclosed about failure modes for an unknown/invalid ID.

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 very short sentences with the core purpose front-loaded and zero padding. Nothing could be removed without losing 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?

An output schema exists, so return values need not be described, and the operation is simple (one required param, read-only, idempotent). The definition is nearly sufficient for correct invocation; only ID sourcing/format is unstated.

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 0% and the single parameter is named 'use_id', which is opaque on its own, so the description does useful work by clarifying it is a ride ID. It still gives no format, example, or source for that ID, so it only partially compensates for the coverage 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?

States a specific verb+resource ('Fetch detail for one completed ride ID'), and the word 'completed' implicitly separates it from the sibling current_ride. However, it never names or contrasts with the near-neighbours ride_summary, list_rides, or ride_route, so the agent must infer the boundary itself.

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?

'One completed ride ID' scopes usage implicitly (not for in-progress rides, one ride at a time), which rules out current_ride by inference. There is no explicit when-to-use guidance and no named alternative, so the routing decision is left partly to the agent.

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 destructiveHint=false, so 'Read-only' largely repeats structured data. The only added behavioral signal is the 'completed ride' scope constraint, which usefully implies the tool fails or is meaningless for in-progress rides.

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, front-loaded sentences with no wasted words. Brevity is appropriate, though the second sentence ('Read-only') is redundant against the annotations rather than earning 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 no explanation, and annotations cover the safety profile. However, with an undocumented required parameter and no guidance on sourcing order_id, the definition is only minimally complete for an agent that must actually call 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?

Schema description coverage is 0% and the single required parameter order_id has no description in either the schema or the tool description. The agent gets no hint about where order_id comes from or its format, and the description does not compensate for this 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?

States a specific verb ('Fetch') and resource ('linked order/charge detail for a completed ride'), which distinguishes it from ride_detail, ride_summary, and ride_route by focusing on order/charge linkage. It does not name a sibling to route against, so it falls 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?

The phrase 'for a completed ride' implies the precondition (the ride must be finished) but gives no explicit when-to-use vs when-not guidance and never points to alternatives like ride_detail or list_rides for obtaining the order_id. Usage is inferable but not 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?

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description adds a meaningful precondition about explicit sensitive-location acknowledgement, but it doesn't explain how that acknowledgement is achieved, whether it's enforced server-side, or what happens if it isn't – which is the key behavioral question here.

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 waste. It's efficient, though the extreme brevity comes at the cost of the clarity the missing schema docs need.

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 present, return values can be omitted, but the tool still has two undocumented parameters and a potentially sensitive access precondition. For a GPS-location tool with 0% schema coverage and no sibling differentiation, the description leaves important calling requirements unresolved.

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 0%, so the schema only names use_id and include_sensitive_location with no explanation. The description mentions 'sensitive-location acknowledgement' but does not clarify what include_sensitive_location controls, whether it must be true, or what use_id identifies. The description does not compensate for the documentation 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?

States a specific verb (Fetch) and resource (stored route GPS) with a notable constraint, but 'route GPS' is terse and there is no differentiation from siblings like ride_detail or current_ride, which likely also return ride data. Purpose is discernible but the boundaries are left to inference.

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 this tool is only for retrieving stored route GPS after acknowledging sensitive location, which gives some contextual usage. But it never says when to use it over ride_detail or current_ride, and the acknowledgement precondition is not operationalized for the caller.

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 destructiveHint=false, so the safety profile is covered. The description contributes only the word 'local', which faintly suggests on-the-fly computation rather than an asynchronous stats job, but it never explains default time-range behavior when start/end are omitted, output granularity, 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 and no redundancy. It is efficient, though the brevity is achieved partly by omitting information that belongs somewhere.

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 explained, but the tool takes an undocumented date range and the description omits when to call it versus the stats siblings. For a two-parameter analytics tool the definition leaves essential invocation context missing.

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 start or end at all, so it fails to compensate for the schema gap. An agent cannot learn the expected date format, whether the range is inclusive, or what range is used by default (both params default to null).

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 ('Compute') and resource ('local ride totals'), then enumerates the metrics produced (distance, duration, discounts, monthly trend, averages), which lets an agent distinguish it from siblings like current_ride or list_rides. It is clear but never differentiates itself from the stats-oriented siblings such as prepare_stats or account_month_amount.

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 no when-to-use guidance, no prerequisites, and no mention of alternatives, despite several siblings (prepare_stats, stats_job_status, account_month_amount, recharge_month) occupying adjacent statistics territory. An agent has no signal for preferring this tool or for knowing whether start/end should be supplied.

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 destructiveHint=false, so the safety profile is covered. The description adds genuine context about what a completed job yields (counts, and a dashboard URL for open_stats), but says nothing about in-progress/failed states or polling cadence.

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 with no filler, and the core action ('poll') is front-loaded before the return-value 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?

An output schema exists, so return values need not be spelled out, and the description's note on completed results is a helpful bonus. The only real gap is the missing lifecycle guidance (pending/failed states, polling) for a job-status tool.

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?

One required parameter (job_id) with 0% schema description coverage, so the description must compensate. It only hints that the job is 'background stats job,' implying the id comes from prepare_stats, but gives no format or source detail beyond the schema's bare 'Job Id' title.

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 (poll) and resource (background stats job), which cleanly separates it from the sibling tools that prepare or return stats. It never names those siblings, so the differentiation is implied rather than 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?

Calling this a 'poll' implies it is used repeatedly after a job is kicked off (presumably by prepare_stats), but the description never states when to call it versus checking elsewhere, nor that it requires a job_id produced by another tool.

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, idempotentHint and destructiveHint, so repeating 'read-only' adds no new information. The only added context is the account scoping; nothing is said about pagination behavior, result volume, or what happens when all_pages=true, which is the main behavioral question for this tool.

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; the verb and resource come first and 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 read-only list tool whose safety profile is already carried by annotations, the description is minimally adequate: it names the resource and scope. It falls short on the one thing it should explain — pagination semantics — and there is no output schema to cover return shape.

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?

Both parameters (page, all_pages) have 0% schema description coverage, and the description explains neither: it doesn't say that page is zero-indexed, how page interacts with all_pages, or whether all_pages overrides paging. With two undocumented parameters, the description should compensate but does not.

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 (Return), resource (Vipps payment-order history) and scope (signed-in account), so the agent knows exactly what it retrieves. It does not, however, differentiate itself from the similarly-named siblings recharge_history/recharge_detail.

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 when-to-use or when-not-to-use guidance, and no alternative tool is named. The agent must infer from the name that this is the history-listing call rather than one of the recharge/ride siblings.

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