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

No annotations were provided, so the description carries the behavioral disclosure burden. It discloses that the check 'bypasses the once/day throttle' and reports the availability and update instructions. This reveals a rate-limit bypass behavior and the tool's side effect of performing a network call. It does not mention potential failure modes, but for a check tool the description is adequately transparent.

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 long, with the first sentence front-loading the core purpose and behavior, and the second providing context about the daily automatic check. Every word earns its place; no filler or redundant 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?

Given zero parameters, no output schema, and no annotations, the description provides sufficient information for an agent to understand what the tool does, when to invoke it, and what it returns. It explains the bypass behavior and the nature of the report. The presence of sibling tools is addressed through the clear focus on forcing an immediate check.

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 no parameters, so the schema is empty and description adds no parameter details. Per the instructions, a 0-parameter tool gets a baseline 4. The description doesn't need to explain anything about parameters, and the schema coverage is trivially complete.

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

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

The description clearly states the action: 'Forces an immediate check against GitHub' and the outcome: 'reports whether a newer version is available plus how to update.' This distinguishes it from siblings like dismiss_update, which is about dismissing an update notification, and status, which likely shows current state. The verb 'check' is specific and the resource 'GitHub' is 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 description provides context by noting that 'normally the check runs automatically once a day', implying the tool is for when an immediate check is desired. It gives a clear scenario for use (bypassing the daily throttle) but does not explicitly name alternative tools or state when not to use it. This is solid usage guidance without being exhaustive.

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

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

With no annotations provided, the description fully discloses behavior: it records the skip state, affects get_usage, and is temporary until a newer version appears. This clarifies side effects and temporal scope without contradicting any 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?

The description is a single sentence that front-loads the call condition and immediately explains the effect. Every phrase earns its place with no redundancy.

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

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

For a simple tool with no parameters and no output schema, the description is complete: it tells when to use, what it does, and the impact on get_usage. The caveat about newer versions covers edge 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?

The tool has zero parameters, which sets a baseline of 4. The description adds no parameter-specific details (as none exist), but it conveys the tool's action and effect, which is sufficient for a no-parameter tool.

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

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

The description clearly states the tool's purpose: recording the current remote version as skipped so get_usage won't surface it. It uses specific verbs ('Call this when the user declines') and names the affected sibling tool (get_usage), distinguishing it from other 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?

Explicitly instructs when to call ('when the user declines an available update') and implies when not to call (when the user accepts). It also references get_usage as the alternative that would otherwise surface updates, providing clear contextual 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?

Given the absence of annotations, the description discloses key behavioral traits: automatic authentication via Cursor's local token, handling of needsLogin, and caching behavior with refresh support. This gives the agent comprehensive insight beyond the tool's name and schema.

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

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

The description is well-structured and front-loaded with the call timing instruction, followed by purpose and actionable conditional logic. Each sentence provides necessary information without redundancy, making it appropriately sized for the tool's complexity.

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

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

The tool has no output schema, so the description compensates by explaining the return flags (conserve, followup, needsLogin) and how to respond to each. It also covers auth and caching behaviors, making it complete enough for an agent to invoke 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?

The schema already describes the refresh parameter as bypassing the cache, and the description adds valuable context about when caching is active (once quota is exhausted until cycle resets) and why refresh would be needed. This enriches the parameter's meaning and improves correct usage.

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's function: reading the user's current Cursor usage/spend and returning conserve and followup flags. This distinguishes it from siblings like usage_breakdown, which likely provides detailed breakdowns, by focusing on the summary decision flags.

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 instructs to call this at the START of a task and provides conditional behavior based on the returned flags (e.g., using the questions/options UI when conserve is true, ending with an options question when followup is true). However, it does not explicitly mention alternatives or when not to use it beyond those conditions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses the key behaviors: opening a real browser, requiring user login, auto-discovery of endpoints, and storing the session cookie locally at ~/.cursor-usage. It could have mentioned the return/result of the tool or failure modes, but the main behavior and side effects are clearly stated.

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 three concise sentences, front-loaded with 'FALLBACK auth only.' Each sentence serves a purpose: announcing the fallback nature, specifying conditions for use, and explaining the process and outcome. No wasted words.

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's interactive nature and one parameter, the description covers the rationale, conditions, and side effects well. It does not explicitly describe return values, but the absence of an output schema is balanced by the clear behavioral outcome (cookie stored, endpoints discovered). The completeness is strong, though a brief note on results would make it fully complete.

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

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

