StreamClipping AI

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

Beyond the destructiveHint annotation, the description discloses important conditional behavior: failed or already-cancelled posts are permanently deleted, and the response's action field reports what occurred. This adds substantial context about outcome and idempotency that annotations alone do not provide.

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

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

Three sentences, front-loaded with the core action and immediately followed by edge-case behavior and response disclosure. Every sentence adds useful information with no waste.

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, single-parameter tool with rich annotations and an output schema, the description covers the essential behavioral nuance (live vs. not live, conditional deletion, response field) without needing to restate return values. It is complete for correct invocation.

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

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

Schema coverage is 100% for the single scheduledPostId parameter, so the schema already documents its meaning and expected status. The description adds no syntax, format, or additional semantics beyond what the schema provides; baseline 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 ("Cancels a post") and adds meaningful scope ("that has not gone out yet" / "no effect on a post that is already live"). It does not explicitly name or route against any sibling tool, so it is clear but lacks sibling differentiation.

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 clearly states when the tool applies (scheduled, not yet live) and when it has no effect (already live). It does not name alternative tools or explain how to choose another sibling, so it falls short of the 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?

Goes well past the annotations by disclosing environment prerequisites, the plan gate, that processing minutes are consumed, and that the clip becomes visible asynchronously in list_clips only after processing. The non-idempotent, non-destructive nature is consistent with the annotations and the "now" semantics make repeat-call consequences implicit.

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 sentences, each carrying distinct information: action, prerequisites, cost, and result visibility. The prerequisite clause is a long run-on that could be a bulleted list, but nothing is padding.

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 an output schema exists and the parameter is fully documented, the description covers everything an agent still needs: when this applies, what must be true, what it costs, and where the result surfaces. No significant gap remains for correct invocation.

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

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

Schema coverage is 100% and the single seconds parameter is documented with its enum values and default, so the schema carries the meaning. The description restates "the last 30 or 60 seconds" and anchors it to "now," but adds no formatting or edge-case detail beyond that.

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 action and resource: save the OBS replay buffer now and turn the last 30 or 60 seconds into a clip, explicitly likened to the in-app clip button. The live-stream framing separates it from start_clipping and generate_clips, though it never names those siblings directly, so differentiation is inferred 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?

Gives a clear triggering context ("During a live stream") plus three hard prerequisites: agent running and connected on the streaming PC, replay buffer enabled, and a Creator/Pro/Elite plan. It stops short of naming alternatives for non-live or VOD scenarios, so an agent must infer what to use instead when the stream is offline.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds concrete consequence detail beyond the annotations: the deletion is permanent and the video file is erased. It omits auth requirements and failure behavior, so it falls short of a 5.

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 zero filler; the permanence consequence and the confirmation requirement are both front-loaded. Every sentence carries information an agent needs.

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?

An output schema exists, so return values need not be explained, and annotations cover destructiveness. The description supplies the remaining critical facts (irreversibility, confirmation requirement) for a destructive two-parameter tool, though it says nothing about what happens on a false confirm or missing clipId.

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

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

Schema description coverage is 50%: 'confirm' is documented in the schema but 'clipId' has no description anywhere. The description reinforces that confirmation is explicit and required, adding minor value, but it does not compensate for the undocumented clipId parameter (format, source of the id). Baseline 3 is appropriate given partial coverage.

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

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

States a specific verb and resource ('deletes a clip') plus scope beyond the name ('and its video file'), which lets an agent distinguish it from get_clip, list_clips, and update_clip. It does not explicitly name a sibling, but the destructive verb makes the boundary obvious 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?

The description states a prerequisite ('Requires an explicit confirmation argument'), which is genuine usage guidance. However, it gives no when-to-use/when-not context versus siblings like update_clip or cancel_scheduled_post, and does not explain when deletion is appropriate. Guidance is implied by the destructive verb only.

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=false, idempotentHint=false, and destructiveHint=false, so the mutation profile is covered. The description adds that detected moments are approved as a side effect, but says nothing about rendering being long-running/asynchronous or how to track progress. Adequate but thin beyond 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?

One sentence, zero waste, with the action and the gating status front-loaded. Nothing to trim and nothing 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?

An output schema exists, so return-value explanation is unnecessary, and the precondition is covered. However, for a render-triggering job the description omits whether rendering is asynchronous and how the agent should follow up, which is material given the presence of get_project and retry_project siblings.

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

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

