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

No annotations are provided, so the description carries the full burden. The verb "Check" and the returned metrics imply a non-mutating read, and the description does disclose the all-accounts behavior, but it says nothing about authentication requirements, rate limits, or whether values are cached/live.

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, no filler, with the core metrics front-loaded and the account-scoping special case appended. Every clause earns its place.

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

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

For a one-parameter read tool with no output schema, the description usefully enumerates what comes back (usage, quota %, remaining requests, spend), which compensates for the absent output schema. It stops short of describing formats or units, leaving a minor 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 100% and the single account parameter is fully documented in the schema, including the 'all' value and the default (currently active account). The description's mention of account='all' repeats schema content rather than adding syntax or edge-case meaning, so the baseline of 3 applies.

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

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

States a specific verb ("Check") and enumerates the exact resources surfaced: weekly usage, quota percentage, remaining requests, and on-demand spend, scoped to Cursor / Grok Bot accounts. No sibling tool overlaps this concern, so an agent can distinguish it immediately from switch_account, list_bots, and the transcript 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 second sentence covers what account='all' returns, but that is parameter behavior, not usage guidance. There is no statement of when to call this tool versus other account tools, no prerequisites, and no exclusions.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, but it only restates that a bot is created. It says nothing about side effects, whether names must be unique, what permissions are needed, or what happens to any conflicting existing bot.

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 efficient sentence with the action front-loaded and no filler. It is appropriately sized for a two-parameter creation tool, though it is not maximally information-dense.

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 creation tool with full schema coverage the description is close to adequate, but with no output schema it should have said what comes back (e.g. a bot ID needed for send_message or get_transcript) and whether the description field is optional despite name being required.

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%, so both parameters are already documented in the schema with examples, and the description adds nothing beyond a paraphrase of them. Baseline 3 applies when the schema does the heavy lifting.

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: 'Create a new Grok Bot agent instance', and names the two inputs that define it. It is clear on its own, but does not explicitly differentiate itself from siblings like list_bots or delete_bot, leaving the agent to infer the distinction from the names.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g. account context, quotas) and no reference to alternative tools such as search_bots for finding existing bots before creating one. Usage is only implied by the verb 'create'.

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 does say 'Permanently', which correctly signals irreversibility, but it omits whether auth/ownership is required, whether related data is deleted, and whether the operation is idempotent or fails on missing IDs. For a destructive tool with zero annotation coverage, this is thin.

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 compact sentence, front-loaded with the verb and the irreversible nature of the operation. No filler or redundant clauses.

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 destructive operation with no annotations, no output schema, and no guidance on preconditions or side effects, the definition is incomplete. It answers what the tool does but leaves the agent without the context needed to call it safely.

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% and the single agentId parameter is fully documented in the schema itself. The description repeats the 'by its agent ID' idea but adds no syntax, format, or sourcing guidance beyond the schema. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

States a specific verb ('Permanently delete') and resource ('Grok Bot agent') plus the identifier used to target it. It's clear against siblings like create_bot and list_bots, though it doesn't explicitly name an alternative. The output would be stronger if it clarified irreversibility vs a soft-delete sibling, but there is no such sibling here.

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 only says what the tool does, not when to use it. There is no condition for choosing delete_bot over other bot operations, no prerequisite (e.g., ownership or confirmation), and no warning about when not to use it. With a destructive delete, the absence of usage guidance is a notable gap.

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 supplied, so the description carries the full behavioral burden. It does disclose ordering (chronological), which is useful, but says nothing about pagination semantics, default vs. maximum limit behavior, error handling for unknown agent IDs, or whether the read is non-destructive.

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, well-formed sentence with the resource and ordering constraint front-loaded and no filler. Nothing could be removed without losing information.

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

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

With no annotations and no output schema, the description is thin for a tool whose key ambiguity is how `limit` interacts with chronological order (first 50 vs. last 50 messages). It is minimally adequate but leaves meaningful interpretive gaps for an agent to resolve.

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

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

Schema description coverage is 100%, so the meanings of agentId and limit are already fully documented in the schema. The description adds no extra parameter nuance (e.g., whether limit truncates the newest or oldest messages), so the baseline of 3 is appropriate.

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

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

