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

Despite having no annotations, the description fully discloses the tool's behavior: it returns an expiring signed URL, the URL itself carries the auth token ('no auth header needed'), the upload response provides an agent-iris://images/{id} handle, and the tool runs locally in the user's deployment. It even tells the agent that the upload is a separate HTTP POST step, so the tool only creates the URL.

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 dense but efficient, with each sentence adding distinct information: purpose, usage, auth, response, and exclusion. The opening 'Catalog entry.' is slightly cryptic and not fully self-explanatory, costing a point, but the rest is well-organized and front-loaded with the core purpose.

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 tool with no output schema and no annotations, the description is remarkably complete. It covers the full workflow: when to call, what the tool returns, how to upload, what the upload response looks like, how to pass the handle to generate_image, and which cases do not need this tool. 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?

The tool takes zero parameters and the input schema is an empty object with 100% coverage, so the description has no parameters to explain. It goes beyond the baseline by describing the returned upload_url and the handling of the upload response, making the workflow clear even though no params exist.

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

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

The description opens with a specific verb and resource: 'Create the expiring signed URL needed to upload LOCAL image bytes.' It clearly distinguishes the tool from generate_image by stating hosted http(s) URLs should be passed directly to generate_image instead. The 'Runs in your Kuudo deployment, not here' line also clarifies the execution context.

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 when-to-use guidance: 'Use this when you have an image on disk (or raw bytes) to feed into generate_image.' It also provides an exclusion rule: 'Hosted http(s) image URLs do NOT need this — pass them to generate_image directly.' This leaves no ambiguity about which sibling handles which case.

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 delivers: it discloses that the tool runs in the Kuudo deployment, defines mode auto-detection behavior, notes interaction_id TTL (~55 days paid/1 day free), explains handle-as-conditioning vs edit-source semantics, requires POST /images for local bytes, and states the return format. It omits rate limits, failure behavior, and storage/cleanup details, so it is strong but not exhaustive.

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?

Long, but structured with section headers and code blocks so each block earns its place; overview and sibling routing are front-loaded. There is minor redundancy with the schema's mode auto-detection text and the cryptic 'Catalog entry' opener, but the length is justified by the tool's 15 parameters and multiple workflows.

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 states that responses include MCP image content blocks plus structured JSON metadata, covers handle types, upload flow, iteration workflow, presets, and the Amazon compliance prerequisite. Minor gaps remain in exact metadata fields, error semantics, and rate limits, so it falls just short of fully complete for so complex a tool.

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

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

Schema coverage is 100%, so baseline is 3. The description adds meaning beyond the schema through executable examples: character-consistency conditioning with agent-iris:// handles, HTTPS URL editing, interaction_id-only iteration, and multi-reference compositing, plus operation preset semantics. These clarify how mode, input_images, interaction_id, and prompt interact.

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 or edit images with Google Gemini (Nano Banana) from natural language instructions.' It also names the sibling it is not, saying 'For OpenAI gpt-image-2, use the sibling generate_openai_image tool,' so an agent can route correctly without opening schemas.

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 routes to generate_openai_image for OpenAI, prescribes reading skill://amazon-product-image/SKILL.md before Amazon/Seller Central work, marks the interaction_id chained edit as 'PREFERRED', and lays out mode auto-detection rules with explicit override guidance. This is explicit when/when-not/alternatives guidance.

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 exist, so the description carries the full burden. It discloses deployment location ('Runs in your Kuudo deployment, not here'), the auth mechanism (Bearer key), and the iteration semantics via previous_response_id. These are substantive behavioral traits, though rate limits, error behavior, and storage/retention are not covered.

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 front-loaded sentences with zero filler. Purpose first, then sibling distinction, then auth, then iteration — each sentence earns its place and the key usage signal is stated up front.

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 an 11-parameter tool with no output schema, the description covers purpose, sibling routing, auth, and iteration. The schema handles parameter details. The main gap is the absence of return-value or error-behavior context, but that is partly mitigated by the absence of an output 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?

