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?

No annotations are present, so the description carries the full burden and does so: third-party upload path, monetary cost per call on the user's account, absolute-path enforcement, non-overwriting save behavior with JSON sidecar, n splitting into multiple billed calls, provider_options validation before spending, and the mask seam artifact. This is well beyond what the schema declares.

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 purpose, then the critical prerequisites, then args. It is long, but with 17 undocumented parameters the length is largely earned; a few arg entries (e.g. resolution/quality) could be compressed further.

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 describes the return payload (saved paths, notes, failures, model, provider, time, cost, JPEG previews) and covers the full parameter surface, consent, cost, and side effects. Nothing material an agent needs to call it 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% across 17 parameters, and the description compensates almost completely: white=change/black=keep mask semantics, feather default derivation, fit=preserve crop/pad behavior, aspect_ratio/size only under fit='model', seed repeatability caveat, and array ordering ('first is the image being edited; any others are references').

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 ('edit an image') and broadens scope to 'create one from reference images' with a named backend ('OpenRouter image model'). An agent can tell this apart from generate_image in practice, but the sibling is never named and the create-from-references overlap 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?

Explicit prerequisites and ordering: 'Call `list_image_models` first to choose a model, picking one whose inputs column says "text+image"', plus a consent gate ('get the user's OK before sending client or project images') and a conditional constraint ('With fit="preserve" don't pass aspect_ratio or size'). It states when-not for several parameters, not just when.

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.