The description states a specific verb (Read), an unambiguous resource (conversation transcript), a scope (a Grok Bot agent), and an ordering guarantee (chronological). It is clear, though it never distinguishes itself from the sibling read_transcript_entries, so an agent must guess which transcript reader applies.

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

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

There is no statement of when to use this tool versus read_transcript_entries or search_messages, and no prerequisites (e.g., needing a valid agentId) are mentioned. Usage can only be inferred from the name and the agentId requirement.

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. It discloses the return fields (agent IDs, names, origins, descriptions) and the scope (running or registered on this machine), but says nothing about the read-only nature, ordering, pagination, or permissions, which is a gap for an annotation-free 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?

Two tight sentences with the action and scope front-loaded and the return contents following. 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?

No output schema exists, so the description rightly enumerates the returned fields, and with zero parameters and no annotations there is little else required. It could add read-only/pagination notes but is largely sufficient for a simple list 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 tool takes zero parameters, so the baseline is 4. There are no parameters whose semantics need explaining, and the description correctly implies a parameterless enumeration.

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

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

The description gives a specific verb and resource ("List all Grok Bot agents") and scopes it ("currently running or registered on this machine"). It is clear what the tool does, though it does not explicitly name how it differs from the sibling search_bots beyond the word "all".

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

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

Usage is only implied: an agent can infer this is the unfiltered enumeration of bots, in contrast to search_bots. There is no explicit when-to-use/when-not-to-use guidance or named alternative, so the agent must infer the choice.

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 behavioral burden. It does disclose the return content (agent IDs and file sizes) and implies a read-only listing, but says nothing about permissions, ordering, or behavior when no databases exist.

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

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

A single sentence with the resource and scope front-loaded and the output content appended. Nothing is wasted and nothing needs trimming.

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

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

For a zero-parameter read tool with no output schema and no annotations, the description covers what it is, where it looks, and what it returns. Only minor gaps remain, such as ordering or the empty-result case, which are low-stakes 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 tool takes zero parameters, so there is no parameter semantics for the description to add. Baseline 4 applies; the description cannot be penalized for omitting parameter detail that does not exist.

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

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

Specific verb ('List') and resource ('local Grok Bot SQLite database files on this machine'), plus the returned fields (agent IDs, file sizes). It implicitly separates itself from logical-entity siblings like list_bots by scoping to filesystem database files, but it does not explicitly name how it differs from them.

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

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

No when-to-use guidance, no prerequisites, and no alternatives named. With siblings such as list_bots and search_bots in the same family, the agent is left to infer when a database listing is the right call.

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 behavioral burden. It does disclose meaningful traits — direct local SQLite access, raw (unprocessed) entries, no network calls — which is more than the schema offers. However, it omits permission/auth needs, whether results are ordered or truncated, and what 'raw' changes versus a formatted transcript.

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, tightly written sentence that front-loads the verb and resource with zero filler. Nothing could be removed without losing information.

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

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

