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

Annotations already indicate destructive action (destructiveHint=true, readOnlyHint=false), and the description's action list is consistent with that. However, the description adds no extra behavioral details such as permanence of deletion, side effects of modification, or output format.

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

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

The description is a single concise sentence that front-loads the primary verb and lists all supported actions without fluff. It is appropriately sized for the tool's scope.

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?

The tool has a complex multi-action interface with no output schema, and the description does not mention what actions return (e.g., whether view returns the workflow JSON or list returns names). While the param descriptions are thorough, the lack of output/return info leaves a gap for agents.

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?

Input schema has 100% description coverage with detailed descriptions for all six parameters, including the enum for action and examples for modify values. The description itself adds no parameter semantics beyond the schema, so 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?

Description clearly states the tool manages ComfyUI workflow templates and enumerates the five supported actions (list, view, import, modify, delete). This distinguishes it from sibling tools focused on generation or search.

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 usage for workflow template management but does not explicitly state when to use this tool over alternatives, nor does it mention any prerequisites or exclusions. However, the action list provides clear context for when each action is appropriate.

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?

The description discloses a key behavioral trait: the tool rejects direct calls without an active skill grant/run descriptor, which is not captured in annotations. It also reveals that it returns an asset id for later use. Annotations only indicate non-read-only/non-destructive, so this additional behavioral context is valuable.

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 concise sentences, each adding distinct value: what it does, how to use the output, and a prerequisite/restriction. There is no filler, and the main purpose is 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?

For a tool with 4 parameters and no output schema, the description covers the core action, the return value (asset id), and a critical prerequisite. It omits details on optional parameters and failure behavior, but the provided annotations and straightforward purpose keep it reasonably 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?

Schema description coverage is only 25% (only url has a description). The tool description does not explain the purpose of title, purpose, or groupName, and it merely restates the url's schema description. With low schema coverage, the description was expected to compensate but does not.

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 materializes a public URL into a current-project asset, using a specific verb and resource. It distinguishes itself from siblings by mentioning the returned asset id for later media calls and by referencing the run_skill prerequisite, making its role unique.

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 explicitly instructs calling run_skill first and warns that direct calls are rejected without the skill grant, giving a clear precondition. It also indicates the tool's output is used in later media calls, providing context. It does not explicitly name alternative tools like web_fetch, but the usage context is well-defined.

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 indicate a write operation (readOnlyHint=false) and non-destructive (destructiveHint=false). The description adds behavioral context: it requires an active skill grant/run descriptor and rejects direct calls, and it requires 1-3 authorized audio samples. This goes beyond the annotations and informs the agent of preconditions.

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 two sentences, front-loaded with the core purpose, and includes a critical prerequisite. Every word contributes; no wasted content.

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?

The description gives the essential purpose and a key precondition, but with seven parameters and no output schema, it lacks details on return values, error cases, and the role of optional parameters. It is adequate but not fully complete for a tool of this complexity.

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

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

Schema description coverage is 0%, so the description must carry parameter meaning. It clarifies sampleAssetIds as '1-3 authorized project audio samples' but does not explain the other six parameters like language, voicePrompt, idempotencyKey, tags, etc. This leaves significant ambiguity for the agent.

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's function: 'Create a reusable project voice profile from 1-3 authorized project audio samples.' It uses a specific verb 'create' with a clear object and source constraint, distinguishing it from siblings like run_skill.

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 explicit usage guidance: 'Call run_skill first' and 'This tool rejects direct calls without the active skill grant/run descriptor.' This tells the agent when to use the tool (after run_skill) and when not to (direct calls without grant). It doesn't mention alternatives, but the sequential dependency is clearly 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?