There is a single parameter with 100% schema description coverage; the schema already explains that projectId must reference an AWAITING_REVIEW project. The description merely restates that constraint, adding no new meaning. Baseline 3 applies when the schema carries the parameter 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 specific verbs and resource: approves detected moments and starts rendering videos for a project. The AWAITING_REVIEW precondition distinguishes it from siblings like start_clipping and retry_project, though it never names an alternative 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?

Gives clear preconditions - the project must be in AWAITING_REVIEW status - which tells the agent when this tool applies. It does not state what to do instead for projects in other statuses or how this relates to start_clipping.

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 a safe read-only, closed-world operation, so the description is free to add the non-obvious semantics: the import failure mode when minutes are exhausted and the trial quota resetting at midnight local time in the trialDaily field. It does not cover auth or freshness of the counters, but the operational caveats it does provide are genuinely additive.

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 front-loads the list of returned values, then adds two short caveat sentences about quota behaviour. Nothing is redundant, though the field enumeration reads as a run-on list rather than a scannable structure.

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 tool with an output schema and readOnly annotations, the description supplies everything an agent needs: what is returned, the read-only nature of credits, and the quota reset rule. Return-value structure is left to the output schema, which is correct.

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

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

There are zero input parameters, so the baseline is 4. The description does useful extra work by naming the specific response fields (credits, trialDaily) and flagging that credits is read-only, which aids interpretation of the output.

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 resource — the account's plan, minutes, magic-clipping quota, credits and connected social accounts — so an agent knows exactly what it gets back. It does not explicitly contrast with siblings like get_analytics or list_social_accounts, even though 'connected social accounts' overlaps with the latter, so differentiation is only implicit.

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 line 'An import fails when minutes run short' implies a pre-flight check before import_vod, which is a useful usage cue, but it is never framed as 'call this before X' and no alternative tools are named or excluded. Usage is inferable rather than stated.

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

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

Annotations already declare this a safe, closed-world read (readOnlyHint true, destructiveHint false, openWorldHint false). The description adds genuinely non-obvious behavioral context beyond them: the dataset is limited to posts published from StreamClipping AI, which tells the agent results may under-report versus native platform analytics. It does not mention any auth or permission requirements, but for a read-only tool with annotations covering the safety profile this is a modest gap.

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

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

Two short sentences, zero filler, with the content of the report front-loaded and the important coverage caveat placed as a separate scoping sentence.

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?

An output schema exists, so the description needn't explain return shape, and the schema documents both parameters thoroughly. The only meaningful gap is the absence of any note on how per-platform figures are aggregated or what happens when no data exists in the window, which is minor for a two-parameter read tool.

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

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

Schema description coverage is 100%, so the creator scoping rules and the 7/30/90-day window are already fully documented in the schema. The description reinforces the period concept ("over a period") and hints at a per-platform breakdown, but adds no syntax or format detail beyond what the schema provides, 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?

The description names the concrete metrics returned (views, likes, top posts), the grouping dimension (per platform) and the analysis window, so an agent knows exactly what this tool produces. It is clearly the only analytics/reporting tool among the siblings, though the verb is implicit ("Views, likes and top posts") rather than an explicit "retrieve".

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

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

There is no explicit when-to-use statement or comparison to a sibling, and no alternative analytics tool exists to route to. The scope restriction ("Only covers posts published from StreamClipping AI") functions as an implicit when-not condition, which is useful but is the only usage guidance present.

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 the set of metadata fields, but this largely duplicates the available output schema and does not disclose permissions, error behavior, or how the clip is identified.

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 that lists the metadata categories without introductory fluff. It is appropriately sized, though the field list is somewhat redundant given an output schema exists.

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 lookup tool with one required parameter and an output schema, the description covers returned fields but leaves the parameter and call context unaddressed. It is adequate at a high level but missing the practical details an agent needs to invoke it confidently.

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

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

Schema description coverage is 0% for the single required clipId parameter, and the description never mentions clipId or explains its expected format/source. The name is intuitive, but the description contributes no semantics beyond the raw 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 names the resource (clip metadata) and enumerates the fields returned, making the tool's output clear. However, it omits an explicit retrieving verb and does not differentiate from siblings like list_clips or get_project, so it is clear but not fully distinguishing.

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 when-to-use guidance, no mention of alternatives such as list_clips, and no prerequisites (e.g., needing a clipId from list_clips). The agent receives no routing information.

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, destructiveHint=false and a closed-world scope, so the safety profile is covered. The description adds real value on top: it enumerates the observable pipeline state, exposes error reporting, and hints at polling cadence, plus an explicit negative scope ('Does not return the transcript') that prevents a wrong-expectation call.

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, zero filler: the first front-loads what the agent gets back, the second closes the one non-obvious gap (no transcript). Nothing is repeated from the annotations or schema.

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?

