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

No annotations exist, so the description carries the behavioral disclosure burden. It adds useful context: the call runs inside the signed-in tab and the path is relative to https://ads.tiktok.com. However, it does not disclose potential side effects, method semantics, error behavior, or that arbitrary endpoints may include mutating operations, beyond the vague 'escape hatch' label.

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, no filler. The purpose and main constraint are front-loaded, and the usage rule follows immediately. 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?

The tool is a generic API passthrough with 4 parameters and no output schema. The description provides the critical base URL and a strong usage guardrail, but it omits practical invocation details such as how to set the HTTP method, structure query parameters, or interpret responses. It is minimally viable but not complete for an agent unfamiliar with the underlying endpoint conventions.

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

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

Schema description coverage is 0%, so the description must compensate for the 4 undocumented parameters. It explains the `path` parameter is relative to the base URL, but gives no guidance on `method`, `query`, or `body`. The meaning of these parameters is left to HTTP convention rather than clarified 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 states a specific verb and resource: 'call a Symphony JSON endpoint'. It also distinguishes itself from siblings by labeling the tool a 'developer escape hatch' to be used only when documented tools cannot do the job, making its generic role clear.

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 says 'Use only when a documented tool cannot do it.' This is a direct when/why-not rule, and the alternatives are implicitly the documented sibling tools. No inference is required.

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 burden. It discloses the default kind (aigc), the count range (1400+), and what fields are returned. It doesn't mention pagination behavior, rate limits, or whether results are sorted, but the core behavior is 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 compact and information-dense. Every sentence adds value: the first enumerates kinds, the second explains filtering, the third lists return fields. 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 list/query tool with no required parameters and no output schema, the description covers the essential semantics: kinds, filters, and return fields. It could mention pagination defaults or sort order, but the tool is simple enough that the description is nearly 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 0%, so the description must compensate. It explains the meaning of kind values, query, and tagsAll, and gives a concrete example. It doesn't explain page/limit semantics, but those are self-evident from their names.

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 lists avatars and enumerates the four kinds (aigc, real, tryon, product) with brief explanations. It distinguishes itself from sibling tools like sym_voices, sym_templates, and sym_generate by focusing specifically on avatar retrieval.

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 explains how to filter by kind, query, and tagsAll, giving a concrete example of tagsAll. It doesn't explicitly state when to use this tool versus alternatives, but the context signals and sibling names make the use case clear enough.

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

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

With no annotations provided, the description carries full behavioral burden. It discloses the synthesis pipeline (TTS, lip-sync, captions), key constraints (script length, speed range), default voice behavior, current credit cost, and the asynchronous jobId return pattern. This is comprehensive for a creation tool.

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, front-loaded with purpose, then constraints and integration notes, with no filler words. Every sentence contributes to correct invocation.

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 core async workflow is explained (returns jobId, wait with sym_wait), but the nested items array can contain multiple video jobs, and parameters like dryRun, folder, prefix, volume, captions, and name are not addressed. For a tool with no output schema and rich input schema, this leaves notable gaps for an 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 description coverage is 0%, so the description must compensate. It adds meaning for script (length limit, spoken language), voiceId (source from sym_voices, default avatar voice), and speed (0.8–1.3 range), but leaves items/avatarId/captions/folder/prefix/volume/dryRun unexplained. The description covers only a subset of the parameters, so it is adequate but incomplete.

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 creates a talking avatar video from a script, mentioning TTS, lip-sync, and captions. It is specific about the verb and resource, but it does not explicitly differentiate from sibling tools like sym_dub or sym_generate, so it misses the top bar for sibling distinction.

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 clear operational context: voiceId should come from sym_voices, defaults to the avatar's own voice, speed range 0.8–1.3, script limit of 1000 characters, and to wait with sym_wait after receiving jobId. However, it does not state when to choose this tool over alternatives or when not to use 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?

With no annotations, the description carries the full behavioral burden and does it well: it discloses that the operation destroys pending/not-started items and explicitly guarantees running renders are untouched. It does not mention irreversibility or credit/billing side effects, but the core destructive scope and its most important exception are clear.

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

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

