SendShort

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is clear. The description adds the genuinely useful behavioral constraint that in-flight or published posts are outside this tool's reach, which cannot be inferred from 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 sentences with zero filler; the core action is front-loaded and the constraint follows immediately. Every clause carries actionable 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 single-parameter destructive tool with rich annotations and no output schema, the description covers the essential constraint. A brief note on the result of a successful cancellation would close the last gap.

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

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

Schema coverage is 100% and the single parameter is fully documented with a UUID format, pattern, and upstream sources. The description adds contextual meaning by implying the identifier refers to a scheduled item, though it does not itself explain the parameter.

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

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

States a specific verb and resource ('Delete a scheduled short or slideshow post') plus a timing scope ('before it publishes'), which separates it from delete_video and the publishing-status siblings. An agent can act on this without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly names the exclusion case (posts publishing or already published) and redirects to the correct alternative ('delete those on the platform itself'). This is the when-not/alternative pairing that earns a top score.

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 it is a non-readonly, non-idempotent, non-destructive open-world write, so the safety bar is covered. The description adds genuinely new operational context: it consumes the monthly shorts quota, the quota equals moment_ids.length when specified, and it returns a job_id for async polling rather than finished shorts.

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

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

Five dense sentences, all front-loaded: identity and prerequisites first, the moment_ids/count branch next, optional knobs, then the return-and-poll instruction. No sentence is 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?

