ClickBus MCP

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

Annotations already establish this as a safe, read-only, idempotent operation. The description adds useful behavioral context by disclosing that the tool relies on live trip JSON because dedicated boarding URLs fail, which goes beyond what annotations provide.

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 very short and front-loaded, with each sentence carrying information. The second sentence is telegraphic but still earns its place as a key caveat, though it could be phrased more clearly.

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, a cryptic two-sentence description, and five parameters including two enums, the agent is left without enough context about expected output, the meaning of 'boarding points', or how response_format and privacy_mode affect results.

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 description adds nothing about the parameters. The schema covers the three required slugs/date with examples and gives enums for two optional fields, but at 60% coverage the description could have clarified privacy_mode and response_format behavior, and 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?

The description identifies the resource (boarding terminals/points) and the source (live trip JSON), but it lacks an explicit verb like 'get' or 'list', leaving the action to be inferred. It is more specific than a tautology but not fully self-explanatory.

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 statement 'Dedicated boarding URLs 404/500' implies this tool is a workaround for broken dedicated endpoints, giving an indirect reason to use it. However, it does not explicitly say when to prefer this tool over sibling tools or mention any exclusions.

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

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

Annotations already indicate a destructive, non-readonly write operation. The description adds useful behavioral context: it fails closed, requires an environment flag, requires explicit user intent, and guest tokens cannot charge. It does not describe what happens after a successful booking, but the annotations plus the gating notes cover the most important behavioral risks.

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?

Four short, front-loaded sentences with no filler. 'Fail-closed' immediately communicates the most critical behavioral constraint, and every subsequent sentence adds distinct gating or auth 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 mutation tool with six parameters, no output schema, and financial implications, the description is incomplete. It fully covers gating requirements but omits how to obtain trip_id, what the response contains, and what a successful booking actually does. An agent would still need significant external knowledge to call this correctly.

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

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

Schema description coverage is only 17%, and the description does not compensate. Only explicit_user_intent is referenced, while from, to, departure_date, trip_id, and response_format are left entirely undocumented. The description reinforces the intent flag but adds nothing about required travel parameters or the output format.

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 clearly states the operation: 'Book a ClickBus ticket (gated)', and the name 'clickbus_book' matches. The description itself does not restate the purpose, instead focusing on gating requirements, but the tool is still unambiguous and distinct from sibling search/cancel tools.

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 names prerequisites: CLICKBUS_ALLOW_MUTATIONS and explicit_user_intent, and warns that guest tokens cannot charge. It also says 'Default examples never enable this,' which tells agents not to invoke it casually. It does not explicitly say 'use after search_trips' or contrast with alternatives, but the gating guidance is clear.

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

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

Annotations already mark the tool read-only, idempotent, open-world, and non-destructive. The description adds valuable behavioral context beyond those annotations by stating that street, phone, and GPS data are redacted, which affects the data the agent will receive. No contradiction with annotations exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three terse fragments ('Past consumer bookings. Read-only. Street/phone/GPS redacted.') convey the core purpose, safety, and privacy behavior with no filler. Everything present earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with optional parameters, the core behavior and privacy redaction are stated. However, with no output schema and no parameter descriptions, the agent is left to infer what privacy_mode values like 'summary' vs 'raw' produce and when to use them. It is minimally viable but has clear gaps around invocation choices.

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 never mentions privacy_mode or response_format, so it does not compensate for the missing parameter documentation. The enum values are reasonably self-explanatory, which prevents a score of 1, but the description adds no meaning to the 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?