Two short sentences with no filler. The primary behavior is front-loaded, and the single critical caveat about running renders follows immediately. 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?

For a zero-parameter cancellation tool with no output schema, this is nearly complete: it says what will be removed and what will be preserved. It could add a note about what 'everything' refers to or whether the action is reversible, but the essential invocation knowledge is present.

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 is empty with no parameters, so the baseline is 4. The description's global wording ('everything') reinforces that no filters or arguments are expected, which is the only parameter-related meaning an agent needs.

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 concrete action ('Remove') and a precise scope ('everything that has not started yet'), then clarifies the boundary with 'Running renders are not interrupted.' This clearly identifies the tool as a cancel-all-pending-jobs operation and distinguishes it from sibling tools like sym_generate, sym_status, or sym_wait.

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 behavior implies when to use it: to clear all not-yet-started work while leaving active renders alone. However, it does not name alternatives or explicitly give a when-to-use/when-not-to-use recommendation, so the routing decision is mostly left to inference.

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

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

With no annotations, the description must carry behavioral disclosure. It adds useful context—'Live' indicates real-time data, and 'price actually charged per task' and 'expected next refill' clarify the nature of the ledger. However, it never explicitly states whether this is a read-only/check operation or whether invoking it affects the credit balance, which is material for a credits-related tool.

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 tightly packed sentence followed by a four-word usage directive. Every phrase adds information—what is returned, the live nature, and when to call it—with 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 low-complexity tool with one optional parameter and no output schema, the description covers the main return categories and provides actionable timing. It could be more complete by explicitly stating that it is a read-only query and how 'limit' shapes the ledger, but the missing parts are largely covered by schema or are minor.

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 input schema already fully documents the single optional 'limit' parameter. The description adds no parameter-level meaning beyond that, 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 clearly identifies the resource (Symphony credit account) and enumerates specific data it exposes: balance, weekly grant/spent, tier, available models, recent ledger with actual charged price, and next refill. It lacks an explicit imperative verb like 'get' or 'list' and does not name a sibling to distinguish itself from, so it falls just short of a top score.

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 explicit operational timing: 'Use before batches and after failures.' This tells the agent when the tool is appropriate. It does not state when not to use it or mention an alternative sibling, so it earns a 4 rather than 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?

With no annotations, the description discloses the return value (jobId) and how to retrieve paths (sym_wait), which is important for agents to understand the flow. It also clarifies that it does not generate content, preventing misuse. While it doesn't detail error conditions, it sufficiently conveys the tool's behavior for a download 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 two sentences, front-loaded with the action and purpose, and provides necessary workflow details without 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 tool is simple with three parameters and no output schema. The description covers the essential workflow: download, get jobId, use sym_wait for paths. It doesn't mention error handling or edge cases, but for this purpose it's 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?

Given zero schema coverage, the description explains all three parameters: taskId is sourced from history/status, folder indicates the destination job folder, and watermarked implies a flag for watermarked files. This provides meaning beyond the bare 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 downloads files from a finished task, explicitly distinguishing it from generation by noting 'without generating anything.' It specifies the resource (files of a studio task) and the source of the taskId, making the purpose unmistakable.

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 provides clear usage context by stating the taskId must come from sym_history or sym_status, implying the tool is for post-generation downloads. It does not explicitly name alternatives for when not to use, but the 'already finished' condition and the workflow of obtaining paths via sym_wait give adequate 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 are provided, so the description carries the behavioral disclosure burden. It discloses meaningful behavior: uses a synthetic voice, can replace burned-in subtitles, supports lip-sync for one visible speaker, caps the request at 20 videos, and returns a jobId. The jobId return value usefully implies asynchronous processing, though it does not explicitly state side effects on the original videos.

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 and front-loads the core purpose with a colon. Every clause adds value: the operation, available options, batch limit, and return value. There is 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 tool with 8 parameters, no annotations, and no output schema, the description is reasonably informative but incomplete. It captures the main purpose, limits, and jobId return, but leaves several parameters unexplained and does not describe how to monitor or cancel the returned job, which matters given sibling tools like sym_status and sym_cancel.

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%, so the description must compensate for undocumented parameters. It adds meaning for videos ('Up to 20 videos per call'), lipsync ('one visible speaker'), and replaceSubtitles ('replace burned-in subtitles'). However, dryRun, folder, and voiceId receive no explanation in either the schema or the description, leaving important gaps.

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 starts with a specific verb and resource: 'Dubbing: translate the speech of a video into other languages with a synthetic voice.' It also names concrete options, making it easy to distinguish from sibling tools like sym_transform or sym_generate.

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 intended use is clearly implied by the description and name: use this when dubbing video speech into another language. However, it does not explicitly contrast with alternatives, state when not to use it, or mention prerequisites, so guidance is implied rather than direct.

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 disclosure burden, but it only clarifies that get reads and update writes. It does not describe side effects, resource costs, idempotency, or behavioral differences of estimate, render, check_render, and export.

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 operation list in the first sentence, followed by a clarifying sentence about draft structure. The dense list of ops could be more readable, but every sentence contributes 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?

