99 MCP

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

Annotations already establish read-only, idempotent, non-destructive behavior, lowering the burden. The description adds that only status, ETA, and category are returned and that no ride ID is required. It does not disclose behavior like missing-ride responses or how privacy_mode affects output, but the annotation coverage is sufficient to keep this at a mid score.

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 extremely concise with no filler. It front-loads the relationship to 'track' and the key distinction, then states the limited output scope. 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?

Given three parameters, no output schema, and no descriptions for privacy_mode or response_format, the definition is incomplete. The reference to 'same as track' is underspecified because the sibling tool's description is not part of this definition, and there is no guidance on defaults, error cases, or no-active-ride handling.

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 meaning. It clarifies that ride_id is not required, which is useful, but it completely omits any explanation of privacy_mode or response_format, both of which have enum values an agent would need to understand.

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 indicates this tool provides status, ETA, and category for the active 99 ride, and contrasts it with 'track' by not requiring a ride ID. It differentiates from the sibling ninenine_track_ride, though 'same as track' relies on the reader already understanding what track does.

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 explicitly names 'track' as the analogous tool and states the key usage distinction: no ride ID is needed. This helps an agent choose between this and ninenine_track_ride, but it does not discuss other alternatives or edge cases such as what happens when no active ride exists.

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 destructiveHint=true and readOnlyHint=false. The description adds useful non-obvious behavior: fail-closed operation, environment-variable gating, and a guest-token limitation. It doesn't contradict the annotations, though the 'cannot charge' phrasing is ambiguous.

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-load the critical fail-closed and permission requirements. The opening sentence earns its place, and the guest-token clause adds context even if somewhat 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?

It covers the essential gate conditions and makes the destructive intent clear, but there is no output schema and no description of success/failure return behavior or what response_format changes. Edge-case behavior and return semantics are under-specified.

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 only 33%, with ride_id and response_format undocumented. The description mentions explicit_user_intent in prose but does not clarify that it must be set to true or explain the other two parameters. It does not compensate for the low 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?

Name and title clearly specify 'cancel a 99 ride' as a distinct operation from siblings like request_ride and track_ride. The description adds gating context rather than restating the purpose. It lacks an explicit sibling differentiation, so it doesn't reach 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 description explicitly lists required preconditions: NINENINE_ALLOW_MUTATIONS, explicit_user_intent, and notes guest tokens cannot charge. This gives clear activation context. It does not state when not to use it or mention alternative tools, so it stays at 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 declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the description's burden is lower. It adds useful context about the unofficial scope and gated writes, but it does not define what 'gated' means in practice or describe the response format. 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 extremely concise: one sentence states the tool's purpose and a second clause clarifies scope. Every word earns its place, with no repetition of the title or schema details.

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 one optional parameter and no output schema, the description gives enough high-level understanding of what the tool returns. However, it omits any mention of the response_format parameter and provides no explicit guidance on when the tool should be used, leaving a moderate gap in completeness.

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 only parameter, response_format, at all. The enum and default in the schema are self-documenting, but under the low-coverage rule the description was expected to compensate and did 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?