For a 2-parameter tool with no annotations and no output schema, the description covers the what and the local-access nature but leaves the return shape, entry ordering, and the semantics of 'raw' vs. a formatted transcript unexplained. Adequate but with clear gaps for an agent deciding between this and get_transcript.

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%, so both agentId and limit are already documented by the schema, including the default of 100. The description adds no parameter-level detail beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb (read) and resource (raw transcript entries) with scope (a bot's local SQLite database). It gestures at a distinction from network-based fetching ('without network overhead') but never names the obvious sibling get_transcript, so sibling differentiation is left to inference.

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

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

No explicit when-to-use guidance, no prerequisites, and no named alternative even though get_transcript is an obvious candidate. The 'without network overhead' phrase hints at a rationale but never tells the agent when this tool should be preferred over the network-based 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?

No annotations are provided, so the description carries the full burden. It doesn't disclose match semantics (substring, case sensitivity), result limits, pagination, empty-result behavior, or ordering. Only the searchable fields are hinted at.

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 verb and resource, no filler. Slightly abbreviated but nothing wasteful.

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 search tool with no annotations and no output schema, the description should say more about matching behavior and result handling (limits, ordering, empty results). The name/description scope is there but the behavioral envelope is absent.

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 'query' parameter, giving a baseline of 4 for zero/one-parameter tools with full schema documentation. The description adds context that the keyword targets name or description, which is modest value beyond the schema's 'Search query keyword'.

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?

Clear verb ('Search') and resource ('Grok Bot agents'), with scope narrowed to name/description fields. It distinguishes itself from list_bots (no filter) and search_messages (different resource), though it doesn't explicitly name the alternative.

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

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

Usage is implied by 'search ... matching a keyword', suggesting use when you have a keyword rather than browsing. But there's no explicit when-to-use vs list_bots or statement of what happens when no match is found.

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 behavioral burden, yet it does not state how matching works (substring, whole word, case sensitivity), whether it searches user and bot messages, or how results are ordered. Only the scope ('all local bot transcripts') is disclosed, leaving meaningful behavioral gaps for a search operation.

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

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

A single front-loaded sentence with no filler or redundancy. It is efficient, though the brevity contributes to the missing behavioral detail noted elsewhere.

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 two-parameter tool with no output schema and no annotations, the description covers scope but omits match semantics and result shape. It is the minimum viable amount of information to call the tool, but not enough for the agent to predict what comes back.

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

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

Schema description coverage is 100%, so both the 'query' keyword and 'limit' default are already documented in the schema. The description adds only the notion that the query is a keyword compared against transcripts, which is marginal beyond what the schema states – baseline 3 applies.

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

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

States a specific verb (search) and resource (messages across all local bot transcripts), with the scope 'all local bot transcripts' implicitly distinguishing it from get_transcript and read_transcript_entries, which operate on a single transcript. It does not explicitly name those siblings, so the differentiation is inferable rather than stated.

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

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

The description gives no when-to-use guidance and names no alternatives, so the agent must infer that keyword lookup is preferable to get_transcript or read_transcript_entries. No exclusions or prerequisites 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?

No annotations are provided, so the description carries the full burden. It hints at synchronous behavior ('receive its response') but omits whether the message is persisted in the transcript, whether the call blocks until completion, timeout/rate-limit behavior, and what happens on agent errors.

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

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

A single front-loaded sentence with no filler. Every element earns its place: the action, the target, and the fact that a response is returned.

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

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

For a two-parameter tool with no output schema and no annotations, the description covers the core action but leaves return shape, blocking behavior, and side effects unstated. It is minimally viable rather than complete.

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

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

Schema description coverage is 100%, so 'agentId' and 'message' are already documented in the input schema. The description adds only the framing of 'message or user prompt' and does not extend parameter meaning further, making the baseline 3 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 (send) and resource (message/user prompt to a Grok Bot agent) and even notes the response comes back. It clearly separates this from siblings like search_messages or get_transcript by naming the distinct resource type, though it never explicitly contrasts itself with those siblings.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The agent must infer that this is the tool for interacting with a bot versus reading transcripts or searching messages.

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 behavioral burden. It usefully discloses one side effect ('Next time you open the Grok Bot desktop app, it will launch directly into this account'), but says nothing about auth/permission requirements, reversibility, or whether an in-flight CLI session is affected. Partial disclosure only.

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 tightly written sentences, front-loaded with the core action and scope, then the persistence detail. Every sentence 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 single-parameter, no-output-schema tool this covers purpose, scope, and the key persistence effect. It could still note whether an active session is disrupted or what happens to the previously active account, but the definition is adequate for a low-complexity 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?

Schema coverage is 100% and the 'account' parameter is well documented in the schema with examples ('main', 'company'). The description adds no meaning beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb ('Switch') and resource ('the active account') with explicit scope: Cursor / Grok Bot across CLI/MCP and the macOS desktop app. This clearly distinguishes it from the bot/message-oriented siblings like list_bots and send_message.

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 the tool is relevant (to change the active account) but offers no explicit when-to-use rules, prerequisites, or alternatives. No sibling competes for this function, so the omission is minor, but guidance is only implied.

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