The annotation readOnlyHint=true already signals a safe read-only operation, lowering the burden on the description. The description adds useful operational context ('Free, no API key needed') but doesn't disclose return format or side effects. With the annotation covering safety, this is adequate but not exceptional.

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 focused sentences: purpose, when to use, and an extra tip with operational info. Every sentence earns its place, and the key purpose is front-loaded. No wasted words.

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 simple two-parameter tool with no output schema, the description provides essential context: what it does, when to use it, and a workflow suggestion. It doesn't explain the return format, but that is expected and covered by the schema's name and purpose. Slight gap on output specifics, but overall 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?

Schema description coverage is 100%, with both 'prompt' and 'style' already well-documented. The description's example for prompt adds no additional meaning beyond the schema's example. No info about style is mentioned in the description, so it does not compensate beyond the baseline.

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+resource ('Transform a simple idea into a professional image generation prompt'), clearly distinguishing the tool from image generation or inspiration siblings. The example ('a cat in a garden') reinforces the concrete function.

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 states when to use the tool: 'Use when the user provides a brief description... and needs a detailed, high-quality prompt.' It also suggests combining with gallery inspiration, giving workflow context. It lacks explicit 'when not to use' or named alternatives, which prevents a 5.

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 readOnlyHint=true, so the safety profile is already covered. The description adds valuable context by indicating this is a pre-execution discovery step ('Use this before run_skill') and that the skill must be 'App-managed', but it does not describe output format or behavior when no skill is found.

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 sentences, front-loaded with the verb and resource; the second sentence provides actionable sequencing guidance. Every word earns its place, with no 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?

With 7 parameters, annotations, and high schema coverage, the description provides enough context for a discovery tool: it states what it finds, for whom, and when to use it. The lack of output schema is partially mitigated by the clear relationship to run_skill, but a brief mention of the return value (e.g., skill ID) would make it 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?

Schema coverage is 86% with descriptions for mode, scope, intent, capability, and outputCapability, so the baseline is 3. The description adds minimal parameter nuance beyond linking 'intent' to 'user intent' in the usage sentence, so it does not exceed the baseline.

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 the verb 'Find' with the resource 'App-managed skill' and scopes it to 'the current task', clearly stating its function. It differentiates from sibling run_skill by positioning this as a lookup step: 'Use this before run_skill'.

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 instructs to use this before run_skill, and specifies the condition: 'when the user intent requires a specialized App skill.' This provides clear when-to-use guidance and points to the alternative.

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 indicate destructiveHint=true and readOnlyHint=false, and the description does not contradict these. It adds useful behavioral context about provider support and default selection, but does not disclose potential side effects like file overwriting, output location, or cost implications, which would be relevant given the destructive hint.

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 exactly two sentences, front-loaded with 'Generate an image.' The second sentence adds key provider information. There is zero waste, and it is easy to scan.

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?

Despite having 11 parameters and no output schema, the description is very brief. It does not explain what the tool returns (e.g., an image URL or file path), whether it saves files, or any provider-specific nuances beyond defaults. Given the tool's complexity, the description is insufficient for the agent to fully understand invocation results and side effects.

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 covers 100% of parameters with descriptions, so the baseline is 3. The tool description does not add additional parameter-level meaning beyond what is already in the schema; it only restates the provider default, which is also in the provider parameter description.

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 'Generate an image,' a specific verb+resource pair that clearly identifies the tool's function. It also distinguishes it from sibling tools like video_generation and speech_generation by focusing solely on image generation, and the mention of three supported providers adds specificity.

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 clear context about when to use the tool (when generating images) and describes provider selection behavior (UGCMind default when configured). However, it does not explicitly state when not to use it or compare alternatives, such as if another tool would be better for a different image-related task.

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 destructiveHint=true and readOnlyHint=false. The description adds valuable context by disclosing that video jobs are asynchronous and warning against duplicate submission. This is useful operational behavior not captured in the annotations. No contradiction found.

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 two sentences with no filler. The first sentence front-loads the core action, and the second delivers essential async guidance. Every word 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?