The description clearly indicates the tool reports what this unofficial MCP can read and which writes remain gated, so the resource and scope are identifiable. It lacks a direct verb such as 'lists' or 'returns' and does not distinguish it from sibling ninenine tools, though it does distinguish it from 99Food and 99Pay.

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 tool relative to its siblings like ninenine_connection_status or ninenine_request_ride. The 'Not 99Food or 99Pay' note is an external disambiguation, not usage direction. The phrase 'which writes stay gated' implies it could be used before write operations, but that is not made explicit.

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 and idempotent behavior, but the description adds useful context: token presence, mutations being off by default, and the unofficial nature of the passenger surface. This goes beyond the annotations and helps the agent understand what state the status reports and what safety assumptions hold.

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 extrely concise and free of redundant words, but the telegraphic style relies on unexplained jargon such as 'Local doctor' and 'unofficial passenger surface.' It is short but not as clear as it could be.

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 output schema and a single optional parameter, the description gives reasonable context about token state and mutation safety. Yet it never explicitly states the return shape or the exact meaning of 'connection status,' leaving room for misinterpretation about what the agent will actually recieve.

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 sole parameter 'response_format' at all. However, the schema itself fully constrains the parameter with an enum and default, so the practical gap is small; still, the description contributes no parameter meaning.

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 does not state a direct verb or explicit 'returns connection status'; it relies on the tool name and cryptic fragments like 'Local doctor' and 'unofficial passenger surface.' It hints at useful status dimensions—token presence and mutation configuration—but the action and resource are only implicit.

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 tool versus siblings such as ninenine_capabilities or ninene_privacy_audit. The phrase 'Local doctor' implies a diagnostic use case, but no explicit context or exclusions are provided.

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, openWorldHint, idempotentHint, and non-destructive behavior. The description adds genuinely useful context beyond that: direct driver URLs return 404 HTML, lat/lng are redacted, and the endpoint reads pOrderStatus. It does not detail privacy_mode effects or error cases, but with annotations present the added context is valuable.

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 extremely short with no filler, and each fragment contributes something: the 404 behavior, pOrderStatus, and redaction. However, the phrasing is cryptic and the first clause may confuse rather than clarify, so it loses a point for sacrificing clarity.

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 no output schema and three parameters, this description is insufficient: it does not specify the full return shape, how privacy_mode alters output, or what happens with an invalid or missing ride_id. An agent could infer basics, but the description alone does not provide enough to invoke the 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%, so the description must compensate, but it does not explain ride_id, privacy_mode, or response_format. It hints at privacy behavior through 'lat/lng redacted' and names pOrderStatus as the data read, which gives some context, but enum semantics, requiredness, and parameter mapping remain unclear.

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+resource: it reads pOrderStatus for driver tracking, and the title adds the key qualifier 'GPS redacted'. It is clear in intent, but it does not explicitly differentiate from siblings like ninenine_track_ride or ninenine_active_ride; the 'driver' vs 'ride' naming does some of that work implicitly.

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 explicit when-to-use guidance, no mention of alternatives, and no exclusion criteria. The phrase 'Dedicated driver URLs 404 HTML' implies this tool is more reliable than direct URLs, but it never tells the agent when to choose this over ninenine_track_ride or ninenine_active_ride.

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

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

Annotations already cover read-only, idempotent, and non-destructive behavior. The description adds useful context beyond that: it operates on the 'unofficial 99 passenger surface,' always returns both 99Pop and 99Moto quotes, and has no booking side effect. 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?

Three short sentences with no wasted words. The key fact is front-loaded, and each sentence adds a distinct, useful detail: read-only quoting, both fare types, and no car request.

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 core purpose and safety profile are clear, and annotations cover side effects. However, with no output schema and no explanation of the optional privacy_mode/response_format parameters, the description leaves gaps around result formatting and interpretation.

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 only refers to origin/destination generically. It does not explain how privacy_mode values ('summary', 'structured', 'raw') or response_format values ('markdown', 'json') affect results, leaving the agent to infer semantics from names and enums alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'read-only fare quotes for origin/destination.' It also distinguishes itself from ride-booking siblings by noting it 'does not request a car,' making its scope unmistakable.

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 clearly frames when to use the tool: when a fare estimate is needed without booking a ride. The 'does not request a car' phrasing explicitly excludes request behavior, though it does not name alternative tools like ninenine_request_ride.

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 read-only, idempotent, non-destructive behavior. The description adds useful context beyond that: dedicated address URLs return 404 and are not shipped, and GPS/street data is redacted by default. This helps an agent set expectations about data availability and the returned content.

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 two short sentences with the main action front-loaded. The second sentence packs two behavioral caveats without padding. Minor stilted phrasing ('URLs 404 and are not shipped') keeps it from being perfectly structured.

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 the simple two-parameter schema and read-only annotations, the description covers the core operation and adds useful caveats. However, with no output schema, it does not describe the shape of the returned address list or how response_format affects it. Overall it is minimally viable but leaves parameter and output behavior 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?

Both parameters have zero schema description coverage, so the description must compensate. It does not explain privacy_mode or response_format; the only related hint is that GPS/street is redacted by default, which may imply privacy_mode control but is not explicit. The enum values are self-explanatory, but that comes from the schema, not the description.

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 clear operation: read saved/home addresses, sourced from pGetConfig when present. This distinguishes it from the sibling ride/connection tools, which are about rides, status, estimates, and logout. The 'pGetConfig' reference and the '99 addresses' phrasing in the title add slight jargon, so it is not perfectly polished.

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 explicit guidance is given about when to call this tool versus alternatives. The only conditional phrase, 'when present', describes a data-availability caveat rather than a decision rule. Sibling tools are different enough that an agent might infer usage, but the description does not state it.

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 flag destructiveHint=true and readOnlyHint=false; the description goes further by disclosing the exact file path that will be removed and the explicit user-intent guardrail. 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 short sentences state the action, target, and precondition with no filler. The critical user-intent requirement is front-loaded.

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?