The single parameter, timeoutSeconds, has 100% schema description coverage ('How long to wait for login + endpoint discovery. Default 240.'). The tool description itself does not elaborate on the parameter, but per the rubric, high schema coverage justifies a baseline score of 3. No additional parameter semantics are 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?

The description clearly states the tool's purpose as a fallback login mechanism, opening a real browser to log in, auto-discovering usage endpoints, and storing the session cookie. It explicitly differentiates from get_usage by stating 'By default get_usage needs no login' and 'Use this tool only when that can't work', making the specific verb+resource+scope unambiguous.

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

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

The description provides explicit when-to-use guidance, listing concrete conditions such as the MCP running on a different machine, unreadable local DB, unavailable node:sqlite, or the CURSOR_USAGE_FORCE_LOGIN environment variable. It names the alternative (get_usage) and frames login as a fallback only, which is 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?

With no annotations, the description carries full burden and does an excellent job: it discloses what gets cleared (cookie and endpoints), the optional behavior of forgetBrowser (wipe browser profile, force full re-login), and what is preserved (threshold config). This is transparent and adds meaningful context beyond the schema.

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

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

Two sentences, front-loaded with the primary action, and each sentence earns its place. No filler or redundancy.

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

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

For a simple tool with one optional parameter and no output schema, the description covers the essential behavior, the optional parameter's effect, and what is preserved. It is complete enough for an agent to select and invoke 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 coverage is 100% for the single parameter, so baseline is 3. The description adds extra semantic value by explaining the consequence of forgetBrowser=true ('forces a full re-login next time'), which goes beyond the schema's 'delete the saved Playwright browser profile'. Thus a score of 4 is appropriate.

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

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

The description states a specific verb ('Clears') and resource ('stored session cookie and discovered endpoints'), clearly distinguishing it from login and other session-related tools. It also mentions the observable effect on get_usage, making the purpose unambiguous.

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

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

The description implies when to use this tool (to force get_usage to report needsLogin) and notes that threshold config is preserved, which helps distinguish it from tools like set_threshold. However, it does not explicitly name alternative tools or exclusion cases, so it falls short of full 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?

With no annotations, the description itself discloses key behaviors: persistence (state change), default off, effect on get_usage, and the env var override. It does not mention permissions or return value, but for a boolean setter these are less critical. The description adds meaningful behavioral context beyond the tool name and title.

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 and well-structured, with the key information front-loaded. Every sentence adds value: the first explains the mechanism and effect, the second the override. No fluff or redundancy.

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

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

For a simple one-boolean setter with no output schema, the description is exceptionally complete. It covers purpose, default, effect on a related tool, and the env var override, which are the essential aspects. There is no missing critical information.

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 description must compensate. It does by explaining the meaning of the followup parameter indirectly: 'default off' and 'when on' indicate the boolean effect. However, it does not explicitly state that the followup parameter should be set to true to enable and false to disable, leaving a small 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 clearly states the tool's purpose: it persists a follow-up mode that affects get_usage's behavior. It specifies the action ('Persists follow-up mode'), the resource (end-of-task follow-up question), and distinguishes from siblings by tying it to get_usage. The default (off) and overriding env var add precision.

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

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

The description implies when to use the tool: to control whether get_usage includes a follow-up question. It notes that when on, the agent will almost always get a prompt, and that an env var can override. It does not explicitly state 'use this instead of setting the env var' or list alternatives, but the context is clear enough for a simple setter.

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

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

With no annotations, the description carries the burden of transparency. It explains the behavioral effect of the threshold value, such as 0 meaning conserve whenever a reading succeeds and requests remain, and 80 meaning conserve only near the limit. This provides meaningful insight into the tool's behavior, though it does not cover all potential side effects (e.g., persistence or authorization).

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 three concise sentences, front-loaded with the main purpose, and contains no redundant information or fluff.

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 setter with one parameter, no annotations, and no output schema, the description is sufficiently complete. It explains the parameter semantics and gives behavioral examples, covering all essential aspects needed for an agent to use 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?