Given the tool has 9 parameters, no output schema, and async behavior, the description provides crucial context (async, status polling) but omits what the response contains or how the final video is retrieved. It is not fully complete for such a complex tool, though the rich parameter schema compensates somewhat.

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 100% description coverage, with all nine parameters fully documented including defaults and constraints. The description itself adds no parameter-level details beyond the schema, so the baseline score of 3 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?

The description clearly states the tool's primary action: 'Generate a video through the UGCmind App Tool Runtime.' It uses a specific verb and resource, making the purpose unambiguous. However, it does not explicitly differentiate from the sibling tool 'video_generation', 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?

The description provides explicit guidance for the asynchronous case: 'if queued/running, call get_tool_task_status rather than submitting again.' This names a specific alternative and tells the agent when not to resubmit. It does not, however, explain when to prefer this tool over the 'video_generation' sibling, which prevents a 5.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds value by enumerating the returned content (prompt, media URLs, metadata, next-action hints), which helps set expectations for a read-only retrieval call. No contradiction with annotations.

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?

Single sentence, directly states the operation and outcomes. No filler or 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 simple retrieval tool with a well-documented schema and read-only annotation, the description sufficiently explains purpose and return content. Without an output schema, the enumerated return fields provide adequate context; minor ambiguity about 'next-action hints' is acceptable.

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%, with both locale and imageId already documented. The description adds no further parameter-level semantics beyond the general return contents, 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?

The description specifies a concrete action (Get) and identifies the resource (one UGCmind prompt library entry) plus the exact data returned. This clearly distinguishes it from search_gallery which lists entries rather than retrieving full detail for a single one.

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 does not explicitly state when to use this tool or contrast it with siblings. The imageId parameter's schema reference to 'search_gallery results' implies the intended workflow, but this guidance is not in the description itself.

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 mark the tool as read-only. The description adds value by clarifying this is for polling asynchronous tasks that returned queued/running and that it returns status and artifacts. It does not describe the output structure in detail, but the mention of 'status and artifacts' provides a helpful overview beyond the annotation.

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 two sentences: the first states the purpose, the second states when to use it. There is no filler or redundancy, and the most important information is 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 the one-parameter input, read-only annotation, and no output schema, the description covers the essential usage scenario well. The mention of 'status and artifacts' gives a sufficient sense of the return value, though it does not go into error cases or polling behavior.

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 fully describes the single parameter 'toolTaskId' with the same source context ('returned by generate_image or generate_video'). The description repeats that context but does not add further parameter-level semantics beyond what the schema already 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 uses a specific verb 'Check' and names the resource 'UGCmind Tool Runtime task' along with what is checked: 'latest status and artifacts'. It clearly differentiates from sibling generation tools by framing this as the follow-up status check.

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 explicitly states when to use the tool: 'Use this after generate_image/generate_video returns queued or running.' This provides a clear trigger condition. However, it does not mention alternatives or situations to avoid, so it does not earn a 5.

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?

The readOnlyHint annotation already indicates a safe read operation. The description adds valuable behavioral context: the source is the App public model catalog, and with UGCMIND_API_KEY, project-specific overrides may be included, which can affect results. No contradictions with annotations.

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 concise sentences front-load the core purpose and add a relevant caveat. Every word earns its place, with no redundancy or 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 simple read-only list tool with one optional parameter and no output schema, the description is sufficiently complete. It states what is listed and the API key influence. A minor gap is not specifying whether the return includes identifiers or how to use them in generation calls, but this is not critical for basic selection.

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%, as the only parameter (activeOnly) is already documented with its purpose and current behavior. The description adds nothing about parameter syntax or meaning, but the schema handles it fully, so the baseline score of 3 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?

The description uses a specific verb ('List') and identifies the resource ('UGCmind image/video generation model options from the App public model catalog'). It clearly differentiates this tool from sibling generation tools like generate_image and video_generation by focusing on listing model options rather than generating content.

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 for querying available models before generation, and notes that an API key may include project-specific overrides. However, it does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or prerequisites beyond the API key.

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?