Given 15 parameters, a nested style object, and no output schema, the description covers the high-risk gaps: quota cost, async job_id, and polling target. It omits edge behavior (what happens if the video isn't finished importing, error semantics) but is sufficient for a correct first call.

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 baseline is 3; the description still adds value by explaining the precedence rule between moment_ids and count (and the resulting quota calculation) in one place. Defaults like count=5 and theme=18 are already in the schema, so the added semantics are real but incremental.

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?

Specific verb (queue clipping) plus resource (an already-imported video_id), and it names where the id comes from (list_videos / get_import_status). It also implicitly separates itself from get_clip_status by casting itself as the enqueue step, so an agent can distinguish it from siblings without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear operating rules: use moment_ids to clip specific moments in order, otherwise count random moments, and poll get_clip_status afterward. It doesn't state when to prefer a sibling like create_music_video, but the context for calling this tool is unambiguous.

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 only say it is a non-idempotent, open-world write; the description adds real behavioral context beyond that: it consumes the monthly music-video quota, requires the caller to hold music and video rights (no license granted), warns that lyric captions are speech-to-text and can be wrong on sung audio, and discloses the async job_id return pattern.

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?

Dense but front-loaded: format and duration first, then quota, then inputs, then caveats and next step. Every sentence carries information, though the single-paragraph block of eight-plus clauses is slightly heavier than it needs to be.

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 9-parameter creation tool with no output schema, the description covers the essentials: input modes, defaults, media-type-dependent requirements, legal caveat, caption accuracy risk, the returned job_id, and the polling step. Nothing an agent needs to call it correctly is missing.

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

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

With 100% schema coverage the baseline is 3, but the description earns more by explaining cross-parameter behavior the schema states only piecemeal: gameplay/aesthetic pull from the SendShort library while custom requires video_url or video_path, and the default theme is intentionally not in list_themes. It still leaves details like the title fallback and audio_url vs audio_path precedence largely to the schema.

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

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

States a specific verb and resource with hard constraints baked in: 'Queue a 9:16 music video up to 60 seconds.' It also names the async follow-up tool (get_music_video_status), so the agent can distinguish this creation tool from status-listing siblings without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear routing context: it tells the agent to call list_themes for caption styles, to poll get_music_video_status after submission, and to use POST /api/v1/music-video/upload before passing audio_path. It does not explicitly say when to prefer a different sibling (e.g. clip_video or schedule_short), so it stops short of full when/when-not coverage.

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, the description discloses important consequences: shorts already made from the video stay, the long-video slot is freed, and the user cannot restore the deleted video from the app. It also tells the agent to confirm with the user first, which is critical behavioral guidance for a destructive 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 four short sentences with no wasted text. The primary purpose is front-loaded, followed by side effects, required confirmation, and irreversibility.

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 destructive single-parameter deletion tool, the description covers what is deleted, what remains, the slot side effect, required user confirmation, and irreversibility. Combined with the destructive annotation and complete schema, an agent has enough information to invoke it correctly.

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

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

The schema has 100% description coverage for the single required video_id parameter, including that it comes from list_videos. The description does not add any further parameter semantics beyond what the schema already provides, 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 gives a specific verb and resource: delete an imported long video. It also states the scope and consequence: freeing a long-video slot, while shorts made from it remain. This clearly distinguishes the action from related video and short-management 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?

It provides clear usage context: use this to free a long-video slot, and confirm the video with the user first. It does not name an explicit alternative tool or explain when deletion should be avoided in favor of another action, but the confirmation prerequisite is strong 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 already declare readOnly/destructive=false and openWorld=false, so safety is covered. The description adds genuinely useful behavioral context – that download_url appears only when the rendered MP4 exists – but omits the status values or terminal states an agent needs to decide when polling is finished.

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

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

Two short sentences, front-loaded with the core action first and the conditional-output caveat second. No wasted text for a simple single-param read tool.

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

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

For a simple polling read tool with annotations covering safety and a single documented param, this is adequate but incomplete: the status values, whether polling should continue, and the response shape (no output schema exists) are left unexplained, and only the download_url condition is surfaced.

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 a single required parameter and 100% schema description coverage (including the 'job_id from clip_video' note), the schema does all the work. The description adds nothing beyond it, so the baseline of 3 applies.

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

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

States a specific verb (poll) and resource (clip job), which is clearer than the bare name. However it doesn't distinguish itself from parallel status tools like get_import_status, get_music_video_status, or get_status, so an agent must infer the resource distinction from the name alone.

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?

'Poll a clip job' implies the polling use case but gives no explicit when-to-use guidance, no mention that job_id comes from clip_video (that detail lives only in the schema), and no indication of how often to poll or when to stop.

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, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds real value beyond that by disclosing a payload behavior: video_id is absent until the download finishes and the file is in storage. It does not describe other status fields or terminal-state values.

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, and the action ('Poll a YouTube import job') is front-loaded ahead of the qualifying detail about video_id.

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

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

With no output schema, the description usefully fills the most important return-value gap by explaining when video_id appears. Minor gaps remain: no enumeration of statuses or failure states and no polling-interval guidance, but the essentials for calling this tool correctly are 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?

Schema description coverage is 100% and the single job_id parameter is documented in the schema as coming from import_youtube, so the schema carries the burden. The description adds no format or provenance detail beyond it, making the baseline 3 appropriate.

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

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

States a specific verb and resource ('Poll a YouTube import job'), which distinguishes it from the generic get_status and the parallel get_clip_status / get_music_video_status siblings by naming the YouTube-import resource. It stops short of explicitly naming which sibling is the alternative.

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?

'Poll' implies repeated invocation until completion, and the second sentence implies that until video_id appears the job is not yet done, so the stop condition is inferable. However, no explicit guidance is given on when to call this versus get_status, nor on polling cadence or how to treat terminal failures.

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

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

Annotations already declare readOnly and non-destructive, so the safety profile is covered. The description adds genuinely new behavior: download_url signals completion and a job idle for 45 minutes is marked failed without consuming quota, which tells the agent when to stop polling.

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

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

Three short sentences, zero filler, with the core action front-loaded and completion/failure semantics following in priority order.

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 single-parameter poller with no output schema, the description covers what matters: the success signal and the timeout/failure condition. It stops short of describing other likely status fields (progress, error state), so a small gap remains.

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 a single parameter at 100% schema coverage, the schema already documents job_id as coming from create_music_video. The description adds nothing about the parameter, so the baseline 3 applies.

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

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

States a specific verb and resource: 'Poll a music-video job.' The 'music-video' qualifier implicitly separates it from get_clip_status and get_import_status, which poll other job types, though those siblings are never named explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Poll' plus the note that download_url appears when the MP4 exists makes the intended loop (repeated calls until a download URL appears) clear, and the 45-minute rule tells the agent how to interpret a stalled job. There is no explicit exclusion statement naming alternatives, which keeps it below 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 this is a safe read (readOnlyHint=true, destructiveHint=false, closed-world), so the bar is lower. The description adds genuinely useful behavior beyond that: download_url is signed, is null when not exported, and requires a prior export step, which an agent would otherwise not know.

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

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

Three short sentences, front-loaded with the core action and then the conditional download_url caveat. No filler and every sentence carries 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?

With no output schema, the description carries the burden of explaining returns, and it covers the key output fields (download_url, export_status) and the condition connecting them. Nothing an agent needs to call it correctly or interpret the response is missing.

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

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

Schema coverage is 100%, so the short_id parameter is already documented, including its source ('from list_shorts or get_clip_status'). The description adds no further meaning about the parameter, so baseline 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 states a specific verb and resource ('Get one short by id'), clearly distinguishing it from list_shorts, and adds scope by noting it covers both app-made shorts and clip_video results. It does not explicitly contrast itself against the nearest sibling, but the singular-vs-list distinction is obvious.

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 explains a clear usage condition: download_url is null while export_status is not_exported, and the user must export in the SendShort editor first. It doesn't explicitly name an alternative tool, but the prerequisite workflow is spelled out.

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 cover the safety profile (readOnlyHint true, destructiveHint false, openWorldHint false), so the bar is lower. The description still adds real value: it discloses the account-tier prerequisite, the max-8 long-video slot constraint, the remediation step ('delete in the SendShort app Home if full'), and clarifies that MUSIC_VIDEO quota counts completed jobs plus in-flight — none of which are in structured fields.

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

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

A single front-loaded sentence opens with the core purpose and then lists the data points returned. It is dense but every clause corresponds to a distinct returned field or constraint; the only weakness is that it reads as one run-on enumeration rather than being grouped or bulleted.

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

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

There is no output schema, so the description carries the burden of explaining return values and does so thoroughly — plan eligibility, slots, three quota types, and two named rate limits. What's missing is any indication of response shape or what a plan-ineligible response looks like, which an agent would need to branch on.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline is 4. The description correctly spends its space on what the call returns instead.

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 verb and resource — check SendShort API plan eligibility, slot capacity, quotas, and rate limits — and enumerates the exact return fields, so the agent knows this is an account-level status/preflight call. It could go one step further and explicitly distinguish itself from the job-level siblings get_clip_status / get_import_status / get_music_video_status, which is the only thing keeping it from 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?

Usage is implied rather than stated: the enumeration of plan eligibility and quotas suggests calling this before submitting jobs, and 'Professional or Business plan required' is a useful prerequisite. But there is no explicit when-to-call guidance and no naming of the sibling status tools it should be preferred over or combined with.

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 (non-readOnly, openWorld, non-idempotent), the description discloses the concrete long-video slot cap (max 8), the exact error condition (quota_exceeded), and the asynchronous semantics (returns job_id quickly, requires polling). This is operational context an agent cannot derive from the annotation flags alone.

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 tightly packed sentences: capability first, constraint and remediation second, workflow third. No filler, and the most important gating fact (slot cap) appears early rather than buried.

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

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

With no output schema, the description still explains what comes back (job_id) and how to resolve it to a usable video_id. Combined with the quota failure path, an agent has everything needed to invoke this correctly on the first try.

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%, and the description's source list (YouTube, Twitch, Kick, direct links) duplicates the youtube_url schema description almost verbatim. The lang parameter, including its default, is not mentioned in the description at all. Baseline 3 applies since the schema carries the load.

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

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

States a specific verb and resource ('Import a long video from a link') and enumerates accepted sources. It is clearly distinguishable from siblings like get_import_status and clip_video, which it names as downstream steps rather than alternatives.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use guidance plus the failure path: on quota_exceeded, free a slot via list_videos and delete_video, then retry. It also spells out the follow-up sequence (poll get_import_status until video_id, then clip_video), leaving nothing 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?

Annotations say readOnlyHint=false with idempotentHint=true, and the description supplies the reason: generate=true creates GPT moments. That tells the agent the call can write but is safe to repeat. It does not say whether generation is billed, slow, or async, which would have completed the picture.

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, all functional, and the core action is front-loaded. But the stacked parentheticals '(...) (gpt and already-created)' sit awkwardly mid-sentence and cost the reader a re-read.

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 list tool with no output schema, the description covers the input contract, the side-effecting option, and the downstream handoff to clip_video. It does not describe the shape of a returned moment (fields, ordering, empty-result behavior), which is the main remaining gap.

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

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

Schema coverage is 100% and the generate parameter's description ('If true, generate GPT moments when the video has none yet') already duplicates the prose almost exactly. The description's only real addition is the provenance of video_id (imported SendShort videos.id), which the schema gestures at but does not source.

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?

Opens with a specific verb+resource ('List AI moments for an imported video_id') and pins the scope to imported videos, which separates it from list_videos and get_import_status. The trailing parenthetical '(gpt and already-created)' is intended to describe the moment types returned but reads ambiguously.

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 states where video_id comes from (list_videos or get_import_status), when to add generate=true (only when no GPT moments exist yet), and where the returned ids go next ('clip_video.moment_ids'). That is clear conditional guidance, though no explicit when-not-to-use case is given.

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, openWorldHint=false, destructiveHint=false, so the safety profile is covered. The description contributes real behavioral detail beyond that: ordering ('soonest first'), the status taxonomy (scheduled, processing/publishing, published, failed), per-account published_at, and the 30-day window on include_past.

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 lead sentence is front-loaded with the core behavior and the include_past note lands at the end where it belongs. The sentence about retrying a failed post from the SendShort calendar is informational but not needed to invoke this tool, so it is minor dead weight.

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

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

With no output schema, the description usefully enumerates the returned fields (status, published_at) and the sort order, which is what an agent needs to interpret results. The only gap is the absence of any max-result or pagination cue, plus no explicit sibling routing.

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

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

Schema coverage is 100%, so baseline is 3, and the description earns above baseline by clarifying the actual semantics of include_past – not just 'include published posts' but specifically posts published in the last 30 days, which bounds the result set in a way the schema 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 names a specific verb and resource ('List the user's scheduled short and slideshow posts') and adds scope details (ordering, status values). It does not, however, distinguish itself from siblings like list_shorts or list_slideshows, leaving the agent to infer that this is the scheduled-queue view rather than a content library.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is implied: it's the tool for seeing what's queued, and include_past is framed as an opt-in for published posts. There is no explicit statement of when to prefer this over list_shorts/list_slideshows, and the mention of retrying from the SendShort calendar is tangential rather than a routing rule.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description still adds real behavioral context: newest-first ordering, the fact that shorts created in the app are included rather than only API-created ones, and the prerequisite that export/rendering (download_url set) gates scheduling. What it omits is pagination mechanics and any signal of result volume.

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 what is listed and returned, then the export prerequisite. The final sentence is dense and packs two ideas (export gating and download_url as the export signal), but nothing is redundant.

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

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

With no output schema, the description carries the return-value burden and does so adequately by naming the returned fields and their nullability. The main residual gap is pagination behavior and whether export state is visible per item, which matters given the export-before-schedule rule.

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?

All three parameters (limit, offset, search) are fully documented in the schema, so the baseline is 3. The description adds no extra parameter semantics — notably it never mentions the search filter or that offset should be fed from next_offset on the previous page.

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

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

States a specific verb and resource (list the user's shorts) plus ordering (newest first) and the exact fields returned (id, name, video_id, with null semantics for uploaded/generated shorts). That level of detail lets an agent distinguish it from get_short and list_videos without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies the workflow clearly: the returned id/name are what feed schedule_short, and the description warns that a short must be exported before scheduling. It does not explicitly name alternatives (e.g. use get_short for a single short) or state when not to use it, so it stops short of 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 annotations already declare readOnlyHint=true, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: results are newest first and include id and name, which helps an agent know what it will receive.

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?

It is a single compact sentence with no wasted words. The core purpose, scope, ordering, and downstream use are all 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 simple read-only list tool with fully described parameters and clear annotations, the description supplies the key missing context: what a slideshow is, ordering, and returned fields. It could say more about pagination or filtering behavior, but the schema already covers those 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 100%, so limit, offset, and search are already well documented in the schema. The description does not add parameter-specific guidance beyond what the schema provides, making 3 the appropriate 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 gives a specific verb and resource, clarifies that slideshows are TikTok photo carousels, and states the ordering and returned fields. This distinguishes it from siblings like list_shorts and list_videos without requiring schema inspection.

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 ties the tool to schedule_slideshow by saying the id and name are provided for that purpose, which gives clear intended usage. It does not explicitly name when to use alternatives or exclusions, but the downstream scheduling 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuine value beyond that: the per-platform `supports.slideshows` flag (TikTok only) and the no-accounts fallback behavior, both of which are non-obvious operational facts.

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

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

Three short sentences, each doing distinct work: what it returns, how to use the ids, and the empty-state handling. The core purpose is front-loaded with zero filler.

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

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

With no output schema, the description carries the burden of describing returns, and it partially does (ids, supports.slideshows) but not the full shape (e.g., account names, platform identifiers, ordering). Adequate for a zero-param read tool, but not exhaustive.

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

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

Zero input parameters, so the schema baseline of 4 applies; there is nothing for the description to disambiguate on the input side.

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

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

States a specific verb and resource ('List the TikTok and YouTube accounts the user connected') and scopes it to SendShort, which cleanly separates it from sibling listers like list_videos or list_shorts. The mention of Settings → Preferences even tells the agent where the underlying data originates.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly routes the agent forward ('Use the ids with schedule_short and schedule_slideshow') and covers the empty case ('ask the user to connect one'). It doesn't state when not to call it or name a competing alternative, so it stops short of 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, openWorldHint=false, and destructiveHint=false, so the safety profile is fully covered structurally. The description adds only the ownership scope ('API key owner's'), contributing modest behavioral context without covering return shape or ordering.

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

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

A single front-loaded sentence with no filler. The verb and resource come first, and the qualifying detail follows immediately.

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

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

For a zero-parameter, read-only list tool whose annotations fully cover safety, this is nearly complete as a selection aid. The one gap is that without an output schema the description doesn't indicate what the listed entries look like (IDs vs names), though the clip_video reference partially compensates.

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

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

The tool takes zero parameters, so the schema baseline of 4 applies. The description usefully ties the output to the clip_video.starter_template_id field, giving the agent a sense of what the enumerated values feed into.

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

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

States a specific verb (List) and resource (starter templates) with an explicit scope (the API key owner's). The trailing reference to clip_video.starter_template_id distinguishes it from the many sibling list_* tools by naming where the results are consumed.

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 clause 'for clip_video.starter_template_id' makes the usage context clear: call this to obtain a valid value for that clip_video parameter. It gives no explicit exclusions or named alternatives, but the purpose-driven context is unambiguous.

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 provides specific structural context for the results, mentioning the key fields (id, name, font hints). This is valuable behavioral information about the returned object that goes beyond the general read-only safety hints provided in 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 a single, highly efficient sentence that front-loads all necessary information. It avoids filler and delivers the core functionality and scope immediately.

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

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

For a zero-input listing tool, the description is functionally complete. It defines the action, the data being acted upon (the presets), and the contexts in which the data is relevant (the two specified themes).

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?

Since the input schema has zero parameters and 100% coverage, the description adds semantic value by defining the structure of the returned data points (id, name, font hints). Given the lack of input complexity, a 4 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 specifies a clear verb ('List') and resource ('caption theme presets'), making the purpose unmistakable. It is highly granular by specifying that these presets are intended for two distinct workflows: clip_video.theme and create_music_video.theme.

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?

While the description defines exactly what the tool does, it does not provide explicit guidance on when to choose it over other sibling tools like 'list_templates.' The usage is implied to be when a user needs theme options for video creation.

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 handle safety (`readOnlyHint: true`). The description enhances this by detailing operational metadata (shorts count, slot usage), which informs the agent about the resource's current state and usage patterns, adding significant context beyond standard safety hints.

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

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

The two sentences are highly efficient; the first defines the resource and output, and the second defines operational constraints, making it succinct and professional.

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 lack of an output schema, the description provides crucial structural details about the returned data (specifically that it includes shorts data and slot usage) which makes the tool more complete than a generic 'list videos' call.

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%, meaning the schema defines the limits and offsets. The description does not add semantic meaning to the parameters (limit, offset, search), adhering to the baseline score for highly covered schemas.

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 ('user's imported long videos'), the specific data points returned (id, title, status, shorts count, slot usage), and the sorting order ('newest first').

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 explicit guidance on downstream use: 'Use a video id with list_moments or clip_video.' This prevents the agent from misapplying the tool's output.

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, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds real context: the ~5 minute posting window, calendar visibility, the precondition that the short must be exported, and that the returned schedule_id is not a final outcome. It doesn't spell out what 'destructive' practically means (e.g. cannot be un-posted once live), but it's meaningfully richer than 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?

Four tight sentences, front-loaded with the action and targets, then timing, preconditions, and return/follow-up. No filler, though the calendar mention is the least load-bearing clause.

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 nested-object mutation tool with no output schema, the description covers the critical gaps an agent needs: what happens on success (schedule_id), how to verify or undo, the export precondition, and timing semantics. Nothing essential to calling it correctly is missing.

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

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

Top-level schema coverage is 50%, but nested properties (caption, privacy_level, draft, tags, title) are individually documented in the schema. The description adds meaning the schema cannot: tiktok/youtube are alternative-or-both targets, publish_at omitted means immediate posting, and past timestamps are rejected. That compensates for the coverage gap.

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

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

States a specific verb (schedule) plus resource (an exported short) and the target platforms, which cleanly distinguishes it from schedule_slideshow and clip_video among the siblings. An agent knows immediately what this does without opening the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explains the targeting choice ('Set tiktok, youtube, or both') and the publish_at timing behavior, and names follow-up alternatives (list_scheduled_posts to check, cancel_scheduled_post to undo). It lacks an explicit 'use schedule_slideshow instead for slideshows' routing line, but the 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?

The description adds meaningful behavior beyond annotations: slides are re-rendered automatically if changed, posting occurs at publish_at within about five minutes, and omitting publish_at posts soon after the call. It also explains the return shape (one schedule_id per account) and points to list_scheduled_posts, though it does not mention cancellation or partial-account failure.

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 four tight sentences and front-loads the main action and platform scope. Every sentence contributes useful operational context without repetition 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 mutation tool with nested parameters, no output schema, and moderate schema description coverage, the description covers the essential call behavior and return handling. It could be more complete by noting that posts are public/open-world and cancellable via cancel_scheduled_post, but the core information 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?

Schema coverage is 67%, and the schema already documents parameters such as account_ids, caption, privacy_level, and publish_at. The description reinforces publish_at timing and slideshow_id sourcing but adds limited parameter meaning beyond the schema.

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

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

The description states a specific verb and resource: scheduling a user's slideshow to TikTok accounts as a photo post. It also clarifies the platform limitation (slideshows post to TikTok only), which helps distinguish this tool from broader short/video scheduling siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The usage context is implied clearly: use this to schedule a slideshow to TikTok, either at a chosen time or immediately. However, it does not explicitly state when not to use it or name alternatives such as schedule_short for non-slideshow content.

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