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

Goes well beyond the annotations (readOnlyHint=false, openWorldHint=true, destructiveHint=false) by disclosing credit spend, the approval-plan return path for paid/unknown prices, and the absence of automatic retry. It does not state what the returned approval plan looks like or how assets are re-bound after approval.

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 tight sentences, front-loaded with the capability before cost behavior. No filler; each sentence carries a distinct fact.

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?

Given no output schema and a nested request object, the description covers the operation set, field pass-through and the credit/approval lifecycle well. It leaves the shape of the approval response and the file-binding mechanism to the schema.

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?

At 75% schema coverage the schema already documents most fields, but the description contributes real semantics: req_type and official fields pass through unchanged, and the approval flags only matter once a price is verified non-free. It does not clarify the boundary between cost_approved and high_resolution_approved, however.

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?

Names the specific resource (official Director Tools) and enumerates the concrete operations: background removal, line art, sketch, colorize, emotion, declutter. That is enough to tell it apart from generate/upscale/suggest_tags siblings, though it never explicitly contrasts itself with 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?

Explains the approval workflow (free vs paid vs unknown price) and that no retry happens, which guides invocation. But it gives no explicit routing advice on when to pick this over novelai_upscale, novelai_generate or novelai_encode_vibe; the operations list only implies use cases.

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 declare a non-read-only, non-destructive, non-idempotent, non-open-world write. The description adds real context beyond that: it writes a new PNG to disk, performs no network request, and explains mask semantics (white repaints, black keeps). It still does not say whether an existing file is overwritten or where the output lands.

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 tight sentences, front-loaded with the action and scope, then the color convention, supported shapes, and side effect. No filler or repetition of the tool name.

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 should account for the return artifact; 'Saves a new PNG' gestures at it but gives no path or naming, and nothing is said about overwrite behavior. For a file-writing tool with 0% schema coverage this leaves an agent with open questions 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%, so the description carries the burden. It usefully explains the shape vocabulary (rectangle/ellipse/polygon), that coordinates are in pixels, and that feathering is optional, but it never explains image_path, the box-vs-points distinction, or the feather default/minimum.

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 ('Create a local infill mask') plus scope ('at the source image size') and the color convention ('White repaints; black keeps'). The 'local ... no network request' framing distinguishes it from the network-bound siblings like novelai_generate and novelai_upscale.

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 the tool is used to build a mask for a subsequent infill/repaint step, and clarifies it is local rather than a network call, but it never names an alternative tool or states when-not to use it. Usage is inferable but not 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?

Discloses network send to NovelAI, potential credit spend, approval-plan behavior for paid/unknown prices, and no automatic retry. Complements annotations by adding cost and approval context beyond the readOnly and openWorld hints.

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-loads the purpose, then lists capabilities, output, and cost/retry details. Slightly listy and has minor overlap between the credit-spend and approval-plan sentences.

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?

Covers the return format (local .bin) and side effects, but omits explanation of high_resolution_approved and the files binding. For a complex, multi-parameter tool with no output schema, notable gaps remain.

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?

Mentions masks, extraction, focus/noise seeds and mode=vibe, clarifying several request fields. With schema coverage at 75%, the description adds useful meaning but does not cover every 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?

States a specific verb (encode) and resource (image into reusable vibe binary) and names the official API. Does not explicitly contrast with sibling generation tools, but the purpose is unambiguous.

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?

Provides operational rules for cost approval and retries but no guidance on when to choose this tool over alternatives like novelai_generate or novelai_revise. No when-to-use, when-not-to-use, or alternative selection criteria.

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?

Adds substantial behavior beyond the annotations: it may spend account credits, it checks live entitlement and Huishu pricing, it never retries automatically, paid/unknown prices are gated behind explicit approval, and it returns images plus a run ID. These are exactly the side-effect and safety facts an agent needs that readOnlyHint=false and destructiveHint=false do not 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?

Front-loads the purpose and mode coverage, then layers behavioral constraints. Dense but every sentence carries operational information; it is slightly long, though nothing is clearly redundant.

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 high-complexity generation tool with a large nested request schema and no output schema, the description covers the approval gating, cost risk, and return value well. It leaves the construction of the large official request payload to the schema, which is acceptable given the schema's detail.

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 already 80%, so the schema documents most fields. The description goes further by supplying defaults (28 steps, CFG 6), recommended resolutions, and the pass-through behavior for unknown fields, which the schema does not state.

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 (Generate) and resource (NovelAI images) and enumerates the distinct modes it covers (text-to-image, img2img, infill, vibe transfer, precise reference, multi-character). This clearly separates it from siblings like novelai_encode_vibe or novelai_upscale, which handle single steps rather than full generation.

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 workflow conditions: verified free requests run on the human's instruction, while paid or unknown prices require cost_approved, and high-resolution output requires separate consent. It also advises resolution selection by composition. It stops short of naming alternative tools for adjacent jobs, so it is strong but not exhaustive.

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 establish this as a safe, idempotent, closed-world read. The description adds genuine output-scope context (no image base64, no credentials), which is useful, but it says nothing about ordering, pagination, or what a "run" record actually contains.

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 sentences, front-loaded with the core action and followed by a useful negative constraint. Nothing is padded, though the phrasing "original image/parameter paths" is slightly opaque.

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 carry the return-value burden; it does partially by ruling out base64 and credentials, but leaves the record shape, ordering, and parameter behavior unspecified. Adequate but with clear gaps for a history-listing 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?