The annotation readOnlyHint=false is consistent with the description's "Read or update" framing, so no contradiction. The description adds the useful behavioral note about calling "get" at conversation start, but it does not disclose side effects of "set", "add_favorite", or "remove_favorite" such as overwriting preferences or permanently deleting favorites. These details are partly in the schema but not in the description.

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 two concise sentences, front-loaded with the main purpose and a clear usage instruction. Every word contributes value; no redundancy or 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?

The tool has 4 actions and 8 parameters, but the description does not mention the add_favorite or remove_favorite actions explicitly, nor does it describe the output shape of a "get" call. The schema fills in parameter details, but the description alone is only minimally complete for a multi-action preference 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 description coverage is 100%, so each parameter is already documented with action-specific semantics. The description only enumerates preference categories (style, aspect ratio, model, etc.) and does not add new meaning beyond the schema. This meets the baseline for full schema coverage.

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 reads or updates user preferences and lists the specific preference fields (default style, aspect ratio, model, style notes, favorite prompts). This specific verb+resource combination differentiates it from the sibling tools, which are mostly generation or asset tasks.

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 explicit usage context: call with action "get" at conversation start to load preferences. It does not explicitly mention when not to use the tool or alternatives, but the context is clear and sufficient given the tool's unique role among siblings.

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 offer no safety hints (readOnlyHint=false, destructiveHint=false), so the description carries the burden. It discloses the rejection mechanism without a skill grant and the asynchronous behavior ('If the result is queued or running, do not submit it again; return the task id and stop the turn'), adding value beyond the structured fields. No contradiction.

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, each with a distinct purpose: stating the function, imposing a prerequisite, and giving task-handling instruction. No filler or redundancy. Front-loaded and efficient.

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 tool's complexity (11 parameters, no output schema, no annotation detail), the description is sparse. It does not mention return values, parameter meanings, error handling, or how to construct a valid prompt. The task-id guidance is helpful but insufficient for a production-grade 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 description coverage is only 9%, with just one parameter (model_option_id) having a description. The tool description does not explain any of the 11 parameters (e.g., prompt, style, title), leaving the agent without semantic guidance. This is a critical 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 clearly states the tool's function: 'Generate a project music asset through the UGCmind Tool Runtime.' The verb 'Generate' and resource 'project music asset' are specific, and the tool name and mention of 'music' distinguish it from image/video/speech generation 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?

Provides explicit prerequisites and constraints: 'Call run_skill first' and 'rejects direct calls without the active skill grant/run descriptor.' Also advises handling queued/running results by not resubmitting and returning the task id. This gives clear context for when to invoke the tool, though it does not directly compare to sibling tools.

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 (readOnlyHint=false, destructiveHint=false), the description adds a key behavioral trait: the tool rejects direct calls unless preceded by run_skill. It also clarifies the project-scoped nature and that it operates on existing assets. This goes beyond what annotations convey, though it leaves unclear what happens on success or if there are 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?

Two sentences, each earning its place: the first states the core function, the second covers the critical prerequisite and rejection condition. No filler or 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?

