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

With no annotations, the description carries the full burden and does so unusually well: all-or-nothing pre-validation against today's budget, per-job error isolation with batch continuation, and the exception class (budget/no-extension) that halts the run and marks remaining jobs 'skipped'. That is exactly the failure-mode detail an agent needs before spending budget.

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?

Front-loaded with the core action, then preconditions, then return/failure semantics — a sensible ordering with no filler. The inline job-object spec is dense and hurts readability slightly, but every line carries information.

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

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

No output schema exists, and the description compensates by describing the return shape and skipped/error semantics. But several documented job fields (mode, size, max_side, keep_original, name) are named without any meaning, and `confirm_over` is never sourced — significant gaps for a zero-coverage nested schema on a costly generation 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 0% and `jobs` is an untyped array of free-form objects, so the description does the schema's job by enumerating job keys (prompt, name, aspect, n 1..4 default 1, mode, max_side, size, keep_original, timeout_s, out_dir). It loses a point for leaving `confirm_over` as a dangling reference not defined here, and for not distinguishing top-level `out_dir` from the per-job `out_dir`.

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

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

States a specific verb and resource: running several image jobs sequentially as a single batch. It is clearly distinguishable in intent from grok_generate_image (single job), though it never names the sibling or explicitly contrasts with looping the single-job 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?

Usage is implied by the batch framing and the description gives real operational preconditions (whole batch validated first, confirm=true required above `confirm_over` submissions, ask the user first). However, it never states when to prefer this over calling grok_generate_image repeatedly, nor 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?

With no annotations, the description carries the full burden and does so: it discloses that a missing page control in quality mode yields a warning rather than a failure, that files are never overwritten, that n=3/4 costs two submissions, and where files land. It also enumerates the return keys, so the agent knows what success and partial success look like.

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?