Both parameters (limit, run_id) have zero schema description coverage, and the description does not mention either one. It neither explains what run_id selects nor how limit bounds the results, so it fails to compensate for the documentation gap.

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 verb ("Find") and an object ("previous runs") with an added note about what is returned ("original image/parameter paths"). However, "runs" is never defined, and it does not differentiate itself from plausible siblings like novelai_metadata or novelai_schema that might also hold historical/parameter data.

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, no prerequisites, and no named alternative. The line about not returning base64 implicitly points elsewhere for images, but the routing is left entirely 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?

Goes well beyond the annotations (readOnly/idempotent/non-destructive) by disclosing the exact metadata sources read (PNG text, alpha-channel stealth, EXIF), that it is purely local with no token/network/credit cost, that it never alters the image, and that metadata text is data not instructions with missing fields left unguessed. This is unusually rich behavioral context, including a prompt-injection guard.

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-loads the purpose, then layers sources, return values, and safety constraints with zero filler. Every sentence carries distinct information (sources, return fields, cost/auth profile, immutability, injection caveat).

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 still enumerates return values (prompts, seed, model, saved parameters, optional raw metadata), and annotations already carry the safety profile. An agent has everything needed to select and invoke it 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?

Schema description coverage is 50%: path and run_id are documented in the schema, and the description reinforces them via 'local image or prior output' and 'optional raw metadata' (include_raw). The image_index parameter is undocumented in both the schema and the description, so the description only partially compensates for the coverage gap.

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 ('Extract') and resource ('embedded NovelAI generation metadata') plus the two input sources (local image or prior output). This is clearly distinguishable from siblings like novelai_view_image or novelai_history, which do not extract metadata.

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?

Establishes clear context: reading metadata from a local image path or a saved generation ID, which maps to the path/run_id alternatives. It does not, however, explicitly contrast itself with sibling tools such as novelai_history or novelai_view_image, so the routing guidance 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 establish the safe-read profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds real behavioral value beyond them: exact Anlas rules, live subscription entitlement and platform pricing, and the 'no generation charge' constraint with only subscription/quote endpoints contacted.

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 and then the pricing source and return fields. Efficient overall, though the middle sentences are somewhat dense with pricing jargon that could be trimmed.

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 steps in to describe return contents (known sample count, free/paid/unknown status, amount and breakdown), which is exactly the missing information. The main residual gap is how the nested request/files objects are shaped for each operation, but that is largely a schema concern.

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 67%, with the nested `files` binding and the opaque `request` body already documented in-schema. The description mentions 'official image request' mapping loosely to the request parameter but adds no format, structure, or operation-specific guidance beyond 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 (quote) and resource (official image request) and immediately scopes it as cost estimation 'without generating images,' which contrasts it with the generation sibling. The Anlas/pricing detail reinforces what the tool actually does, though it never names the primary alternative (novelai_generate) directly.

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 phrase 'without generating images' implies this is a preview/cost-check step before generation, giving moderate usage signal. However there is no explicit when-to-use vs. when-not, no named alternative, and no stated prerequisites for calling it.

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?

Adds real value beyond annotations: 'Creates a new run and may spend credits; never overwrites the earlier image' directly clarifies the destructiveHint=false and the credit-spend risk that openWorldHint alone does not convey. It also documents the JSON Merge Patch mutation semantics (objects merge, arrays replace, null deletes), which is essential for predicting behavior.

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 core purpose and followed by the highest-risk details (patch semantics, credit spend). No filler, though the prompt/negative_prompt caption note is somewhat terse.

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 output schema, it covers the critical unknowns: new run creation, credit spend, and non-destructiveness toward the source image. The approval-flag workflow is left to schema descriptions, which is acceptable, but run_id/file binding behavior could be clearer.

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 only 33% across 9 parameters, so the description must compensate. It usefully explains patch semantics, prompt/negative_prompt caption synchronization, and use_output_as_input, but leaves files, image_index, run_id, and the binding pointer/path structure unexplained.

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: 'Continue a prior generation, keeping every unmodified parameter.' An agent can distinguish this from novelai_generate (fresh generation) without opening the schema, though no sibling is named 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?

Implies usage (modify a prior run) and explains that use_output_as_input switches to img2img from a previous output, but gives no explicit when-to-use vs novelai_generate/novelai_augment, nor any when-not 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?