The description leaves significant gaps: no output schema, no explanation of what 'reference metadata' entails, and no guidance on how to populate the seven parameters (only primaryAssetId is documented in the schema). The run_skill prerequisite is critical but not sufficient for confident invocation.

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 14% (only primaryAssetId is described). The description does not compensate for the other six parameters—traits, displayName, negativePrompt, promptFragment, sourceAssetIds, and type—beyond the vague notion of 'existing project assets.' It provides no additional meaning for most parameters.

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+resource phrase: 'Create reusable project-scoped reference metadata from existing project assets.' This clearly distinguishes the tool from siblings like generate_image or write_free_doc, and the name 'prepare_reference_asset' aligns with the described function.

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 explicit context: 'Call run_skill first' and states that direct calls without the active skill grant/run descriptor are rejected. This tells the agent when and how to invoke the tool, though it does not mention alternatives or exclusions beyond this prerequisite.

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 the readOnlyHint annotation, the description discloses a key behavioral trait: the tool rejects direct calls unless run_skill has been invoked. It also implies bounded content via 'bounded text content,' adding context about limits. No contradiction with annotations.

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 two sentences long, front-loaded with the main purpose, and each sentence adds value. 'Call run_skill first' and the rejection note are slightly redundant but not excessive, keeping it efficient.

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 tool has 4 parameters, no output schema, and a read-only annotation, the description covers the crucial prerequisite (run_skill) and the read scope. It does not explain return values or pagination details, but the description is adequate for a bounded read operation with a known prerequisite.

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 25% (assetId has a description, but limit, offset, and includeContent do not). The description partially compensates by mentioning 'metadata or bounded text content,' which hints at includeContent and limit/offset, but it does not explicitly map parameters or explain how offset/limit work.

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 what the tool does: 'Read metadata or bounded text content from one current-project asset.' It specifies the verb (read), the resource (project asset), and the scope (one current-project asset), which distinguishes it from siblings like search_project_assets (searching) and write_free_doc (writing).

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 explicit usage context: 'Call run_skill first' and notes that direct calls are rejected without the active skill grant/run descriptor. This is clear prerequisite guidance, though it does not explicitly compare with alternatives or state when not to use the tool.

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 indicate only that the tool is neither read-only nor destructive. The description adds context about its role as an authorization/precedence step, but it does not disclose side effects, return values, or whether calling it multiple times has consequences. This leaves ambiguity about what 'authorize' entails.

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 two sentences long with no wasted words. The first sentence defines the purpose, and the second reinforces the critical timing. Both sentences earn their place, making it highly concise and well-structured.

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 9 parameters and no output schema, the description is insufficiently complete. It fails to explain what the tool returns (e.g., an execution grant) or how the optional identifiers like skillId, skillRef, and executionGrantId should be used together. This leaves the agent uncertain about the outcome and the required parameter combinations.

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 descriptions cover 100% of parameters, so the baseline is 3. The description does not add any additional parameter semantics beyond what the schema already provides; it only implicitly links the 'tool' parameter to the preceding-tool context without explaining specific parameter relationships or optional combinations.

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's function: 'Run and authorize an App-managed skill before calling its concrete App tools.' It uses a specific verb-resource pair and distinguishes itself from siblings like find_skill by positioning it as a prerequisite step to concrete App tools.

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 timing guidance is provided: 'Call this immediately before the tool that will use the skill.' This clearly indicates when to use the tool relative to other actions, though it does not explicitly state when not to use it or list alternative approaches when already authorized.

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 mark the tool as read-only. The description adds context about result contents (prompt summaries, image URLs) and recommends rendering Markdown images, giving the agent actionable behavioral expectations without contradicting the read-only hint.

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 two concise sentences, front-loaded with the core action and resource, then adding output and rendering guidance. No filler or 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?

With 9 parameters and no output schema, the description gives a clear overview of purpose and result format. It doesn't cover pagination, sorting, or parameter interactions, but the core use case is adequately addressed.

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 100% coverage for all 9 parameters, so the description need not elaborate on them. It provides no additional parameter-specific detail, aligning with the baseline of 3.

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 specifies the verb 'Search', the resource 'UGCmind prompt library', and the purpose 'visual inspiration', making it clear and distinct from sibling tools. It does not explicitly name alternative tools, so it misses the top score, but is still strong.

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 usage for visual inspiration, but offers no explicit when-to-use or alternative guidance. It doesn't compare to siblings like get_inspiration or search_project_assets, nor mention when not to use this tool.

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?

