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

Beyond the annotations (which only declare it writes, is open-world and non-idempotent), the description discloses the up-front validation pass, the all-or-nothing semantics when the batch doesn't fit, the human-confirmation gate, and precise partial-failure behavior including which error classes stop the batch and mark remaining jobs "skipped". That is exactly the non-obvious behavior an agent 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?

Dense and front-loaded: what it does, the job shape, the validation/confirm rule, then the return contract and failure semantics in order of need. The embedded JSON snippet wraps awkwardly mid-line, but no sentence 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?

For a batch mutation tool with no output schema and an untyped `jobs` array, the description supplies the job structure, the return keys ("results", "submissions_planned", "usage"), and failure handling. What "submissions" or "today's budget" mean in units is left to grok_usage, 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?

With 0% schema description coverage, the description carries the load and does: it enumerates the full job object shape including bounds and defaults (`n` 1..4 default 1) and lists all optional keys. The only gap is the top-level `out_dir`, which is only implied via the identically named job-level field, and `confirm_over` is referenced but not shown as a parameter.

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 gives a specific verb and resource — "Run several image jobs one after another" — which clearly distinguishes it as the batch counterpart to grok_generate_image. It doesn't explicitly name the single-image sibling as the alternative, but the batch framing makes the split obvious.

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 conditions for the `confirm` flag ("ask the user first" above `confirm_over` submissions) and explains that budget/no-extension errors halt the batch. It never states outright when to prefer grok_generate_image over this one, nor the preconditions for a job to be accepted beyond the fit check.

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

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

Annotations already flag non-readonly, non-idempotent, open-world behavior; the description adds substantial value beyond them: it discloses auth model (browser session, no API key), quota-enforcement refusal, that missing page controls yield a warning rather than failure, and that output files are never overwritten. That is exactly the behavioral context an agent needs before spending the user's quota.

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 but front-loaded: environment/auth context first, then parameter rules, then file naming and return shape. Nearly every clause earns its place, though the parameter block reads as a run-on list and could be marginally tighter.

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 correctly documents the return object keys (files, kept, generated, submissions, aspect_ok, secs, sizes, warning) and the on-disk naming convention. Combined with defaults and quota behavior, an agent has everything needed to invoke and interpret 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?