Given six parameters, no output schema, and no annotations, the description is substantially incomplete. It does not clarify required parameters, output formats, how op selection changes invocation, or the purpose of taskId and render/export parameters.

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

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

Schema description coverage is 0%, so the description must compensate, but it only explains op semantics partially and mentions drafts are CapCut-style documents. Parameters such as draftId, taskId, exportParams, and renderParams are left entirely 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 identifies the tool as the server-side draft of the Symphony editor and enumerates its operations, including readable verbs for get and update. It conveys the general purpose of structurally editing and rendering CapCut-style drafts, but it does not explicitly differentiate this tool from siblings like sym_transform or sym_generate.

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?

No guidance is provided on when to use this tool versus alternatives such as sym_generate, sym_transform, or sym_render-related siblings. The description implies usage through the op list but never states conditions, exclusions, or prerequisites.

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

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

No annotations are present, so the description carries the full burden and mostly meets it: it discloses async queueing, immediate jobId return, credit/cost behavior, and that the extension waits and downloads files. It does not cover failure modes, cancellation, or exact side effects of a real run beyond spending credits.

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?

Every sentence carries useful information: mode distinctions, async behavior, wet/dry-run cost guidance, and the follow-up tool. The density is high, but the structure makes it scannable and the most critical safeguards are clearly emphasized.

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 complex generation tool with no output schema, it covers the essential return path (jobId → sym_wait) and the mandatory cost-safety workflow. It omits error-handling behavior and leaves 'prefix' unexplained, making it slightly incomplete for fully autonomous 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?

The description materially extends the schema by explaining mode-specific capacities (r2v limits, i2v frame counts, i2i models) and the dryRun return payload. It does not compensate for the undocumented 'prefix' parameter, so parameter guidance is strong but not complete.

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 precise action: 'Queue video/image generation in the live Symphony account' and identifies the four supported modes. It clearly distinguishes this from sibling read/status/download 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?

Provides explicit operational guidance: ALWAYS use dryRun:true first unless the user confirmed cost, and directs retrieval through sym_wait. Mode selection is implied clearly, but it does not explicitly contrast this tool with closer generation-related siblings like sym_transform or sym_tryon.

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 returns drafts with status, type, vid, cover, errors, and explains miniAppTypes numeric codes. However, it doesn't disclose pagination behavior, ordering, whether results are read-only, or any side effects. The miniAppTypes mapping is useful behavioral context but incomplete.

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 main purpose. The miniAppTypes mapping is dense but useful. However, the structure is a bit run-on and could be clearer with separation between the purpose statement and the parameter mapping.

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 no annotations and no output schema, the description is thin. It doesn't explain the return format beyond listing fields, doesn't mention pagination defaults, doesn't clarify whether miniAppTypes is a filter or a response field, and doesn't provide usage context. The miniAppTypes mapping is helpful but the overall picture is incomplete.

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

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