The readOnlyHint annotation already indicates a safe read operation. The description adds non-obvious behavioral details: the requirement to have an active skill grant and the rejection of direct calls. This goes beyond what annotations provide and helps the agent understand the invocation context.

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 two sentences long, front-loaded with the primary purpose, and every sentence adds value: the first states what the tool does, the second the critical prerequisite. There is no redundant or vague wording.

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 six parameters, no output schema, and no parameter descriptions, the description is incomplete for an agent to know what to pass or what to expect in return. It does communicate the run_skill dependency, but lacks information on output format, filtering options, and when to prefer this tool over siblings like read_project_asset.

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 description does not explain any of the six parameters (kind, limit, query, scope, groupId, mimeType). While names like 'query' and 'limit' are self-evident, others like 'groupId' and 'mimeType' are left to inference, and the description says nothing about their role in filtering assets.

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 ('Search') and the resource ('assets owned by the current UGCmind project'), giving specific scope. It does not explicitly mention alternative search tools, but the combination of project ownership and the run_skill prerequisite distinguishes it from siblings like search_gallery.

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 instructs to call run_skill first and warns that direct calls are rejected without the active skill grant/run descriptor. This provides clear usage context and a specific prerequisite, but it doesn't discuss alternatives or exclusions relative to sibling search tools.

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 the readOnlyHint annotation, the description discloses materialization requirements and the rejection behavior for missing skill grants. These are significant behavioral traits that help the agent anticipate outcomes and dependencies.

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, front-loaded with the primary action. No redundancy or filler, every sentence adds value.

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?

The description covers the core behavior and critical prerequisites, but with 7 optional parameters and no output schema, it lacks details on filtering, pagination, and return values. The completeness is adequate for a simple search but not fully fleshed out.

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

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

With 7 parameters and 0% schema description coverage, the description must compensate but provides no details on query, gender, region, ageGroup, category, page, or pageSize. This leaves the agent without guidance on how to properly invoke the tool.

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 it searches the approved UGC actor catalog, using a specific verb and resource. This distinguishes it from sibling search tools like search_project_assets or search_gallery, which have different domains.

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 explicitly instructs to call run_skill first and warns that the tool rejects direct calls without the active skill grant/run descriptor. This provides strong usage context, including a prerequisite and a condition for successful invocation.

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 the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that the tool rejects direct calls without an active skill grant/run descriptor, and that if a result is queued/running the agent should return the task id and stop. It also hints at an approval process for voice profiles, adding useful behavioral context.

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 concise sentences, front-loaded with the core action. Every sentence adds value: what it does, the required prerequisite, and a critical async/queued behavior warning. No fluff 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?

Given the tool's complexity—12 parameters, no output schema, minimal annotations—the description covers the critical prerequisite and queued-task behavior, but omits the success return format and does not describe most parameter semantics. It is adequate for initial selection but not fully complete for safe invocation without further investigation.

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

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

With 12 parameters and schema description coverage of only 17%, the description should compensate by explaining key parameters. It only vaguely references 'approved voice profile' and 'project reference assets', which map to a few parameters, but provides no meaningful guidance on format, sample_rate, pitch_rate, duration, or model_option_id. The schema enums/ranges are not enough, and the description adds little beyond them.

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: 'Generate a speech audio asset', which clearly distinguishes it from sibling tools like music_generation and video_generation. It adds optional qualifiers ('voice profile or project reference assets') that refine the tool's scope without ambiguity.

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 clear usage context by stating 'Call run_skill first' and explicitly warns against resubmitting queued/running tasks. While it does not name alternative tools, the prerequisite and the 'do not submit again' instruction give practical guidance on when and how to use the tool.

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?

The description reveals asynchronous behavior (queued/running states), a task-id return, and a prerequisite skill grant—context beyond the annotations (readOnlyHint=false, destructiveHint=false). It does not disclose failure modes or rate limits, but the provided context is valuable for correct use.

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 sentences, front-loaded with the main action, and every clause adds operational information. No wasteful phrasing or 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?