This is a simple destructive logout tool, and the description covers what is deleted and when it is allowed. With annotations covering idempotence and destructiveness, the definition is complete enough; only success/return behavior is omitted, which is not essential here.

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 explicit_user_intent parameter is described in the schema, and the description merely reinforcs it. The response_format parameter lacks a description and the description adds nothing about it; however, the schema's enums and default provide enough guidance.

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?

Description uses a specific verb ('Deletes') and names the exact resource (~/.ninenine-mcp/tokens.json), making the tool's purpose unambiguous. It does not explicitly differentiate from sibling tools, but the unique file path and logout title distinguish it well enough.

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 the key precondition: 'Requires explicit_user_intent,' telling the agent when it is permissible to invoke this destructive tool. It does not mention alternative tools for related actions, but gives sufficient context for safe invocation.

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 bar for added value is met by the description's extra context: the HTTP transport (POST), the response envelope ('JSON 200 errno' — critical for error detection since errors arrive as 200s with errno codes rather than HTTP failures), the lack of authentication, and the side-effect confirmation that no car is requested. All complement rather than contradict 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 13 words with zero filler; the safety-critical facts (read-only, endpoint, response envelope, no token) are front-loaded. It is slightly under-sized for a tool with 6 parameters and two non-obvious enums, but as pure conciseness it is exemplary.

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 parameters at 0% schema coverage, two opaque enums, and no output schema, the description carries a heavy burden and covers only the safety/error-handling layer. Missing are the core use case, parameter semantics, response structure beyond errno, and differentiation from the near-namesake ninenine_estimate sibling — genuine gaps that would force an agent to guess.

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 inherits the full burden of explaining parameters — and it mentions none of them. An agent cannot learn from either source what the from/to lat-lng pairs represent (origin/destination), what privacy_mode does with its opaque 'summary/structured/raw' enum, or how response_format affects output beyond its self-evident name.

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 names a specific verb+resource ('Read-only POST pMultiEstimatePrice') and adds a disambiguating note ('Does not request a car') that separates it from request_ride. However, the business purpose — multi-route price estimation — is only implied via the title and endpoint name; it is never explicitly stated that this computes fare estimates.

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 useful context: it is safe (read-only), requires no token, and does not request a car, which partially excludes the request_ride path. But it offers no explicit when-to-use guidance and never mentions the most likely alternative sibling, ninenine_estimate, so an agent gets no help choosing between single and multi estimate.

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

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

Annotations already cover read-only, idempotent, non-destructive behavior. The description adds the meaningful audit content: which defaults are shown and the condition for request-ride being off. 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?

A single, compact sentence with no filler. It front-loads the key action ('Shows redaction defaults') and packs the gate condition efficiently.

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 audit tool with no output schema, the description covers the essential content. The phrase 'both gates' is not expanded, but this appears to be domain-specific terminology and does not block 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 only parameter, response_format, is fully self-documenting via its enum and default in the schema. Although schema coverage is 0%, the description adds no parameter info, but none is really needed for such a simple option.

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 begins with a specific verb ('Shows') and names concrete resources: redaction defaults for street/phone/GPS and the request-ride gate condition. This clearly differentiates it from all sibling tools, none of which are privacy-focused.

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 usage is implied: use this to audit privacy/redaction settings. It does not explicitly state when to use this tool instead of another, but no sibling tool overlaps with this purpose, so differentiation is less critical.

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 mark this as destructive and non-read-only, and the description adds substantial context: fail-closed behavior, environment variable gating, explicit user intent, guest token charging restrictions, and example defaulting. This is exactly the kind of safety-critical behavioral disclosure that prevents accidental paid or destructive calls. 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?

The description is four short clauses with no filler, and the 'Fail-closed' warning is front-loaded. It is appropriately telegraphic for a gated mutation tool, though the lack of an action statement makes it slightly 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?

There is no output schema, yet the description never explains what a successful call returns or how to consume the ride result. It also does not place the tool in relation to siblings like ninenine_estimate, ninenine_active_ride, or ninenine_cancel_ride. Gating is covered well, but operational context for an agent is incomplete.

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 only 14%, and the description does not compensate. It adds nothing about from_lat/from_lng/to_lat/to_lng, category, or response_format. It only reinforces explicit_user_intent, which the schema already documents, leaving several parameters effectively 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?