Schema coverage is 100%, so baseline is 3. The schema already documents every parameter richly (n as N server-side calls, size constraints, input_images URL resolution). The description adds only marginal meaning by framing previous_response_id as the OpenAI analog of Gemini's interaction_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 and resource: 'Generate images with OpenAI gpt-image-2 via the Responses API.' It distinguishes itself from the sibling generate_image (Google Gemini) by naming the provider explicitly, so an agent can tell the two apart immediately.

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?

Names the sibling generate_image and positions this tool as 'the additive OpenAI provider,' giving the selection criterion (which provider/API you want). It also discloses the auth prerequisite (Bearer key). The when-to-choose condition is slightly implied via provider naming rather than spelled out as an explicit rule.

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 full behavioral burden. It discloses that it runs in the Kuudo deployment (remote), render times from 11 seconds to minutes, background vs. pending behavior for task-capable clients, the idempotency/resume mechanism, the warning not to retry with a new recovery_id after unknown submission, and the result format (signed URLs and agent-iris://videos/vid_N handles). This is exceptionally transparent.

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 long but front-loaded with the core purpose and input types. Each sentence adds essential information: constraints, async behavior, recovery, compliance. It is structured and not wasteful, though it could be tightened by moving some operational details to the skill reference. Still, given the tool's complexity, the length is justified.

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 13 optional parameters, no output schema, and no annotations, the description covers all necessary aspects: input formats, constraints, timing, async handling, recovery, compliance, and result format. It also directs to the skill for deeper mode/model selection. Nothing 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 100%, so the schema already documents each parameter. The description adds cross-parameter constraints (references/1080p/4k require 8 seconds, inputs must be bounded handles or http(s) URLs, never inline data) that are not fully captured per-parameter. This adds meaningful semantic value 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?

The description clearly states the tool generates video with Google Veo 3.1 from text, images, frames, reference images, or video extension. It names the specific resource and action, and the verb 'generate' distinguishes it from sibling tools like generate_image and generate_openai_image. The scope is precise.

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 directs agents to read the canonical skill://amazon-video/SKILL.md before planning or generating, covering mode/model selection and compliance. It also explains async behavior with get_video_status and recovery_id. However, it doesn't explicitly say 'when not to use this' versus alternatives like generate_image, leaving that inference to the agent, though the skill reference partially compensates.

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 behavioral burden. It discloses that the tool runs in the Kuudo deployment, returns rendered JSON with a messages array, and expects arguments as a dict. This is meaningful behavioral context, though it doesn't explicitly state side-effect safety or error 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?

The description is three short sentences and each one adds information: execution context, retrieval purpose, output shape, and argument format. The opening 'Catalog entry.' is minor filler, but overall the description is efficient and front-loaded.

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, the description adequately explains the return format and argument usage. It also adds the important deployment context. It doesn't describe the messages array's inner structure or error cases, but for a simple fetch-by-name tool it is sufficient for an agent to 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 100%, so the baseline is 3. The description restates the arguments parameter as 'a dict mapping argument names to values,' which adds slight clarity but mostly mirrors the schema's anyOf object/null definition. It does not add substantial new meaning for either 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 description states a specific verb and resource: 'Get a prompt by name with optional arguments.' It also clarifies the tool's product by saying it 'Returns the rendered prompt as JSON with a messages array,' which separates it from siblings like list_prompts.

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 gives useful context such as 'Runs in your Kuudo deployment, not here' and implies the use case of fetching a prompt by name. However, it does not explicitly say when to use this tool versus list_prompts or any other alternative, leaving the agent to infer the distinction.

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 well: it discloses that it runs remotely, makes at most one Google status call, never waits for rendering, downloads/stores the video when finished, and is owner-scoped. This is far beyond a minimal mutation warning and gives an agent an accurate mental model of side effects and access.

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 only three sentences and each sentence contributes: environment, operation scope, behavior, and ownership. The opening 'Catalog entry.' is slightly cryptic but not wasteful. It is front-loaded with the most important scoping information and avoids redundancy.

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?

There is no output schema, so the description should clarify what the call returns; it does not explicitly say the response includes status or progress information. It explains the side effect (download/stores video) but not the return value or retry_collection's effect on the response. For an agent to fully consume the result, this is a notable 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 input schema already covers all three parameters (100% coverage), so the baseline is 3. The description adds value by stating the mutual exclusion between recovery_id and operation_name, which is not enforced in the schema. It does not add much about retry_collection, but the schema description already covers it.

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

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

The description uses a specific verb ('Probe') and resource ('one video operation'), and it explicitly contrasts with the sibling list_video_operations by emphasizing 'one' rather than a list. It also clarifies the execution environment ('Runs in your Kuudo deployment'), making the tool's purpose 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?

The description clearly indicates this tool is for probing a single video operation and gives a concrete constraint: exactly one of recovery_id or operation_name. It does not name an alternative tool explicitly, but the context makes the intended use clear. It also states it never waits, which helps an agent decide when to call 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the return format (JSON with metadata) and the execution environment, but it does not state whether the operation is read-only, safe to call repeatedly, or requires any permissions. For a tool with zero annotation coverage, this is a significant omission that could lead an agent to assume incorrectly about side effects or safety.

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, but it includes a fragment 'Catalog entry.' that adds little value and is not the most informative. The core action 'List all available prompts' appears after the fragment, making it less front-loaded than ideal. It is concise but could be restructured to lead with the key action and remove redundancy.

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 parameterless list tool, the description provides enough information to call it correctly: it states the action, the resource, the output format (JSON with prompt metadata including name, description, and optional arguments), and the execution environment. Although there is no output schema, the description compensates by detailing the expected fields. It is sufficiently complete for a simple 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?

The tool has no parameters, so the input schema (empty object) fully covers the parameter space. The description adds no parameter-specific information, which is appropriate. With no parameters, the baseline score of 4 is justified because there is nothing to clarify.

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

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

The description clearly states the action 'List all available prompts' and specifies the resource (prompts). It also mentions the return type (JSON with prompt metadata), distinguishing it from sibling tools like get_prompt (which retrieves a single prompt) and list_resources (which lists a different resource type). The verb and resource are specific and 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?

The description provides context that the tool runs in the Kuudo deployment, which is a useful contextual clue, but it does not explicitly compare to alternatives or state when not to use it. While the name and action imply when to use it, there is no explicit guidance on exclusions or alternative tools. This is a moderate gap.

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 must carry the full burden. It discloses that execution happens remotely, returns JSON, and details the resource/template distinction. However, it omits obvious behavioral aspects like read-only nature, potential pagination, authentication needs, or error behavior—though these are often implied for a listing operation.

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 concise (three sentences) and front-loaded with the core listing purpose. The opening 'Catalog entry.' is somewhat redundant with the name, but the remaining content is dense and useful. 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?

For a zero-parameter, no-output-schema tool, the description covers the essential return format (JSON metadata) and the distinction between static resources and templates. It also notes the remote execution context. While it doesn't address auth or errors, those are minor for a read-only list operation, and the description is adequate.

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 has zero parameters, so schema coverage is trivially 100%. The description doesn't need to explain parameters; the baseline for 0 params is 4. It adds no parameter-related content, which is appropriate.

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'), resource ('all available resources and resource templates'), and clearly distinguishes from siblings like read_resource and list_prompts. The description explicitly names the two output categories (static resources vs templates) and their fields.

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 for enumerating resources but does not explicitly contrast with read_resource (which fetches a specific resource) or list_prompts. No when-not-to-use guidance or alternative routing; the context note 'Runs in your Kuudo deployment, not here' is a deployment hint, not usage direction.

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 full behavioral disclosure. It clearly states it runs in the Kuudo deployment (not here), reads only the local operation store, and makes no Google call. The phrase 'reads only' implies a read-only, non-destructive operation. This provides sufficient context about execution environment and side-effect profile, though it does not mention authorization or error 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?

Three sentences with no redundancy. The most important facts (catalog entry, local execution, ordering, alternative tool) are front-loaded. Every sentence adds value, and the description is appropriately concise for a simple list operation.

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?

There is no output schema, so the description must hint at return contents. It mentions the recovery_id and its use with get_video_status, which implies the output includes recovery identifiers. It also states ordering and filtering options indirectly via the schema. While it does not fully enumerate all returned fields, it covers the essential usage context for an agent to call 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 100%, so the parameters (limit and status) are fully documented in the schema itself. The tool description adds no additional meaning beyond what the schema provides, so the baseline of 3 applies.

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

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

States a specific verb ('list'), resource ('video operations'), and scope ('submitted with this key'), and adds ordering ('newest first'). It differentiates from the sibling get_video_status by explicitly pointing to that tool for resuming/collecting via recovery_id. This leaves no ambiguity about what the tool does.

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 explicit direction to use get_video_status with a recovery_id for resuming/collecting, which is a clear alternative. It also notes the tool reads only the local operation store and makes no Google call, implying it is for local operations only. It does not exhaustively contrast with all siblings, but the key alternative is addressed.

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

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

With no annotations, the description carries the full burden and does well: it discloses that execution happens in the user's Kuudo deployment rather than the local environment, that the return value is a string, and that binary content is base64-encoded. It does not describe error/not-found behavior or permissions, but the read-only nature is clear from the verb.

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 compact and front-loads the execution context before the core action. Each sentence carries useful information, though the opening 'Catalog entry.' is an opaque fragment that adds little for an agent.

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 one-parameter read tool with no output schema, the description covers input format, execution environment, and return encoding, which is enough to call it correctly. It stops short of being fully complete by omitting error behavior and not pointing to list_resources for URI discovery.

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 schema already documents the uri parameter with 100% coverage, so the baseline is 3. The description adds value by distinguishing static URIs (exact URI) from templated URIs (parameters filled in), which is important for correct invocation.

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 action—'Read a resource by its URI'—and clarifies the resource type. It differentiates from resource-management siblings by focusing on reading a single resource, and it adds useful scope guidance for static versus templated URIs. The initial 'Catalog entry.' phrase is vague but does not obscure the core purpose.

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 clear context about how to format the URI for static vs templated resources, telling an agent what value to provide. However, it does not explicitly mention when to prefer this over list_resources or how to discover resource URIs, so usage guidance is implied rather than 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?

No annotations are provided, so the description must carry the full burden. It does not state whether the operation is read-only, requires special permissions, or has side effects. The 'Runs in your Kuudo deployment' note is environmental, not behavioral.

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, but the opening 'Catalog entry.' is cryptic and may confuse agents into thinking it is a placeholder rather than a functional tool. The second sentence is clear and front-loaded, but the first sentence wastes space.

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?

It lists the diagnostic areas, giving an idea of the scope, but does not describe the output format, error handling, or any prerequisites. Without an output schema, the description should provide more detail on the return value to be fully complete.

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?

There are zero parameters, so the description has nothing to add. Baseline of 4 is appropriate since no parameter documentation is needed.

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

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

The description clearly states the tool returns server diagnostics and enumerates the specific areas (auth, models, storage, uploads, resources, health). This is a specific verb-resource pair and distinguishes it from all sibling tools, none of which mention diagnostics.

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 is obvious from the name and description, and the note 'Runs in your Kuudo deployment, not here' gives contextual placement. However, it does not explicitly state when to use this over alternatives, though no sibling offers diagnostics, so it's effectively the only choice.

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 discloses that the tool runs remotely in the Kuudo deployment, not in the current environment, and that it returns workflow documentation rather than performing generation. 'Catalog entry' itself implies a read-only informational operation, though it does not explicitly state there are no 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?

The description is well-structured and front-loaded: 'Catalog entry' and 'Call this FIRST' appear at the beginning. The bullet list organizes the documentation topics efficiently. It is slightly longer than necessary but every sentence contributes context.

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 the empty schema and no output schema, the description covers the essential information: what the tool does, when to call it, where it runs, and what topics the returned documentation covers. It does not specify the output format, but for a zero-parameter documentation entry point this 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 input schema has zero parameters with 100% coverage, so the baseline of 4 applies. The description adds context by explaining that the tool accepts no input and simply returns documentation, which aligns with the empty schema. No parameter descriptions are needed.

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 purpose: it is a catalog entry that returns workflow documentation for using the image and video generation server. The phrase 'Call this FIRST' clearly marks it as an entry-point tool, which distinguishes it from the generation and upload 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?

It explicitly says to call this tool FIRST, providing clear timing guidance. It also notes that it runs in the Kuudo deployment rather than here, which is a useful environment caveat. It does not name specific alternatives or describe when not to use it, but for an overview/documentation tool this is sufficient.

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