Schema description coverage is 0%, so the description must compensate. It explains the miniAppTypes parameter values (1 refresh, 2 i2v, etc.), which is valuable. However, it doesn't explain limit or offset semantics beyond what the schema names imply. The miniAppTypes explanation is the key added value.

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: 'What was generated in this account' with drafts including status, type, vid, cover, errors. It clearly identifies this as a history/listing tool for generated content. It doesn't explicitly differentiate from siblings like sym_log or sym_status, but the resource (generated drafts) is distinct enough.

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?

No explicit guidance on when to use this tool vs alternatives. The description implies it's for viewing generation history, but doesn't mention when to prefer sym_log or sym_status. The miniAppTypes mapping provides some context for filtering but no usage scenarios.

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

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

With no annotations provided, the description carries the full burden and does a good job: it discloses the newest-first ordering and explicitly warns that clear:true empties the inbox after reading, which is an important side effect. It does not describe the full return shape, but for a simple inbox-reader this is acceptable.

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 short sentences with no filler, front-loading the content and ordering before the clear parameter behavior. The first sentence is a grammatical fragment, but it is still compact and information-dense.

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 low complexity—one optional boolean parameter, no output schema, no annotations—the description covers the essential facts: what the inbox contains, how results are ordered, and how clearing works. A clearer verb would strengthen it, but nothing critical is missing for correct selection and 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?

The input schema only defines a boolean 'clear' with no description, and schema description coverage is 0%. The description compensates by explaining the meaningful behavior: clear:true empties the inbox after reading. Since there is only one parameter, this is sufficient.

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 identifies the resource as templates sent from the studio page via the '→ Claude' button and specifies their contents (director prompt, reference image, sample) and ordering (newest first). This differentiates it from sibling template tools like sym_templates and sym_template. It lacks an explicit operative verb like 'list' or 'get', but the intended behavior is still clear.

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 use case: this is the inbox for user-sent templates from the studio page, and clear:true is the cleanup option. It does not explicitly state when to prefer this over sym_templates, sym_template, or sym_history, leaving some routing to inference from sibling names.

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 burden. It discloses that the tool provides links (not files), only works on finished drafts, and that watermarked:true returns the official export. It does not mention error cases or link expiration, but the core behavioral trait of returning links vs downloading is clearly conveyed.

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 with no filler. The main purpose is front-loaded, and the usage context is condensed into a single final clause. Every sentence contributes distinct information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter tool with no annotations and no output schema, the description covers key aspects: purpose, parameter semantics, and usage timing. It omits return format details and behavior for invalid draftIds, but overall an agent can correctly select and invoke this tool for its intended niche.

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 add meaning. It explains the watermarked parameter's effect (official export vs original file) and implies draftId refers to a draft from sym_history. Both parameters are addressed beyond their bare type definitions, though draftId could use a bit more context.

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 and resource: 'Download links of a finished draft', and clarifies the two modes (original no watermark vs watermarked official export). It also distinguishes this tool from the extension's automatic downloads, leaving 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?

The description explicitly states when to use this tool: 'use this for older drafts from sym_history'. It also contrasts with the extension's self-downloading behavior for jobs, implicitly telling the agent when not to use this tool. This is clear guidance with no reliance on inference.

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

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

No annotations are provided, so the description carries the full burden. It communicates a read-only tail operation on the log, which implies no side effects. However, it does not disclose details like default line count, log size limits, or behavior when the log is empty.

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 very short, front-loaded, and free of filler. It is concise without being a pure tautology, though the brevity contributes to missing detail elsewhere.

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 low-complexity tool with one optional parameter and no output schema, the description is barely adequate: it implies the return value is log lines and the operation is safe. But it leaves parameter semantics and usage context to inference, so it is not 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?

The only parameter, 'n', is a bare number in the schema with no description and 0% schema coverage. The description says 'last lines' but never explicitly states that 'n' controls the number of lines, nor does it mention any default or bounds. The description fails to compensate for the schema 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 identifies the resource ('extension log') and the scope ('last lines'), with 'diagnostics' clarifying intent. It is not a tautology and is distinguishable from sibling tools, though it lacks an explicit verb like 'get' or 'tail'.

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 parenthetical 'diagnostics' implies this tool is for debugging or inspecting extension behavior, but the description provides no explicit when-to-use guidance or alternatives. Usage is implied rather than directly 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?