The description never explicitly states that this tool places a ride request; it jumps straight to gating details like 'Fail-closed' and NINENINE_ALLOW_MUTATIONS. The action is recoverable only from the name/title and the indirect 'charge' wording, making the description itself vague about the tool's actual operation.

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 conditions: NINENINE_ALLOW_MUTATIONS and explicit_user_intent are required, guest tokens cannot charge, and default examples should not enable it. This tells an agent both when it is permitted and when it should not be invoked. It does not compare against siblings like ninenine_estimate, but the gating guidance is concrete.

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 read-only, open-world, idempotent, and non-destructive behavior, so the additional burden is low. The description adds genuine behavioral context beyond annotations: the returned categories are driven by pGetConfig, include extra products from that config, and exclude 99Food/99Pay. This is useful scoping information with no contradiction to 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 only two short sentences and contains no padding or redundant restatement of the title. The inclusion/exclusion structure is efficient and scannable. It loses a point because the first sentence is grammatically awkward and relies on unclear jargon ('Shipped', 'pGetConfig'), reducing readability.

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 listing tool with no required parameters and self-describing enum schemas, the description is minimally adequate: it identifies the category scope and the config-dependent source. However, with no output schema present, it should have said more about what the returned list contains or how privacy_mode and response_format alter the response, so an agent is left to infer some behavior.

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 needed to explain or contextualize privacy_mode and response_format, but it mentions neither. The schema's enums and default provide some structure, but the description adds zero semantic value about how these parameters affect the returned category list.

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 title and description make clear that this tool exposes ride categories for 99Pop and 99Moto, plus any extra products returned from pGetConfig. It explicitly scopes itself by saying 'Not 99Food/99Pay', which helps distinguish it from broader product-family tools. It loses the top mark because there is no clean action verb like 'returns' or 'lists', and the phrasing 'Shipped ... product list' is cryptic.

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 should be used for ride categories and explicitly says it is not for 99Food/99Pay, which is useful exclusion guidance. However, it does not state when to choose this over sibling tools such as ninenine_capabilities or how to route food/pay requests to an 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?

The description adds 'GPS polylines redacted' beyond what annotations provide, alerting agents that full GPS trails will not be returned. 'Read-only' reinforces the annotations without contradicting them. This is meaningful behavioral context for a data-returning 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?

Three short phrases with zero filler. The core purpose, safety trait, and key data limitation are all front-loaded in fewer than ten words. This is appropriately concise for a simple read-only list 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?

Adequate for a read-only history tool: the agent knows the purpose and the redaction constraint. However, the meaning of the two parameters, especially the privacy_mode enum, is undocumented, which could matter when the agent must choose 'summary' vs 'structured' vs 'raw'. No output schema exists to fill that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description adds no explanation of what 'privacy_mode' values (summary/structured/raw) or 'response_format' mean for the output. The enums are self-explanatory at a basic level, but the semantic difference between the three privacy modes is left entirely to the agent's guess.

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 ('past passenger rides') and the read-only nature, making it clear this is a history lookup. It is implicitly distinguished from siblings like nine_track_ride and nine_active_ride by the word 'past', though it lacks an explicit verb or a named sibling comparison.

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 'Past passenger rides' implies this tool is for historical ride data, which distinguishes it from active/track/request/cancel siblings. However, no explicit 'when to use' or 'use this instead of X' guidance is provided, leaving the agent to infer the routing.

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, covering the safety profile. The description adds behavioral constraints that the tool only works on active rides and excludes GPS/driver phone data, which goes beyond annotations. However, it does not describe error behavior or what occurs when no active ride exists, a minor gap.

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 extremely concise: two sentences, front-loaded with the primary purpose and followed by explicit exclusions. There is no redundant wording, and every sentence adds value. The structure is efficient and easy to parse.

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 3-parameter tool with no output schema, the description is incomplete. It does not explain the meaning of privacy_mode or response_format, nor does it describe the expected response structure or error conditions. Since the output schema is absent, the description should provide more detail on what the agent will receive, but it only gives broad categories (status, ETA, category).

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 of the three parameters. The schema provides enums for privacy_mode and response_format, but no descriptions of their meaning or effect. The description fails to compensate for the lack of schema documentation, leaving the agent to infer parameter semantics from names alone.

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 'Active ride status/ETA/category only' and explicitly excludes 'GPS polylines or driver phone,' which effectively distinguishes it from sibling tools like ninenine_ride_history and ninenine_active_ride. While the verb is not explicit, the title 'Track a 99 ride' implies tracking, and the scope 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 implies usage for active ride status by using 'only,' but it does not name sibling alternatives or provide explicit conditions for when to choose this tool over others. There is no mention of when not to use it or reference to tools like ninenine_estimate or ninenine_ride_history, leaving the agent to infer the use case.

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