An output schema exists, so return-value exposition is not required, and the description still gives an accurate summary of the payload plus the polling cue. Only minor gaps remain (auth requirements, error/failure semantics when the project does not exist or is not found).

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?

One parameter with 100% schema coverage; the schema already documents projectId as the project identifier. The description adds no syntax, format, or sourcing guidance for the ID, 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?

The description names a specific verb+resource ('Detailed status of a project') and enumerates the returned contents (pipeline steps, error, clips, next action, polling delay), which lets an agent separate it from list_projects or get_clip. It stops short of naming any sibling explicitly, so differentiation is inferred 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?

Implied usage only: mention of 'next expected action' and a 'suggested polling delay' signals this is the status-polling call after starting a project, but the description never says when to prefer it over list_projects or retry_project, nor states prerequisites such as a project already existing.

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 mutation (readOnlyHint=false) and non-idempotency, and the description adds pipeline-state context (project lands in AWAITING_CROP, clipping not started). It does not cover duplicate imports of the same URL, failure behavior for private/ended streams beyond what the schema says, or auth needs — the remaining gaps are meaningful for a non-idempotent create.

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, zero filler. Purpose first, then the state/next-step constraint, which is the highest-value thing an agent needs to know before calling.

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?

Output schema exists, so return values need not be explained, and the description covers purpose plus the state transition that gates the next tool. It stops short of noting invalid/private-VOD failure modes or duplicate-import consequences, a small but real gap for a create operation.

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 per-parameter meaning is fully documented in the schema (platform URL forms, title fallback for YouTube, creator scoping, ISO language). The description adds nothing parameter-specific, but it reinforces the accepted platform set at URL level, which is slightly beyond the schema 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?

States a specific verb ('creates a project') and resource (a VOD from named platforms), and explicitly distinguishes the action from start_clipping, a listed sibling. An agent can tell exactly what this tool does and where it sits in the pipeline.

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 follow-up step: 'Importing does not start clipping: start_clipping is the next step once the project reaches AWAITING_CROP.' That gives the agent both the when-to-use condition and the routing to the sibling tool after the call succeeds.

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 the safety profile is covered. The description adds the account-connection prerequisite and hints at the returned link, but it is slightly redundant with the platform param description and says nothing about how 'recent' is determined or about result limits/pagination.

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 tight two-clause sentence with the resource and the actionable purpose front-loaded; every phrase carries information. Nothing is wasted, though it could be marginally clearer about ordering/limit in the same space.

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

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

With an output schema present, the description need not explain return values, and it correctly supplies the prerequisite and downstream-use hint. The main gap is silence on the limit parameter and recency semantics, which an agent calling this list tool would benefit from knowing.

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 50%: platform is documented in the schema, while limit exists only with structural constraints (default 10, max 50). The description does not mention limit or what 'recent' ordering means, so it fails to compensate for the uncovered parameter, leaving it at minimum-viable.

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 resource (recent VODs / stream replays) for a defined scope (the connected Twitch or YouTube channel), and clarifies the payload's purpose by naming the downstream tool import_vod. It is clear enough to separate from list_clips, though it does not explicitly contrast with that sibling.

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 clear context of use (fetching VODs to pass their link to import_vod) and an explicit prerequisite (the matching account must be connected). It stops short of stating when not to use it or naming a competing sibling to avoid.

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, covering the safety profile. The description usefully adds the default sort (viral potential) and the source of titles/hooks, but says nothing about pagination/cursor limits or result volume beyond what the schema provides.

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

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

Two sentences, front-loaded with scope and default ordering, with no filler. The second sentence about titles/hooks earns its place by explaining where those fields originate.

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?

An output schema exists so return values need not be described, and annotations cover the safety profile. Scope and default ordering are stated; the definition is adequate for a low-risk, zero-required-parameter listing tool.

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

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

Schema description coverage is high (83%) with self-documenting descriptions for cursor, sortBy, status, creator and projectId, so the structured data carries the load. The description's mention of 'account or of one project' and default sort largely restates the schema rather than adding syntax or edge-case meaning.

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

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