The description states the resource ('Past consumer bookings') and signals a read or retrieval operation, though it never uses an explicit verb like 'list' or 'retrieve'. It is clearly distinct from siblings such as clickbus_track_booking or clickbus_search_trips, but does so via context rather than direct contrast.

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 about when to choose this tool over clickbus_track_booking, clickbus_search_trips, or clickbus_book. 'Read-only' implies it is not for mutations, but the description offers no explicit when-to-use or when-not-to-use direction.

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 valuable behavioral context beyond the annotations: the tool is fail-closed, requires a specific environment permission, and rejects guest-token charge attempts. This complements the destructiveHint=true annotation and helps the agent understand safety and auth boundaries before invoking it.

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 most critical behavioral keyword 'Fail-closed' followed by the two required gates. Every sentence earns its place with no repetition of schema or annotation 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 gated destructive mutation, the description covers the necessary safety and authorization context well. Since there is no output schema and the tool's core action is in the title, the lack of details about return values or post-cancel effects is a minor gap rather than a blocking one.

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%, and the description does not compensate. It mentions explicit_user_intent as a requirement, but the schema already describes that parameter. booking_id and response_format are left to their property names, with no added meaning about formats, behavior, or dependencies.

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 clearly states the action and resource: 'Cancel a ClickBus booking (gated)', which distinguihes it from sibling tools like search and book. The free-text description itself does not restate the purpose, but combined with the title and tool name the meaning 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 gives concrete usage gates: requires CLICKBUS_ALLOW_MUTATIONS and explicit_user_intent, and guest tokens cannot charge. It does not explicitly name alternative tools or when-not-to-use scenarios, but for a cancel operation these preconditions are clear and actionable.

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 indicate readOnlyHint=true, idempotentHint=true, and destructiveHint=false, which tell the agent this is a safe read operation. The description adds the context that writes are 'gated', which aligns with the annotations and adds a small layer of transparency about the tool's purpose, but it doesn't describe any further behavioral traits like output specifics or error cases.

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 concise - a single short sentence - and front-loads the core idea of the tool. However, it could additional a bit more detail about the tool's output or specific capabilities, so it's not perfect.

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 tool is a simple capabilities overview with one optional parameter and no output schema, the description is adequate but slightly vague. An agent might wonder what exactly 'read' and 'gated writes' refer to; a brief list of capabilities or a pointer to sibling tools for detailed actions would have made it more complete.

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

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

The schema has only one optional parameter (response_format) with an enum of markdown or json, and its meaning is clear from the schema. The description doesn't need to add much; the parameter is self-explanatory. Baseline for 0 required params is 4, and the schema covers it fully.

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, 'What this unofficial MCP can read and which writes stay gated,' indicates the tool documents the capabilities of the MCP server, separating read operations from write-gated operations. However, it doesn't clearly state what specific operations or resources are covered, and it is somewhat generic compared to what could be expected from a 'capabilities' tool.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for understanding available reads and gated writes, but it doesn't explicitly mention when to use it compared to alternatives like clickbus_connection_status or clickbus_privacy_audit. No direct usage guidance or conditions 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 readOnly, idempotent, and non-destructive behavior. The description adds useful context beyond the annotations: it is a local/unofficial surface and it reports token presence and mutation defaults. This is additive and does not contradict the annotations, though it omits what the response actually contains.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded, but it reads as telegraphic fragments rather than clear prose. The 'Local doctor' metaphor and the list of states are efficient in length yet sacrifice clarity without being fully redundant.

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 no return-value explanation, the description leaves the agent guessing about the actual response shape and how response_format affects results. The safety profile is covered by annotations, but the operational contract of the tool 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?

The single parameter response_format is self-explanatory through its enum and default in the schema, but the tool description adds nothing about it. With schema description coverage at 0%, the description should compensate for parameter meaning; it 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?

The description conveys that this is a local, read-only diagnostic surface for ClickBus, reporting token presence and mutation defaults. However, it never uses an explicit verb like 'returns' or 'checks', relying on the 'Local doctor' metaphor and the tool title for the actual purpose.

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 guidance about when to use this tool versus siblings such as clickbus_capabilities, clickbus_privacy_audit, or clickbus_search_places. The phrase 'mutations off by default' hints at a safe diagnostic tool, but no when-to-use or when-not-to-use context is 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 mark destructiveHint=true and readOnlyHint=false, so the deletion behavior is disclosed. The description adds the specific file path and the requirement for explicit_user_intent, which is important behavioral context beyond the structured annotations. It does not mention recovery or side effects, but for a simple local token deletion, the provided information is adequate.

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, each carrying essential information. The action and target are front-loaded, and the critical prerequisite (explicit user intent) is stated immediately after. There is no redundant or filler content.

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 action with a single clear effect. The schema and annotations cover the parameters and destruction hint, and the description states the file path and intent gate. It lacks explicit mention of return value or success/failure reporting, but for this simple operation the current detail is mostly sufficient—an agent can safely call it knowing what happens.

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 description itself does not describe parameters, but the schema provides good coverage: both parameters are optional with defaults and clear descriptions. The explicit_user_intent parameter is directly tied to the description's 'requires explicit_user_intent' note, adding meaning. The response_format parameter is standard and its enum is self-explanatory, so no extra description is needed.

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?