Given the tool's complexity (9 params, no output schema, async behavior), the description covers the critical flow: prerequisite, rejection behavior, duplicate handling, and task-id return. It omits details about output retrieval and parameter selection, but it is sufficient for an agent to correctly invoke and handle the immediate result. Some gaps remain, so not a 5.

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 only 22%, with descriptions only for model_option_id and source_asset_id. The description adds minimal parameter semantics: it clarifies that source_asset_id refers to a project asset and that the source can be audio or video, but it does not explain diarize, quality, keyterms, num_speakers, etc. For a 9-parameter tool, this is insufficient compensation.

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 function: 'Transcribe a project audio or video asset into a persisted transcript asset.' It uses a specific verb (transcribe), names the resource (project audio/video asset), and the result (persisted transcript asset), which distinguishes it from sibling tools like run_skill.

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 explicitly instructs 'Call run_skill first' and warns 'This tool rejects direct calls without the active skill grant/run descriptor.' It also provides a clear when-not: 'If the result is queued or running, do not submit it again; return the task id and stop the turn.' It does not name alternatives but gives strong operational 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?

Annotations declare readOnlyHint=true, and the description adds contextual details like 'live', 'provider availability', 'access rules', and 'async task contract'. This goes beyond the annotation by indicating the tool returns real-time operational and contractual information, which is valuable for agents.

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 one compact sentence that front-loads the key action and subject. Every word contributes to defining the tool's purpose, achieving high conciseness with no 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 read-only catalog inspection tool with a single enum parameter and no output schema, the description covers the main purpose and the facets of the catalog. It does not explain response structure, but this is acceptable given the simple nature and the parameter's schema description.

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 single parameter 'view' has 100% schema description coverage, explaining that it limits the catalog scope. The tool description does not add further parameter meaning, so it meets the baseline without exceeding 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 'Inspect' and names the resource 'UGCmind MCP tool catalog' plus associated aspects like provider availability and access rules. This clearly distinguishes it from sibling tools that perform content generation or asset management.

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 when to use the tool: to inspect the live catalog for capabilities, provider availability, and contracts. It provides clear context but does not explicitly mention alternatives or exclusions, such as 'use list_models for model-specific info'.

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, the description discloses that the tool rejects direct calls and requires a run descriptor, and it warns about duplicate submissions when a task is queued/running. This adds meaningful behavioral context beyond readOnlyHint and destructiveHint.

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, front-loaded with the core purpose, then critical usage constraints. Every sentence earns its place with no 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?

The description covers the critical workflow (run_skill first, idempotency behavior) but omits parameter details and does not distinguish from generate_video. Given the tool's complexity and low schema coverage, this leaves meaningful gaps for the agent.

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 only 38% (3 of 8 params have descriptions), and the tool description provides no additional parameter semantics. Action, aspect_ratio, duration_seconds, selectedAssetIds, and file_name remain 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?

The description clearly states the tool generates a project video asset and specifies the runtime context (UGCmind Tool Runtime). However, it does not differentiate this tool from the sibling generate_video, despite the unique run_skill prerequisite being implied.

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 instructs to call run_skill first, warns that direct calls are rejected without an active skill grant, and tells the agent not to resubmit if the task is queued/running. It lacks exclusions or explicit alternatives, but the usage context is clear.

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 the annotations (readOnlyHint=false, destructiveHint=false), the description discloses that the tool rejects direct calls without a skill grant and that results may be queued/running, instructing the agent to return the task id. This adds meaningful behavioral context about prerequisites and asynchronous behavior, though it doesn't describe the full success path 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?

The description is three sentences, each earning its place: the first states the core purpose, the second gives a prerequisite, and the third provides handling instructions. It is concise, front-loaded, and free of fluff.

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?