States a specific verb+resource ('Clips of the account or of one project') plus the default sort behavior, making the scope clear. It does not explicitly distinguish itself from the singular sibling get_clip, relying on the plural to imply listing.

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 only implied by the listing nature of the tool; there is no explicit when-to-use guidance or reference to alternatives such as get_clip for a single clip or list_projects for project scoping. An agent can infer its role but is given no routing rules.

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 a safe, read-only, closed-world operation, so the bar is lower. The description still adds value by disclosing the default ordering (newest first) and what each returned project carries (status and next expected action), which goes beyond the annotation set. It stops short of mentioning pagination or page-size behavior.

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

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

A single sentence that front-loads the resource, then scope, then ordering, then returned fields. 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?

An output schema exists, so return-value detail is not required, and the description still previews the notable fields. For a simple, low-risk list tool with fully documented parameters and annotations, this is nearly complete; only pagination/refresh semantics are unaddressed.

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

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

Schema description coverage is 100%, so the schema already documents limit, cursor, and creator thoroughly. The description adds only the 'newest first' ordering, which largely duplicates the limit parameter's own description. Baseline 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?

States a clear verb+resource ('Video projects of the account') plus scope and ordering ('newest first') and the fields returned ('status and the next expected action'). It is easily distinguished from get_project or list_clips by name, though it never explicitly contrasts itself with those 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?

Usage is implied by the name and the scoping to 'the account', but there is no explicit when-to-use guidance, no mention of when to prefer get_project for a single project, and no stated prerequisites or exclusions.

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 a safe, read-only, non-destructive, closed-world operation. The description adds that returned items include a public link and view count, which is mild context, but it says nothing about pagination, ordering, or the 50-item cap behavior that annotations don't cover.

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 short sentence with no filler, which is efficient, but it is a bare noun phrase that leads with enumeration rather than stating the action and scope up front.

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

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

An output schema exists so return values need not be spelled out, but the description leaves dangling basics: which organization/creator scope is default, how limit behaves, and how this differs from the other list_* tools. For a zero-required-parameter listing tool this is thin.

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%: the creator parameter is fully documented in the schema, but limit has no description and the tool description compensates for neither. It adds no syntax, default, or scoping detail beyond what the schema already provides.

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

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

The description names the resource (posts) and enumerates the statuses covered (scheduled, in-progress, published, failed), plus the payload (public link, view count). However, it has no verb and never distinguishes itself from sibling list tools like list_clips or list_projects, so an agent must infer that this is the post-listing endpoint.

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

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

There is no when-to-use guidance, no mention of how this relates to cancel_scheduled_post, schedule_post, or the other list_* siblings, and no note on default scoping (limit defaults to 20, creator omitted covers all creators). The agent gets no routing help.

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 covered. The description adds useful context by scoping results to the StreamClipping AI account and indicating that status and publishability are included. However, it does not mention pagination, ordering, or limits, which is a modest gap against the already-rich annotation set.

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, front-loaded sentence that identifies the resource and the key fields returned. Every clause adds meaning 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?

With zero parameters, clear read-only annotations, and an output schema, the description only needs to establish scope and purpose. It does so adequately by naming the account scope and the returned status/publishability information. A minor omission is the absence of any note about result ordering or volume, but that is not essential for correct 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 tool takes zero parameters, so there is no parameter semantics burden on the description. The baseline for zero parameters is 4, and nothing in the description creates confusion about inputs.

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 resource ('Social accounts connected to the StreamClipping AI account') and what information is included ('status and whether an assistant can publish to them'). It is clear what the tool returns, but it does not explicitly distinguish itself from siblings like get_account or list_channel_vods.

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

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

There is no explicit guidance on when to use this tool versus alternatives such as get_account. The 'list' prefix implies enumeration, but the description provides no conditions, exclusions, or alternative routing.

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

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

Annotations declare idempotentHint=true, destructiveHint=false and readOnlyHint=false, so the mutation profile is largely handled structurally. The description adds real value beyond that by disclosing resumption semantics: it continues from the last valid step rather than re-running from scratch and is non-destructive. It omits what happens if the project is not in FAILED status or whether the retry is long-running.

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 sentence with no filler, front-loading the action and the state constraint. Every clause earns its place.

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

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

For a one-parameter action whose safety profile is covered by annotations and whose return values are covered by an output schema, the description is essentially sufficient. Minor gaps: failure behavior on non-FAILED projects and whether the operation is asynchronous.

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?

Only one parameter and schema description coverage is 100%; the schema already states 'Project in FAILED status.' The description reiterates the same constraint, adding no format, ID-source, or lookup guidance beyond it. Baseline 3 applies when the schema carries the 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?