Annotations already declare readOnlyHint, idempotentHint, non-destructive, and closed-world, so the safety profile is covered. The description adds only that the schema is 'bundled official', offering minimal extra behavioral context and no information on return shape or lookup cost.

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 packed sentences with no filler; the purpose leads and the accepted inputs follow immediately.

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, zero-required introspection tool with no output schema, the description conveys enough to invoke it correctly. It could say a bit more about what a 'catalog' response contains, but nothing essential 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 carry the load, and it does reasonably well: it names the 'catalog' mode (matching the default) and gives a concrete definition example ('image.RequestParameters'). It stops short of explaining the operation-vs-definition precedence.

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 (Inspect) and resource (the bundled official image API schema and every parameter), which is a distinct capability among the siblings. It does not explicitly contrast itself with any sibling, but 'schema inspection' is self-evidently different from generate/upscale/history.

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?

'Use catalog, an operation name, or a definition such as image.RequestParameters' tells the agent which values the tool accepts, which is call-format guidance rather than when-to-use guidance. It never says when this tool should be preferred or what problem it solves for 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?

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety bar is low. The description still adds real value beyond them: 'Never returns credentials' reassures on output sensitivity and 'makes no network request' specifies a local-only behavior the annotations only hint at via openWorldHint=false.

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 sentences, zero redundancy, with the action front-loaded and the behavioral guarantees 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 trivial zero-argument diagnostic with full annotation coverage, this is adequate: it tells the agent what is inspected and what is never returned. It stops short of describing the shape of the status response (e.g., whether a boolean or config fields are returned) and there is no output schema to compensate.

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, so the baseline is 4. There is nothing for the description to disambiguate, and the empty schema is consistent with the description's local status-check framing.

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 two concrete resources: local configuration and token existence. It is clearly distinguishable from the sibling set, which are all image-generation/manipulation tools, though it doesn't name them 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?

The purpose implies a pre-flight/diagnostic usage, but the description never says when to call it (e.g., before generation, on auth errors) or when not to. Usage must be inferred from the verb 'Check' 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 readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, covering the safety profile and the fact that this reaches an external service. The description adds nothing beyond that – no note on whether a model must be supported, latency, or what 'official' tags mean relative to user-supplied ones.

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 tight sentence with the resource front-loaded and no filler. It is efficient, though the brevity shades into under-specification rather than disciplined conciseness.

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 a nested required-object parameter at 0% schema coverage and no output schema, the description carries a heavy burden and does not meet it – it never explains what the returned suggestions look like or how they relate to the supplied prompt/model.

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% and the single parameter is a nested object with required 'model' and 'prompt' plus an optional 'lang'. The phrase 'for an image model' loosely hints at the model field but says nothing about prompt semantics, language handling, or accepted model identifiers, leaving the nested contract undocumented.

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: 'Get official tag suggestions for an image model.' An agent can tell this is a tag-lookup helper rather than generation (novelai_generate) or augmentation (novelai_augment). It does not explicitly name or differentiate from any sibling, so it stops short of a 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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives. The only implied usage is that you call it before composing a prompt, which the agent must infer entirely.

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?

Beyond annotations, it discloses that assets are sent to NovelAI, credits may be spent, free operations need no approval, paid or unknown prices return an approval plan, and there is no automatic retry. This is strong behavioral context, though it does not describe successful output handling.

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 short and front-loaded, with each sentence carrying useful operational information. 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?

With no output schema, the description should do more to explain the successful return value or where the upscaled output goes. It covers approval behavior and retries well, but leaves output completeness and some mutation details implicit.

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 75%, so many parameters are already documented. The description adds that official fields pass through unchanged and that selected assets are bound, but it does not clarify the request object or approval flags beyond what the 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?

The description states a specific operation, using the "official standalone upscaler", which clearly identifies the resource and action. It does not explicitly differentiate from siblings such as novelai_augment or novelai_revise, so it falls short of a 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?

It gives operational guidance around approvals and retries, but does not say when to choose this tool over alternatives like novelai_generate or novelai_augment. Usage is implied by the upscaler framing rather than explicitly scoped.

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/closed-world, so the safety profile is covered. The description adds genuinely new behavioral context beyond them: it returns actual pixel data plus dimensions, and it carries no network call and no credit cost — the cost/latency trait 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?

Three short sentences, front-loaded with the core action, then the return content, then the sibling redirect and cost note. No 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?

With no output schema, describing the return (pixels and dimensions) is the right call and is done. But with 0% parameter coverage and all parameters optional, the description should explain how path, run_id, and image_index interact and what a no-argument call does — that gap is 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 description coverage is 0% for all three parameters, so the description carries the full burden and largely fails it. Only loose hints map to parameters ('local image' implies path, 'prior output' implies run_id); image_index is never mentioned, nor is the relationship or precedence between path and run_id.

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 ('View a local image or a prior output') and names the two input modes, plus explicitly routes metadata extraction to novelai_metadata. An agent can distinguish this from the other novelai_* tools 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 a clear when-to-use alternative ('For embedded generation settings use novelai_metadata') and clarifies this path has no network request or generation charge, which disambiguates it from generation tools. It does not, however, state what happens when no arguments are supplied or when path and run_id conflict.

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