Explicitly states the action ('Deletes') and the exact resource (~/.clickbus-mcp/tokens.json). This clearly distinguishes it from sibling tools like clickbus_book or clickbus_search_trips, which operate on different resources. The title also conveys logout, reinforcing the purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for logging out by deleting the local ClickBus token, which is a clear context for use. It does not explicitly enumerate alternative tools or conditions for when not to use it, but the purpose is specific enough that any agent would understand this is the logout action. The requirement for explicit user intent is a strong usage constraint.

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 that data is live, which is useful, and the 'Dedicated preview URL 404/405' suggests potential failure conditions, but this is vague. It does not contradict annotations and provides marginal behavioral context.

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 very short and front-loaded with the core purpose ('Prices and installments'). However, the second sentence about the 'Dedicated preview URL 404/405' is cryptic and unexplained, making it feel under-specified rather than cleanly concise. It earns a middle score for brevity but lacks 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 5 parameters (including two enums) and no output schema, this description is insufficient. It does not explain the meaning or options for privacy_mode or response_format, nor what the return format looks like. The 'preview' nature is ambiguous, and the 404/405 note is unexplained. An agent would not know how to interpret results or handle edge cases.

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 60% (3 of 5 params have descriptions), so the bar for compensation is moderate. The description adds no parameter-level information at all; it does not clarify privacy_mode, response_format, or even reinforce the meanings of from/to/departure_date. It leaves the two enum parameters undocumented in both schema and description, offering no value beyond the schema.

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

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

States a clear purpose: provides prices and installments from a live GET /api/v4/trips endpoint. This distinguishes it from sibling search tools that likely return full trip details, and the mention of 'preview' suggests a focused scope. However, the phrase 'Dedicated preview URL 404/405' is ambiguous and detracts from clarity.

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?

Provides no explicit guidance on when to use this tool versus alternatives like clickbus_search_trips or clickbus_search_trips_v5. The intended context (price preview) is implied but not stated, and there is no mention of exclusions or prerequisites. The cryptic '404/405' note seems to hint at failure behavior but is unclear.

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 read-only, idempotent, and non-destructive; the description adds concrete behavioral output: default redactions for street, phone, and GPS, and that 'book is off unless both gates are set'. It does not define what the two gates are, but that is a gap in detail rather than misleading behavior.

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 main verb and content, no wasted words. It communicates the essential behavior 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 read-only audit with one optional output-format parameter and no output schema, the description gives enough context about what the tool reveals and the default state of booking. It does not fully explain the 'gates' concept, but the tool is simple enough that this is a minor 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?

The single optional response_format parameter is fully constrained by the schema's enum and default, so the parameter is self-documenting. However, the description adds no meaning about response_format or how markdown/json affect the returned audit, and schema description coverage is 0%. The schema itself carries the parameter 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 uses 'Shows redaction defaults...' to specify what the audit reports, naming concrete fields (street/phone/GPS) and the booking-gating state. It is clear about the tool's purpose, but it does not explicitly distinguish this from sibling tools such as clickbus_capabilities, relying on the tool name for differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies use when an agent needs privacy redaction defaults or booking-gate status, but it does not state when to prefer this tool over alternatives or mention any exclusions. There is no explicit usage guidance, only contextual implication from 'Shows...'.

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

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

Annotations already declare readOnlyHint=true and idempotentHint=true, and the description reinforces this with 'Read-only' and 'Does not book a ticket.' This adds clear user-facing context about expected side effects beyond the raw annotation flags.

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 no filler. It front-loads the read-only nature and the place-search scope, making it easy for an agent to quickly understand the tool's purpose.

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 behavior is captured and the safety profile is well covered by annotations. However, the description omits guidance on how privacy_mode affects results and does not explicitly route the agent to clickbus_search_trips for trip-related searches, leaving moderate room for misinterpretation.

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 provides no explanation of the parameters. 'query' is somewhat self-evident, and the enums for response_format are clear, but 'privacy_mode' with values summary/structured/raw is ambiguous without additional explanation.

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 verb 'search' and the resource 'places', adding the parenthetical '(terminals/cities)' to define scope. It does not explicitly differentiate from sibling clickbus_search_trips, but 'places' vs 'trips' provides reasonable distinction.

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 'Read-only place search' and 'Does not book a ticket' imply this is for lookup rather than booking or modification. However, it does not explicitly state when to prefer this over clickbus_search_trips or provide any exclusions beyond the no-booking note.

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 'GPS/street redacted', a meaningful privacy behavior that is not present in annotations, and 'Does not book' reinforces the non-mutating nature. Some behavioral details like response format or pagination are absent, but the annotation coverage lowers the burden.

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 sentences with no filler. It front-loads the core action and endpoint, then adds the two most decision-relevant constraints ('Does not book' and 'GPS/street redacted'). Every word earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only search tool with strong annotations and a schema defining required parameters, this description is largely complete for selection and invocation. The only notable gaps are that prices are mentioned only in the title, not the description, and the meaning of privacy_mode values is left unclear. Overall, the agent has enough to call the tool correctly.

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

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