Schema coverage is 0% with 10 parameters, so the description carries the full burden and does: enumerates aspect ratios, n's 1..4 range and the 2-images-per-submission mechanic, mode values, max_side semantics, size's exact WxH with cover+crop behavior and override relationship, keep_original, and out_dir resolution. It also names which parameters fall back to grok_settings defaults.

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 (generate images with Grok Imagine) plus the execution context (user's logged-in Chrome, no API key). This clearly separates it from grok_generate_video and the other sibling tools like grok_usage/grok_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?

Gives operational context: quota-backed via the user's own plan, jobs over limits are refused, and points to grok_usage() and grok_settings for limits/defaults. It does not explicitly say when to prefer grok_generate_image over grok_batch or grok_generate_video, so it stops short of full alternatives routing.

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

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

Goes well beyond the annotations (readOnly=false, openWorld=true, non-idempotent): it warns the tool depends on a frequently-changing web UI, flags the quota cost relative to images, notes the daily cap, and discloses the return shape. That is exactly the operational risk context the annotations cannot convey.

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?

Five dense sentences, front-loaded with the EXPERIMENTAL warning and cost caveat; no filler, and the return shape is compressed to a single fragment.

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 6-param mutation tool with no output schema and no annotations on cost, the description covers output shape, quota risk, and fragility. It falls short only on the undocumented optional parameters (notably aspect and timeout behavior), which an agent may need before invoking.

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 carries the burden; it explains prompt and image_path (with accepted formats jpg/png/webp) and hints at output via 'mp4 path'. However, name, aspect, out_dir, and timeout_s get no meaning at all, and 'aspect' is genuinely consequential for video generation, so compensation is only partial.

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+resource ('make a Grok Imagine video'), adds duration (~6 s) and an optional image-to-video mode, which distinguishes it from the sibling grok_generate_image. An agent can tell exactly what this produces without opening the 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?

Sets clear context: experimental, costly in quota, capped by max_videos_per_day, and routes the agent to grok_usage for limits. It does not explicitly say 'use grok_generate_image for stills instead', so the alternative-routing is implied rather than 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?

Annotations already declare the mutation as idempotent, non-destructive, and closed-world, so the description does not need to repeat safety basics. It adds the important partial-update behavior ('omitted values stay as they are'), but does not cover validation, authorization, or what happens when limits are lowered or raised.

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 tight sentence with the key condition and the partial-update rule front-loaded. There is 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?

For a four-parameter mutation tool with no parameter descriptions and no output schema, the definition is too sparse. Annotations cover safety traits, but an agent still lacks enough detail about the parameters and the effects of changing daily limits.

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 carry parameter meaning. It only explains that omitted values remain unchanged, and never clarifies what confirm_over means or how the three max_* limits should be interpreted.

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 (Change) and resource (daily Grok quota guard), making the tool's purpose clear. It does not explicitly differentiate itself from siblings such as grok_settings or grok_usage, but the limits focus is reasonably distinct.

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 a useful condition ('only when the user asked for it'), but does not name alternatives, explain when not to use it, or relate it to grok_settings/grok_status. The guidance is implied rather than fully explicit.

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

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety is covered. The description adds genuine context beyond that: the precedence order (defaults < config.json < env vars), the fact that values are read at server start, and the operational consequence that a client restart is needed after changes.

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 compact sentences, zero filler, with the precedence rule front-loaded and the operational caveat placed last where it belongs. Every clause carries information an agent would otherwise have to guess.

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 does the necessary work by stating that the result includes effective values, their sources, and per-setting descriptions. That is sufficient to call and interpret the tool; only the exact output shape is left unspecified, which is 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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate and it correctly does not invent any arguments.

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 resource and scope: the settings currently in effect, plus each value's origin and meaning. It is clearly a read/inspection tool, though it never names or contrasts itself with siblings such as grok_status, which likely overlaps in reporting server state.

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 rather than stated: an agent gathers this is for inspecting configuration, and the note about restarting the MCP client implies this is a diagnostic/verification step. There is no explicit 'use this instead of X' guidance against grok_status or grok_set_limits, which matters given the sibling list.

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, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds real value beyond that by disclosing the exact diagnostic dimensions being probed (extension connectivity, tab presence, login state), which tells the agent what a failure would mean. It does not describe the shape of the response (booleans vs. a status string), which keeps it from 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?

A single front-loaded sentence that labels the category ('Bridge health') and then enumerates the checks. No filler, no restatement of the title, nothing that could be cut.

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-only, idempotent diagnostic with no output schema, an agent needs only to know what is being checked and that it is safe to call repeatedly — both are supplied. The absence of return-format detail is a small gap, but nothing required to invoke the tool correctly 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 takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-param tool is 4. Schema coverage is 100% and the empty object schema is unambiguous.

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 resource (the bridge / Chrome-extension connection to grok.com) and enumerates the three concrete conditions it reports on: extension connected, imagine tab open, user logged in. That is far more specific than the bare name or the 'Bridge status' title, so an agent knows exactly what question this tool answers. It stops short of explicitly contrasting itself with siblings such as grok_usage or grok_settings, so it lands at 4 rather than 5.

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

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

Usage is only implied: an agent can infer this is a pre-flight/health check to run before grok_generate_image, grok_batch, or grok_generate_video, but the description never says 'call this first' or 'use this to diagnose failures.' There are no stated exclusions or named alternatives, so the routing decision is left to inference.

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, non-destructive and closed-world, so the safety profile is fully covered. The description adds genuinely new context the annotations lack: the temporal scope is limited to 'today' and the tally is broken down into specific counters (submissions, generated, kept, videos). It does not discuss refresh cadence or reset timing, which keeps it below 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?

A single sentence with the scope ('today's') front-loaded and zero filler. Every clause carries information about what is measured.

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 no-argument, read-only usage snapshot with rich annotations there is little else needed. The description covers what is counted and the time window. Lacking an output schema, it could have sketched the returned fields or the limit/reset shape, which is the only real 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?

The tool takes zero parameters, so the baseline is 4. The description correctly does not invent argument semantics and instead spends its words on what the no-argument snapshot returns.

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 (today's Grok Imagine usage) and enumerates the exact metrics counted: image submissions, images generated/kept, videos, measured against daily limits. That is far more precise than a name restatement and separates it from grok_set_limits and grok_status. It stops short of explicitly naming a sibling, keeping it at 4.

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?

Reading the description makes the intended use (check today's consumption versus caps before submitting more work) reasonably obvious, especially next to grok_set_limits. However, there is no explicit when-to-use statement, no mention of the sibling that changes limits, and no prerequisites or exclusion guidance.

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