With no annotations, the description carries the behavioral burden and does a solid job: it enumerates the state categories, exposes the extension.director playbook, and discloses the expired-license path and automatic queue resume. It does not explicitly state whether the call is read-only or side-effect free, but 'status' and 'Call it FIRST' strongly imply a safe state probe.

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 information-dense: every clause adds either a state category, an instruction, or a conditional behavior. It is front-loaded with 'Call it FIRST and follow the playbook' before diving into details, and there is 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 tool with no output schema and many siblings, the description covers the main response areas, the call ordering, and the license-expiration handling. It does not define the structure of extension.director or explain what following the playbook entails, but that may be intentional since the playbook itself is returned by the 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 input schema is empty, so there are no parameters to explain; the no-parameter baseline of 4 applies. The description adds useful meaning by detailing what the returned state contains, which is more valuable than parameter documentation here.

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 explains what the tool reports: bridge/extension state, Creative Studio connection, credits, queue, inbox, and extension.director. It does not use an explicit verb like 'retrieve' or 'return', and it does not explicitly contrast itself with focused siblings such as sym_credits or sym_inbox, though 'Call it FIRST' signals its entry-point role.

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 explicit usage context: call this tool first, follow the director playbook, and handle an expired license by asking the user to activate a key. It does not state when to use sym_inbox or sym_credits instead of this aggregated status tool, so the exclusion/alternative guidance is incomplete.

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

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

With no annotations, the description carries the full burden, and it does disclose the returned content: complete director prompt with specific components, reference image URL, and sample video. It does not explicitly state that this is a read-only retrieval or describe side effects, but the wording strongly implies fetching a template rather than modifying anything.

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 compact sentences with no filler. The first sentence front-loads the resource and its key contents, and the second sentence states the intended usage, so 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?

There is no output schema or annotations to fill gaps, and the description only partially specifies the return value. It omits parameter semantics, especially inspirationItemId, and does not explain how this tool relates to sym_templates, leaving the agent without enough context to call it reliably in all cases.

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

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

Schema description coverage is 0%, so the description must compensate, but it does not clearly define templateId or inspirationItemId. templateId is weakly inferable from the word 'template', but inspirationItemId is entirely unexplained and no guidance is given on how it affects the returned template.

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 identifies a single template resource containing a director prompt, reference image URL, and sample video, and states its intended use for structuring a prompt. However, it does not explicitly contrast with sibling tool sym_templates, so the distinction between listing templates and fetching one is only 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?