The description fully explains the activationThresholdPct parameter by stating it is a usage percentage from 0 to 100 and providing examples. Since the schema has no description for the parameter, this is essential and effectively compensates for the 0% schema description 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 states specifically that it sets the minimum usage percentage at which conserve mode activates. This is a clear verb+resource pair, and it distinguishes from sibling tools like set_verbose or set_followup.

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 clear context by explaining the default (0) and giving an example (80), but it does not explicitly discuss when to use this tool versus alternatives. However, the given examples imply appropriate usage scenarios.

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

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

With no annotations, the description must disclose behavior. It reveals that the mode persists, affects get_usage's output, and can be overridden by an environment variable. This is valuable context, though it does not mention return values or side effects beyond the setting itself.

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 exactly two sentences, front-loaded with the core action and followed by a relevant conditional nuance. Every word earns its place with no redundancy or 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?

For a single-boolean setter with no output schema, the description covers the essential behavior: persistence, effect on get_usage, and the override condition. It omits where the setting is stored or the exact return value, but these are not critical for understanding how to invoke the 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 only defines 'verbose' as a required boolean with zero description. The tool description explains that 'on' results in a footer from get_usage and mentions the env var override, giving the parameter meaningful context. This compensates well for the lack of schema documentation, though it does not specify defaults or edge cases.

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

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

The description clearly states the action ('Persists verbose mode') and the target resource (per-message usage footer), with the title reinforcing the enable/disable function. It is easily distinguished from sibling tools like set_threshold or set_followup.

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

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

The description implies when to use the tool—when you want to enable or disable the usage footer—but it does not explicitly contrast with alternatives or state when not to use it. The relationship with get_usage is clear, but no exclusions or alternate tool references 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?

With no annotations, the description carries the full burden of behavioral disclosure. The word "Reports" implies a read-only operation and enumerating the reported items adds useful context. However, it does not explicitly state that the tool makes no changes, nor does it mention any side effects, permissions, or output format. It provides moderate transparency but leaves the read-only nature implicit.

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

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

The description is a single, front-loaded sentence. It begins with the verb "Reports" and then lists the key information categories without unnecessary filler. Every word earns its place, achieving high conciseness.

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

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

Given that the tool has no parameters and no output schema, the description provides a complete enumeration of the report content (auth source, session/endpoints, thresholds, etc.). It could go further by explicitly noting the read-only nature or how the output is presented, but for a status-reporting tool, the listed categories offer adequate completeness for an agent to decide when to invoke 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?

The tool has zero parameters, so the schema already fully defines the input interface (empty object). Per calibration, the baseline for 0 parameters is 4. The description adds no parameter-specific information because none is needed, and it correctly focuses on what the tool reports rather than input details.

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

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

The description clearly states the tool's purpose with a specific verb ("Reports") and enumerates the exact resources it covers: auth source, stored session/endpoints, thresholds, verbose/follow-up settings, and usage-cache age/cycle. This distinguishes it from siblings like get_usage (which reports usage) and set_threshold (which modifies settings).

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

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

There is no guidance on when to use this tool vs alternatives. The description simply states what it reports but does not mention prerequisites, exclusions, or alternative tools like get_usage or set_threshold. Usage context is only implied (checking configuration status) rather than explicitly 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?

No annotations are provided, so the description carries the full burden. It discloses the temporal scope (billing cycle), the grouping (by model), the output metrics, and a key behavioral trait: it is heavier than get_usage. However, it does not explicitly state read-only/non-mutating behavior, though 'shows' implies 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 sentences, each earning its place: output description, usage trigger, and performance caveat. Front-loaded with the core purpose, no redundancy.

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

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

For a zero-parameter tool with no output schema, the description is remarkably complete: it covers what it returns, when to use it, and how it compares to the sibling tool. No essential context 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?

The tool has zero parameters, so the baseline is 4. The description adds context about the output breakdown but no parameter details are needed since there are none.

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 shows this billing cycle's usage broken down by model, including specific metrics (cost, request count, token totals). The verb 'shows' and the resource 'usage breakdown by model' are specific and the tool is distinguished from get_usage by the granularity of the breakdown.

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?

Explicit when-to-use guidance is provided: 'Use when the user asks what's costing them or which models they use most.' It also names an alternative (get_usage) and gives a performance-based exclusion: 'Heavier than get_usage, so call it on request rather than every task.'

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