Purpose and quota constraint are front-loaded, then parameters are covered in a terse, scannable per-parameter list. For a 10-parameter tool with no schema descriptions, every line carries information; nothing is padding.

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, and the description compensates by listing the return keys and the optional sizes/warning fields. Combined with the quota, overwrite, and default-behavior notes, an agent can call this correctly; only timeout_s semantics and explicit error (as opposed to warning) behavior are left unaddressed.

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% for 10 parameters, so the description must compensate, and it explains most of them: aspect enum values, n range and its submission cost, mode values and failure semantics, max_side, size (with an explicit precedence rule over max_side), keep_original, and out_dir resolution. Gaps remain for timeout_s (only covered by the generic "configured defaults" remark) and name, which is explained only obliquely through the file-naming pattern.

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 first sentence names a specific verb and resource ("Generate images with Grok Imagine") plus the execution mechanism (user's logged-in Chrome, no API key), which is far more than a restatement of the name. It implicitly separates itself from grok_generate_video by naming the medium, but never explicitly routes the agent away from siblings such as grok_batch.

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

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

It gives concrete prerequisites and guardrails: quota is drawn from the user's own Grok plan, over-limit jobs are refused, and the agent is pointed at grok_usage() and grok_settings for limits and defaults. It stops short of stating when to prefer grok_batch or what to do on refusal (retry later vs. reduce n).

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 and does well: it discloses the experimental/fragile nature (Grok's web UI changes often), the quota cost and daily cap, and the return shape. It omits whether the call blocks, how timeout_s behaves, or failure modes, keeping it below a 5.

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?

Dense and front-loaded: the EXPERIMENTAL warning leads, then capability, then cost/cap caveats, then return format. Nearly every sentence earns its place; minor length comes from the parenthetical file-format note.

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?

Return shape is given despite no output schema, and the cost fragility is covered. However, four of six parameters remain unexplained, which for a tool with this much quota risk is a meaningful gap in what an agent needs before calling.

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

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

Schema description coverage is 0% across 6 parameters, so the description must compensate — yet it only explains prompt and image_path (with accepted formats). name, aspect, out_dir, and timeout_s are left entirely undocumented in both schema and description.

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

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

States a specific verb and resource ('make a Grok Imagine video ... from a prompt'), gives the output duration (~6 s), and describes an optional image-animation mode. An agent can distinguish this from grok_generate_image without opening either schema.

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

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

Explicitly flags the tool as EXPERIMENTAL, warns that videos cost much more quota than images, and points to grok_usage / max_videos_per_day for caps. It doesn't say 'prefer grok_generate_image for stills', but the cost comparison effectively routes the agent.

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

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

With no annotations, the description carries the full burden. It usefully discloses partial-update semantics ('Omitted values stay as they are'), which is real behavioral value for a mutation tool. It says nothing about permissions, reversibility, validation ranges, or how an explicit null differs from omission — a meaningful ambiguity given every parameter is nullable.

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 clauses, front-loaded with the action and its guard condition; every sentence earns its place. Minor loss for the undefined 'quota guard' term occupying the prime position.

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 no annotations, four entirely undocumented parameters, and no output schema, the description is far too thin. An agent cannot infer valid ranges, the meaning of confirm_over, or the result of the call.

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

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

Schema description coverage is 0%, so the description must compensate and it does not: confirm_over, max_jobs_per_batch, max_videos_per_day, and max_image_submissions_per_day are never explained. The one semantic hint it gives ('Omitted values stay as they are') actually leaves the null-vs-omitted distinction unresolved rather than clarifying it.

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 ('Change') and resource ('daily Grok quota guard'), which distinguishes it from read-only siblings like grok_status, grok_usage, and grok_settings. However, 'quota guard' is vague and never maps to the four concrete limit fields the schema exposes.

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 constrains invocation with '(only when the user asked for it)', which is a clear when-to-use gate. It does not name an alternative tool, but no sibling performs the same mutation, so the routing risk is low.

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 and discloses important behavior: precedence order (defaults < config.json < environment variables), provenance reporting, and that settings are read only at server startup. It does not explicitly state that the tool is read-only, but the introspection framing makes that clear enough.

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 what the tool reports and followed by the key lifecycle caveat. Every sentence earns its place with no redundant or filler text.

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, parameterless introspection tool with no output schema, the description explains both the returned content and the startup/restart behavior. It could be more complete by explicitly routing the agent away from grok_set_limits or grok_status, but the core information is present.

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, which establishes a baseline of 4. The description correctly does not invent parameter semantics where none exist.

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

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

The description clearly identifies the resource and returned content: current settings, their precedence sources, and what each setting does. It lacks an explicit verb like 'returns' and does not name or distinguish itself from related siblings such as grok_set_limits or grok_status.

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 the purpose: inspect current settings and their provenance. The note that settings are read at server startup and require an MCP client restart after changes adds operational context, but there is no explicit when-to-use guidance or comparison to alternatives like grok_set_limits.

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 burden; it does disclose what is inspected (extension, tab, auth state), implying a read-only probe, but says nothing about cost, latency, or whether it can have side effects such as opening a tab.

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 naming the subject and then the three checks; no filler or repetition.

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, the description must convey what comes back, and it does by listing the three status questions. What's missing is the return shape (booleans vs. messages) and any recommended follow-up on failure.

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?

Zero parameters and 100% schema coverage, so there is nothing for the description to disambiguate; baseline 4 applies.

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

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

States a specific resource (bridge health) and enumerates the concrete conditions it checks: Chrome extension connection, grok.com/imagine tab, and login state. This distinguishes it from generation/settings siblings, though it never explicitly frames itself as a diagnostic/preflight check.

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 a preflight diagnostic to run before grok_generate_image or grok_batch, but no when-to-use or when-not-to-use guidance is stated, nor is any sibling named.

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 must carry the behavioral burden. 'Today's ... usage ... against the daily limits' establishes a read-only, day-scoped snapshot with no mutation, but it does not explicitly state that nothing is modified, does not mention rate limits, permissions, or whether the window resets at a specific time.

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

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

A single compact sentence, front-loaded with the resource and followed by the exact metric list, with zero filler. The parenthetical enumeration is dense but readable.

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 query with no output schema, the description does the work the schema cannot: it enumerates the returned fields (image submissions, images generated/kept, videos) and the comparison basis (daily limits). Only the exact return shape and reset semantics remain unspecified, which is minor 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 nothing to document; the schema is empty and the description correctly adds no parameter claims. Baseline 4 applies for a parameterless 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 names the specific resource (Grok Imagine usage) and enumerates the metrics reported: image submissions, images generated/kept, and videos, all measured against daily limits. It is clearly a read-only quota-report tool, distinguishable in substance from grok_set_limits, though it never names that sibling explicitly.

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

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

Usage is only implied – the 'against the daily limits' framing suggests checking quota before calling grok_generate_image or grok_generate_video, but the description never says when to use this versus grok_status or grok_settings, and offers no exclusions.

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