There is a clear usage instruction: 'Use it as the structure of your own prompt.' This implies when an agent needs a reusable template, but there is no explicit when-to-use versus alternatives, no mention of when not to use it, and no reference to sym_templates for browsing templates.

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 discloses that videoPrompt is truncated by default and can be made full with 'full:true', and that useCase 1 is the default list. However, it does not mention pagination, response format, or side effects. It covers some behavioral aspects but not comprehensively enough for a tool with no annotation support.

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 dense sentence that packs multiple facts (count, fields, truncation, useCase, query) without fluff. It is somewhat dense, but efficient and front-loaded with the primary purpose. It earns points for being concise while conveying substantial information.

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 6 parameters and no output schema or annotations, the description leaves gaps: it doesn't explain page/limit semantics, industryId values, or the structure of the returned list. It gives enough to start, but not enough to call it correctly in all contexts, especially when compared to richer sibling tools.

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% (only 'full' has a description), so the description must compensate. It explains 'useCase' values and that 'query' filters by text, but it does not explain 'page', 'limit', or 'industryId'. This partial compensation is useful but leaves several parameters undocumented in both schema and 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 clearly identifies the tool as returning TikTok trend templates with metadata like name, description, use cases, industry, and videoPrompt. It specifies the default useCase (1) and default list behavior, so an agent understands it as a list endpoint. However, it does not explicitly differentiate from the sibling 'sym_template' (singular), leaving some ambiguity about when to use which.

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 some context on useCase values (1 for viral ads, 8 for Create page) and mentions query text filtering, but it does not state when to prefer this over sibling tools like sym_template, sym_generate, or sym_editor. There is no explicit when-not-to-use or alternative routing guidance, which is a significant gap given the large sibling list.

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 the core behavior (cutting clips, voice-over, returning jobId) and useful constraints (minimum video length, language list). But it does not mention that the operation is asynchronous, that credits may be consumed, or what jobId means beyond being a returned identifier.

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 entire description is one tight, front-loaded sentence with the key action first and all essential constraints compressed into parentheses. The language list is compact and the final sentence on jobId is necessary. 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 an 8-parameter media tool with no output schema and no annotations, the description is too sparse: it omits the meaning of critical parameters (dryRun, folder, productName, productDescription) and does not explain the expected job workflow or how to retrieve the result. An agent could call it with required fields but not know the effects of the optional ones.

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 25% (videos and images have path/URL descriptions), so the description must compensate. It adds meaning for seconds and language by enumerating valid values, but leaves dryRun, folder, productName, and productDescription unexplained, making it hard for an agent to correctly fill all 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 names a specific operation ('Symphony cuts new TikTok-ready clips'), specifies source material (product videos ≥ 15 s and photos), output durations (15/30 s), voice-over language set, and the return value (jobId). This clearly differentiates it from siblings like sym_dub or sym_editor, which do different media operations.

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 use case ('Video refresh') and conditions such as videos ≥15 s and supported languages, so an agent can infer when it might apply. However, it never explicitly says when to prefer this over sym_dub, sym_avatar_video, or sym_editor, nor states any exclusions, which is a notable gap with so many 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?

No annotations are provided, so the description carries the full disclosure burden. It does disclose a key behavioral trait—'Returns jobId'—signaling async submission. However, it omits how results are retrieved (suggesting sym_status/sym_wait), credit consumption, side effects, and failure modes, which matters more given the absence of 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?