Schema description coverage is 60%, so the description is not required to fully compensate, but it still adds no parameter-level detail. The schema documents from/to and departure_date with examples and format, while privacy_mode and response_format have enums but no descriptions; the description does not explain what 'summary', 'structured', or 'raw' mean. This lands at the baseline acceptable level.

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

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

The description opens with 'Read-only trip search on /api/v4/trips', naming a specific verb and resource, and the title adds 'trips and prices'. The explicit 'Does not book' clearly separates it from booking operations, and it is easily distinguished from siblings like clickbus_book and clickbus_search_places.

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 makes it clear this tool is for searching trips and not for booking, which is a valuable when-not-to-use signal. It does not explicitly name alternative tools or conditions, but the sibling list plus the read-only framing lets an agent infer appropriate use.

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, openWorld, idempotent, and non-destructive behavior, so the description's 'read-only' and 'Does not book' largely echo that. It adds a little context by specifying the HTTP method and a JSON 200 response, but no deeper behavior such as response shaping or pagination.

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, no filler, and the most important qualifier ('Read-only', 'Does not book') is front-loaded. The structure is easy to scan.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and several overlapping siblings, the definition is too thin to fully orient an agent. It omits what the returned trip list contains, how privacy_mode and response_format affect results, and why v5 should be chosen over the unversioned search_trips 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?

The schema documents from, to, and departure_date, but the description adds no parameter meaning. privacy_mode and response_format are left as unexplained enums, and the description's 'JSON 200' does not clarify the default markdown response set by response_format, so it fails to compensate for the 60% schema coverage.

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

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

The description identifies a specific resource (GET /api/v5/trips) and primary behavior (read-only trip search) and adds an explicit safety qualifier ('Does not book'). It does not differentiate this v5 tool from the sibling clickbus_search_trips, but the core purpose is clear.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives no context for when to choose this tool over alternatives. The only exclusion, 'Does not book', is an obvious corollary of the name and is not tied to an alternative booking tool; there is also no guidance separating v5 from the plain clickbus_search_trips sibling.

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, openWorld, idempotent, and non-destructive behavior. The description adds useful context beyond that by noting the data comes from 'live trip JSON' and by explicitly disclosing a specific failure mode: full seat-map requests trigger an HTTP 500. This is honest and behaviorally relevant.

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 very compact: two short sentences with no filler. It front-loads the core data fields and then gives the key limitation. A slightly clearer verb at the start would improve it, but it is 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?

For a tool with five parameters, no output schema, and two undocumented parameters, the description is minimally viable but leaves gaps. Required parameters are covered by the schema, and the limitation statement is helpful, but an agent still lacks guidance on privacy_mode/response_format semantics and how returned data is structured.

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 only 60%, and the description adds no parameter-level guidance. The undocumented 'privacy_mode' and 'response_format' parameters are left unexplained, and the description does not clarify how 'availableSeats/totalSeats' relates to those options or what output shape each mode produces.

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 provides 'availableSeats/totalSeats' from 'live trip JSON', which communicates a seat-availability lookup for ClickBus. It does not use an explicit verb or name a sibling, but the combination of title and description makes the purpose understandable and distinct from trip search or booking tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The line 'Full seat map HTTP 500 is an honest gap' implies this tool is not appropriate for full seat-map requests and gives an important limitation. However, it does not state when to use the tool, which sibling might handle full seat maps, or any other routing guidance.

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 clear. The description adds useful scope ('Status only', no GPS polylines or passenger documents), which is genuinely informative, but it does not go into deeper behavior like response format semantics or authorization needs.

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 deliver the core behavioral constraint immediately and add only one clarifying exclusion. Every word earns its place, and the structure is ideal for rapid scanning by an agent.

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 description is too thin for a tool with three parameters, no output schema, and no parameter-level documentation. It does not explain what statuses are returned, how privacy_mode affects output, or what response_format changes, so an agent cannot confidently invoke it beyond guessing from names and enums.

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, but it provides nothing about booking_id, privacy_mode, or response_format. The agent is left with only the schema's field names and enum values, which is insufficient 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?

The description clearly identifies the action and resource: tracking a ClickBus booking. 'Status only' pinpoints the specific output scope and explicitly separates it from a broader 'tracking' interpretation (GPS polylines or passenger documents), distinguishing it from sibling tools without ambiguity.

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 for getting booking status, and it explicitly excludes certain data types, which provides some guidance on when not to use it. However, it does not name alternatives or give explicit conditions for choosing this tool over siblings like clickbus_booking_history or clickbus_connection_status.

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