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

No annotations are provided, so the description carries the full burden, and it largely does: it enumerates what is reported (key label, usage today/week/month/total, spending limit, remaining credit) and handles the in-progress sign-in case with a status and link. It stops short of stating prerequisites (e.g. behavior when not signed in) or read-only guarantees.

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

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

Four short sentences, front-loaded with the core purpose followed by returned data, usage triggers, and the no-parameter note. Every sentence adds something, though the return-value inventory is somewhat list-heavy.

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 must explain returns, which it does in detail, and it supplies usage triggers. It is close to complete for a zero-parameter status tool, missing only edge-case behavior such as the not-signed-in response.

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 sets a baseline of 4, and the description usefully confirms this with 'Takes no parameters.' There is nothing further to document.

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 ('Show whether this computer is signed in to OpenRouter, with the key's spending') and is clearly distinguishable from siblings like auth_login/auth_logout, which are actions on the same auth state. An agent can tell what this returns 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?

Gives explicit triggers: 'after auth_login to confirm sign-in finished, or when the user asks about cost, usage or credits.' It names the sibling it follows but does not state when *not* to use it or contrast it against any alternative status source, so it falls short of the 5 bar.

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 and does so: it returns at once with a link, the link contains no secret, the new key goes to the OS credential store and is never shown, and it is idempotent unless switch_account is true. It even discloses that the current key is retained during a switch.

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 behavior and the link-return contract, then the follow-up step, then the parameter note. Slightly verbose in places (the secret/link caveat), but nearly every sentence 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?

No output schema exists, and the description explains what the tool returns (an immediate link) plus the follow-up confirmation flow. An agent has everything needed to invoke it correctly and handle the result.

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%, but the description fully compensates for the single parameter: switch_account signs in as a different account or workspace, and the current key is kept until the new one is stored. This is meaningful semantics beyond the schema's bare boolean.

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 (sign in to OpenRouter in the user's browser) and describes the actual mechanism (opens the sign-in page, returns a link). It also distinguishes itself from siblings by naming account_status as the confirmation step.

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 explicit when-to-use guidance: finish in the browser, then call account_status to confirm; show the link if the browser didn't open; no-op if already signed in unless switch_account is true. The alternative action (auth_logout) is implicitly separated by the sign-in framing.

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 it delivers a non-obvious behavioral fact: the local key deletion does NOT invalidate the key on OpenRouter, which must be deleted on the dashboard. It also notes the result links that page. It stops short of describing any failure modes or side effects.

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 action verb and core effect, followed by the important caveat about remote key validity. Every sentence adds value; the 'Takes no parameters' line is mildly redundant given the schema but harmless.

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 logout tool, the description covers what happens locally, what does not happen remotely, and what the result contains. No output schema exists, yet it adequately signals the return. 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 tool takes zero parameters, so the baseline is 4. The description reinforces this with 'Takes no parameters,' which is consistent with the empty schema and leaves no ambiguity.

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 ('Sign out') and the concrete action ('delete the stored OpenRouter key from this computer'), making the resource and effect unambiguous. It is clearly distinguishable from its counterpart auth_login and the other image-related 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?

The intent (sign out) is implied clearly enough that an agent will know when to call it, but there is no explicit when-to-use vs when-not guidance or reference to alternatives such as auth_login. Usage 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?

With no annotations, the description carries the full burden and does so richly: third-party upload and consent requirement, per-call monetary cost billed to the user's OpenRouter account, absolute-path enforcement with relative paths rejected, non-overwriting save behavior plus JSON sidecar, and the n-above-max splitting into multiple billed calls. It even discloses an edge-case artifact (visible lighting seam at the mask edge) and how to mitigate it, plus the <result>.unmasked.png artifact saved for remask_image.

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 a one-line purpose, then a prerequisites/behavior paragraph, then a clean per-argument Args block that mirrors the parameter order. It is long, but the length is largely justified by 17 undocumented parameters; a few behavioral details (mask seam, previews) could be tightened.

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 enumerating the returned payload (saved paths, notes, failures, model, provider, time, cost, JPEG previews) and where files land. Given 17 params, cost implications, and a third-party data flow, nothing an agent needs to call this correctly appears 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?

Schema description coverage is 0% across 17 parameters, so the description must compensate and it does so for every argument: prompt example, images ordering semantics (first = edited, rest = references), mask white/black convention, mask_feather_px default derivation, fit modes and their interactions, n range and billing split, provider_options key validation. This adds substantial meaning beyond the bare type/default schema.

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

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

States a specific verb+resource (edit an image, or create one from reference images) with the engine named (OpenRouter image model). It differentiates itself from siblings by pointing to list_image_models for model choice, get_image_model for passthrough params, and remask_image for re-blending, so an agent can separate it from generate_image without opening any 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?

Explicit prerequisites (call list_image_models first, pick a model whose inputs column says text+image), explicit consent rule (get the user's OK before sending client/project images to third-party providers), and explicit when-nots (don't pass aspect_ratio or size with fit="preserve"; mask_path requires fit="preserve"). It also routes to remask_image for free re-blends, covering alternatives rather than leaving them 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?

With no annotations, the description carries the full burden and does so: it discloses that validation happens before any spend ('an invalid value fails with the allowed values and costs nothing'), that each call is billed to the user's account, that n above the model max splits into multiple billed calls, and that files are saved never overwriting plus a JSON sidecar. It also describes the return payload in detail.

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 purpose, the pre-call workflow and the cost/consent warnings are front-loaded, which is the right ordering. The Args block is long, but each line carries non-redundant semantics for a 13-parameter tool with zero schema coverage; only slight tightening is possible.

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, yet the description enumerates the result contents (saved paths, notes and failures, model, provider, time, cost, JPEG previews), covers the cost/consent/privacy dimensions, and routes to the two prerequisite lookup tools. Nothing an agent needs to call this 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?

Schema description coverage is 0%, so the description must compensate entirely, and it documents all 13 parameters with meaning beyond the schema: n's 1-10 range and server-side splitting behavior, output_dir's absolute-or-tilde path rule, filename_prefix defaulting to a prompt slug, and provider_options' passthrough validation rules. This is far more than the bare schema provides.

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 new images from a text prompt') plus the backend ('OpenRouter image model'), which cleanly distinguishes it from siblings edit_image, list_image_models and get_image_model. An agent can select it 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?

Explicitly prescribes the workflow ('Call list_image_models first... and get_image_model for its exact allowed values') and the human-in-the-loop condition, plus a concrete when-not ('get the user's OK before sending client or project images or details to third-party providers'). Nothing 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?

No annotations are provided, so the description carries the full burden. It usefully discloses the return content in detail, but says nothing about permissions, authentication requirements, rate limits, or whether missing ids raise an error versus returning empty. For a no-annotation tool that is a real, if modest, gap.

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 one-line summary followed by a scannable enumeration of the payload and a short Args block. No filler, though the multi-line return breakdown is slightly longer than needed for a one-parameter read tool.

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, describing the returned sections is exactly the right compensation and is done well. The main omission is any behavioral/prerequisite context (auth, error behavior), which matters more given the absence of annotations.

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 the single param is undocumented in the schema, so the description must compensate. It does: it defines model_id as the exact id and tells the agent where to obtain it (list_image_models), which is meaning beyond the bare 'Model Id' title.

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 ('Show full details for one image model') and enumerates what comes back (description, capabilities, provider endpoint sections, passthrough params, pricing). This clearly separates it from the sibling list_image_models, which returns a collection rather than a single model's full detail.

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 model_id arg is described as 'Exact model id from `list_image_models`', which hints you should list first. There is no explicit statement of when to prefer this over list_image_models or any exclusion 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, the description carries the full behavioral burden and mostly does: it discloses that the catalog is live, cached for 10 minutes, and that moderation status may be unknown ('?'). It does not mention auth requirements or rate limits, but for a read-only listing that is a minor gap.

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 action, then usage, then a column inventory, then args. The column enumeration is lengthy but earns its place because there is no output schema; slightly over-detailed for a listing tool.

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 supplies the return shape by naming every column and its semantics (inputs, aspect ratios, resolutions, quality, max n, seed, moderation, price units). Combined with the cache/liveness note and full param docs, an agent has everything needed to call and interpret 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?

Schema description coverage is 0%, so the description must compensate — and it does, defining all four args: case-insensitive query scope, accepts_images tied to edit_image needs, author as the id prefix before '/', and both sort values with their defaults and ordering.

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 (List) and resource (image models on OpenRouter), plus the output shape (markdown table) and liveness of the catalog. It is clearly separable from sibling get_image_model, which is explicitly scoped to 'one model's per-provider details.'

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 an explicit when-to-use rule: 'Use this before generate_image or edit_image to choose a model and see which options it takes.' It also routes the agent elsewhere when only one model is needed ('Call get_image_model for one model's per-provider details'), and warns against stale remembered model ids.

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 and does so: it states that nothing is uploaded, no model is called, no cost is incurred, and the work happens on this computer. It also discloses the hard prerequisites (requires an `edit_image` result made with `mask_path` on openrouter-image-mcp 0.2.0+, the sibling `<result>.unmasked.png`, and the original input still in place/unchanged), and the save behavior (PNG next to `image`, never overwriting, JSON sidecar, plus a JPEG preview in the result).

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 and the routing decision, then prerequisites, then args; the structure is easy to scan. It is somewhat longer than necessary, repeating the free/offline/no-cost point in three separate places ("free and offline", "it costs nothing", "no model is called"), which is mild redundancy rather than 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 four-parameter tool with no annotations, no output schema, and 0% schema coverage, everything an agent needs is present: when to call it, prerequisites that will make it fail, path-format rules, side effects, and the shape of the returned result (saved path + JPEG preview).

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 all four parameters — and it does. It defines `image` (masked `edit_image` or earlier `remask_image` result), the white/black semantics of `mask_path` plus that any size is stretched to the input, the default derivation of `mask_feather_px` from image size, and the `output_dir` override — all beyond the bare titles in the schema.

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

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

States a specific verb and resource: re-doing the mask blend of a masked `edit_image` result with a new mask, locally and for free. It explicitly distinguishes itself from the sibling `edit_image` ("call this instead of paying for another `edit_image`"), so an agent can route between them 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?

Gives explicit when-to-use conditions (a masked edit that blends badly: a seam, a ghosted edge, a limb/shadow cut off at the mask edge, or a mask that should have been bigger/smaller) and names the alternative plus the reason to prefer this one (free, offline vs. paying for another `edit_image`). It also states prerequisites and that a re-masked result can itself be re-masked.

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