States a specific verb (resumes) plus the resource (project) and its applicable state (FAILED status). The clause 'from the last valid step, without starting over' makes it distinguishable from a fresh-start tool like start_clipping or generate_clips, though no sibling is named explicitly.

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

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

The precondition is clear: the project must be in FAILED status, which is the when-to-use condition. It does not state what to do instead when the project is not FAILED, so the alternatives side is 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?

Adds real context beyond annotations: plan-tier entitlement for X, near-immediate publishing when scheduledAt is omitted, the requirement for explicit confirmation, and the TikTok eligibility gate. It does not restate irreversibility (that lives in the confirm schema field) but covers the non-obvious operational constraints well.

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

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

Front-loads what the tool does, then stacks constraints in short declarative sentences with no filler. The plan-tier parenthetical is slightly dense but materially useful.

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 mutating, multi-platform publish tool with an output schema, this covers the key decision points an agent needs: platform eligibility, entitlement, timing semantics, confirmation, and the cross-tool dependency on list_social_accounts. 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?

Schema description coverage is 100%, so the schema already documents title defaults, ISO 8601 format, READY status for clipId, and canPublishHere for socialAccountId. The description reinforces the omit-date behavior and TikTok gating but adds little syntax or edge-case detail the schema lacks; 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 (schedules a clip for publication) and enumerates the supported destination platforms (YouTube Shorts, Instagram Reels, X). It is clearly distinguishable from siblings like list_scheduled_posts or cancel_scheduled_post.

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 concrete gating conditions: X requires a paid Pro/Elite plan, omitting scheduledAt publishes within a minute, and TikTok requires canPublishHere from list_social_accounts. It does not explicitly point to cancel_scheduled_post for reversal or list_scheduled_posts for verification, so the sibling routing is partial.

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

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

Goes well beyond the annotations by disclosing the cost model: processing minutes proportional to duration and a magic project drawn in a stated order (monthly quota, then bought Magic, then wallet Credit), which also explains why the call is non-idempotent. It reports that creditUsage reveals Credits used and remaining, but says nothing about failure behavior or whether a partially processed project is resumable.

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

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

Front-loaded with the action and state requirement in the first sentence; the second sentence carries the cost chain. Dense and mostly waste-free, though the quota-ordering detail is verbose for the value it adds.

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 charged, non-idempotent mutation with an output schema and full annotation coverage, the description supplies the missing piece an agent needs — the economic consequence and where creditUsage comes from. Nothing essential to calling it correctly is absent.

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 all three parameters including the magic mode and startAtSec offset are fully documented in the schema. The description adds only the cost consequence of magic=automatic mode, which is already largely restated by the schema field description, so baseline 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?

Names a concrete verb pair (starts transcription and moment detection) and the resource (a project), plus the required AWAITING_CROP state. It doesn't explicitly contrast itself with nearby siblings like generate_clips or retry_project, but the action is specific enough to distinguish it from list/get 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?

The precondition 'project in AWAITING_CROP status' tells the agent when the call is valid, which is genuinely useful. However, it never says what to do when the project is in another status, or whether retry_project/cancel-type siblings are the fallback, so alternatives are 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?

Annotations already declare destructiveHint=true and idempotentHint=true, and the description corroborates this with 'overwrites ... with the values given'. More importantly it discloses non-obvious behavior annotations cannot: editing does not re-render the video, so a hook change only takes effect in the file after a new render. That is real added value beyond 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?

Two tight sentences, zero filler, and the operative fact (what gets overwritten) is front-loaded before the caveat about rendering. Every clause earns its place.

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

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

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The description covers the main gotcha (no re-render), but omits what happens to fields not supplied and any permission/lock requirements for editing a clip.

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 80%, so the schema already documents most parameters (title, hashtags 'without the # sign', hookText, description). The description only restates those field names as a group and adds the render caveat for the hook; it does not clarify whether omitted fields are left untouched or cleared. Baseline 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 names a specific verb (overwrites) and enumerates the exact editable fields (title, description, hashtags, hook) on a clip, so the agent can identify it as a metadata-mutation tool. It stops short of explicitly contrasting with siblings such as get_clip or delete_clip, but the resource and operation are unambiguous.

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

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

Usage is implied by the mutating verbs and the field list, but the description offers no explicit when-to-use guidance, no prerequisites (e.g. clip must already exist / be rendered), and no mention of alternatives if any exist. Nothing is misleading, but an agent must infer the calling context.

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