The tool has 6 parameters, no output schema, and moderate complexity. The description covers the prerequisite and async handling, but it omits what the tool returns on success and does not explain the undocumented parameters. It is adequate but has notable gaps.

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 50%, with descriptions for prompt, assetId, and model_option_id, but file_name, aspect_ratio, and selectedAssetIds lack descriptions. The tool description does not mention or explain any parameters, so it fails to compensate for the undocumented ones. It adds no value beyond the schema for the parameters it does cover.

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 a project image asset via the UGCmind Tool Runtime, which is a specific verb+resource. It does not explicitly distinguish itself from the sibling generate_image, but the mention of run_skill and task handling implies a workflow-based purpose, providing sufficient clarity.

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 explicit usage context: call run_skill first, and it warns that direct calls are rejected without the active skill grant/run descriptor. It also instructs not to resubmit if the result is queued/running and to return the task id instead. This is clear context, though it doesn't discuss alternatives or when to prefer this tool over generate_image.

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 beyond annotations by revealing the tool requires a skill grant and rejects direct calls, plus hints at a safety mechanism ('project-safe result'). The annotations only provide readOnlyHint=false and destructiveHint=false, so this description adds meaningful behavioral context about prerequisites and access control.

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 sentences, front-loaded with the core function, followed by a critical prerequisite. No fluff or redundancy; 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?

Given the tool's moderate complexity, the description adequately covers the core action, the required prior step (run_skill), and the rejection scenario. It does not specify the exact return format, but since there is no output schema, this is a minor gap rather than a critical omission.

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

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

Schema description coverage is 100% with clear descriptions for all three parameters (url, title, purpose). The tool description itself does not add extra parameter-level information, meeting the baseline for well-documented 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 uses a specific verb ('Fetch') and resource ('public product or research URL'), and clarifies the mechanism ('UGCmind's bounded URL materializer') and outcome ('project-safe result'). This clearly distinguishes it from sibling URL-related tools like create_file_by_url.

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 instructs 'Call run_skill first' and states that direct calls are rejected without an active skill grant/run descriptor. This provides clear context on how to invoke the tool, though it does not mention alternative tools for similar 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?

Beyond the annotations (readOnlyHint=false, destructiveHint=false), the description discloses important behaviors: it requires a prior skill run and rejects direct calls without it, and it instructs the agent to avoid resubmitting when a task is queued/running and instead return the task id. These are non-obvious behavioral traits that the annotations do not convey. It does not contradict the annotations.

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 sentences, front-loaded with the primary purpose, followed by the prerequisite and an important operational warning. Every sentence carries meaningful information and there is no redundancy or padding. It is concise yet dense with necessary guidance.

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 tool has 6 parameters, no output schema, and low parameter description coverage, the description provides the core purpose and critical usage caveats but does not explain success return values or the full parameter set. It mentions returning a task id only for queued/running cases, not what a successful persist returns. It also leaves parameter meanings mostly unexplained, making the description incomplete for a tool of this complexity.

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 17%, and the description itself does not explain any of the parameters. While 'Markdown brief' hints at the markdown parameter, there is no explanation of file_name, title, task, model_option_id, or selectedAssetIds. The schema only gives descriptive text for model_option_id ('Optional model option id supplied by the UGCmind runtime') and selectedAssetIds items ('A UGCmind project asset id...'), but the tool description adds no semantics for these fields. The description fails to compensate for the low schema coverage.

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's function: 'Persist a Markdown brief or report as a UGCmind project document asset.' It uses a specific verb ('Persist') and resource ('Markdown brief or report'), and the scope ('UGCmind project document asset') distinguishes it from sibling tools like create_file_by_url or read_project_asset. Even without naming alternatives, the write-and-persist 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?

The description gives an explicit prerequisite: 'Call run_skill first' and warns that 'this tool rejects direct calls without the active skill grant/run descriptor.' It also provides handling guidance for async results: 'If the result is queued or running, do not submit it again; return the task id and stop the turn.' This is clear context for when and how to use the tool, though it does not explicitly list alternative tools for comparison.

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