Three dense sentences front-load the core purpose, then compress parameter sourcing and the return value into a small footprint. Every sentence earns its place, though the telegraphic 'kind apparel' / 'kind product' phrasing is slightly awkward.

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 6-parameter tool with no annotations and no output schema, the description covers the two required parameters and the async jobId return, enough to invoke correctly. It leaves the optional parameters (prompt, dryRun, folder) and the post-submission workflow (fetching the finished video) to inference from sibling names.

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% (only images is documented), so the description must compensate. It does add meaning for kind (wearing apparel vs presenting product), images (product/apparel photos), and avatarId sourcing. But prompt, dryRun, and folder receive no explanation in either the schema or the description, so compensation is partial.

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 behavior: generating a video of an avatar wearing the user's apparel (kind=apparel) or presenting the product (kind=product), and names the source of avatarId (sym_avatars kind=tryon|product). It is clear and specific, but never explicitly contrasts with near siblings like sym_avatar_video or sym_generate, so differentiation is implicit rather than stated.

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 a concrete prerequisite ('avatarId from sym_avatars kind=tryon|product'), which routes the agent to the correct source tool, and implies usage for try-on scenarios. However, there is no explicit when-to-use versus when-not-to-use guidance and no named alternatives for cases like plain avatar video.

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 of disclosing behavior. It indicates a write operation (uploading) but does not mention any side effects, permissions required, or what the tool returns (e.g., URLs or IDs). The phrase 'to reuse URLs/vids' hints at a return value but is vague. It also omits any error conditions, file type restrictions, or size limits. This is a significant gap for a mutation tool with no output schema.

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, well-structured sentence that front-loads the primary action and then adds the distinguishing clause ('without generating anything') and the purpose ('to reuse URLs/vids'). There is zero redundancy or filler, making it highly concise and easy to parse.

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 is simple with one parameter, and the schema fully covers that parameter. The description provides the use case and differentiation. However, it lacks explicit information about the return value or success indication, which is important for an agent to know if the upload succeeded. The hint 'to reuse URLs/vids' implies a return, but it is not stated. Given the simplicity of the tool, a 3 is borderline; it is adequate but could be more 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 100%, so the schema already describes the 'files' parameter clearly (absolute path or https URL inside Symphony). The description does not add any additional context about the parameter beyond its purpose. Since the schema is complete, a baseline of 3 is appropriate; the description adds no extra value on this dimension.

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 verb ('Upload') and the resource ('files into the Symphony library'), and explicitly contrasts with generation tools via 'without generating anything'. It also names the intended purpose ('reuse URLs/vids across tasks'), which distinguishes it from siblings like sym_generate.

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 on when to use the tool: when you want to reuse existing assets across tasks without generating new ones. It implicitly excludes generation use cases by stating 'without generating anything', though it does not explicitly name alternative tools or specify conditions like 'use sym_generate if you need to create content'. This is still sufficient guidance for most agents.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds some useful info (tags and preview audio, language/gender values) but does not state whether the operation is read-only, what the response structure includes beyond preview audio, or any side effects. It does not mention authorization or rate limits. The transparency is minimal and insufficient for a tool with no 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 concise, using a single sentence with a colon to introduce parameter hints. It is not overly verbose and gets to the point. However, the structure mixes the main purpose with parameter examples in a way that could be more clearly separated, but it is still efficient and on-topic.

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 5 parameters (all optional), no output schema, and no annotations, the description is incomplete. It does not mention how filtering works (e.g., 'query' semantics), whether results are paginated via 'limit', or what 'recommendOnly' controls. It also does not clarify the return format beyond mentioning preview audio. An agent would be under-informed to call this tool correctly, lacking important operational details.

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 should explain each parameter. It explicitly explains 'language' and 'gender' with example values (english/spanish, male/female), which is helpful, but it does not clarify 'limit', 'query', or 'recommendOnly'. Without these, the agent cannot correctly construct a call or understand filtering behavior. The partial coverage does not adequately compensate the missing schema documentation.

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 identifies the resource: voices for talking avatars, and mentions tags (language, gender, age, style) and preview audio. It distinguishes itself from siblings like sym_avatars (avatars) and sym_templates (templates) by focusing on voices. However, it lacks an explicit verb like 'List' or 'Search', relying on the noun phrase to imply retrieval, so it's a point below perfect.

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 provide any guidance on when to use this tool versus alternatives. It fails to mention that this tool is for searching/listing voices or when to prefer it over other category-specific tools. No usage context or exclusions are given, leaving the agent to infer from the resource name.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool returns intermediate results on timeout and requires a subsequent call, and it enumerates the return contents (items, file paths, links, cost data, errors). This is more than a minimal statement and provides useful behavioral context, though it does not mention side effects like resource consumption or authentication.

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 primary action and output details. The first sentence states the purpose and return contents; the second covers timeout behavior. There is zero wasted wording, and the structure is highly scannable.

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 must explain the return values, and it does: items, local file paths, links, cost data, errors. It also explains timeout behavior. It does not specify the exact return structure or edge cases (e.g., missing job), but for a simple wait tool with two parameters, this is fairly complete. The timeout parameter is well-described in the schema, and the description adds the necessary context about the intermediate picture.

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%: timeoutSec has a descriptive schema, but jobId lacks any description. The tool description partially compensates by indicating jobId is used in the path structure (symflow-out/<job>/...), which clarifies its role. However, it does not fully explain jobId's format or requirements, and the schema already covers timeoutSec well. The description adds some value but not enough to fully compensate for the uncovered 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 clearly states the tool's function: 'Wait for a job and return its items'. It specifies the resource (job) and the outcome (items with local file paths, links, cost data, errors). This distinguishes it from siblings like sym_status (which likely only checks status) by emphasizing the wait-and-return behavior. The inclusion of output details 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 implies usage: you call this to wait for a job and get results, and on timeout you call again. However, it does not explicitly contrast with alternatives like sym_status or sym_log, nor does it state when NOT to use this tool. The timeout behavior is mentioned, but the guidance is mostly implicit.

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