Show It Works

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

There are no annotations, so the description carries the full burden of behavioral disclosure. It states the core action of verifying and publishing, but it does not disclose side effects, reversibility, permission requirements, failure behavior if verification fails, or whether publishing is permanent. For a state-changing tool this is a significant 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?

The description is a single, front-loaded sentence with no filler. Every word contributes to conveying the verb and object, making it easy for an agent to parse quickly.

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

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

The tool performs a mutating publish operation with no annotations and no output schema, yet the description omits workflow context, side effects, failure semantics, and any details about what 'verify' entails. It is too sparse to be fully complete for safe invocation, even though the tool is simple.

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 provides only videoId and has 0% description coverage, so the description must compensate. The phrase 'an uploaded recording' adds minimal context that videoId identifies the recording to verify and publish, but the description does not explain the ID's origin, format, or constraints. The single self-descriptive parameter keeps this from being a lower score.

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

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

The description uses a specific action ('Verify... and publish it') and identifies a clear resource ('an uploaded recording'). It also implies a distinct lifecycle phase from siblings like create_video_upload, though it does not explicitly name or exclude sibling 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?

No guidance is given about when to call this tool versus alternatives. There is no mention of invoking it after create_video_upload, before get_video_link, or instead of delete_video. The workflow context is only implied by the sibling names and the phrase 'an uploaded recording.'

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

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

With no annotations, the description carries the full burden, and it does substantial work: it discloses privacy boundaries (ownerContext visible only to project members, publicContext only when public-safe), the project scoping by API key, and the locale/language requirements. It does not cover the subsequent workflow or mutations, but it provides meaningful behavioral context beyond the schema.

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

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

The description is a single dense paragraph that front-loads localization instructions before stating the core 'creates a direct R2 upload' behavior. The sentence 'The answer says so when what you sent is not in it' is vague and adds confusion. It is not excessively long, but it is not ideally structured or focused.

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

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

The description never mentions what the tool returns, how to use the result to upload the video bytes, or that complete_video_upload likely must be called next. With no output schema and a sibling named complete_video_upload, this omission leaves an agent guessing about the required workflow.

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

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

Schema coverage is only 56%, and the description compensates by adding real semantics for taskName, worktreeName, ownerContext, and publicContext: it explains what is public, what is private, when publicContext should be supplied, and how worktreeName should be derived. It does not add much for required parameters like filename, mimeType, or byteSize, but the schema already documents their ranges and enum.

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 that it 'creates a direct R2 upload for an MP4 or WebM recording, filed under the project this API key belongs to,' which clearly identifies the action and resource. It does not explicitly differentiate itself from siblings like complete_video_upload or get_video_link, but the 'creates' language and MIME-type scope make the primary purpose clear.

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

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

The description gives no guidance on when to choose this tool over complete_video_upload or search_videos, nor does it mention the likely two-step flow of creating then completing an upload. Sibling names exist in context, but the description itself never references them or gives exclusion criteria.

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

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

No annotations are provided, so the description carries the full burden. It clearly discloses that deletion is permanent (irreversible), which is a critical behavioral trait. It does not detail other side effects, but for a delete tool this is the key 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 with no filler. It is front-loaded with the action and its permanence, and every word earns its place.

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

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

For a one-parameter, no-output-schema delete tool, the description covers the essential purpose and irreversibility. The schema provides the required parameter. It lacks return-value or error details, but those are less critical for a simple destructive action.

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

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

Schema description coverage is 0%, and the description does not mention videoId at all. The only clue is the parameter name itself, which is self-explanatory but not elaborated. The description fails to compensate for the missing schema documentation.

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

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

The description states a specific verb ('permanently delete') on a specific resource ('a recording'). Among the sibling tools, only this one performs deletion, so it is immediately distinguishable.

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 intent is clear—use this tool when you need to permanently remove a recording. However, it provides no explicit guidance on when not to use it or any alternatives, leaving usage to be inferred.

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

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

No annotations are provided, so the description carries the burden. It discloses that the link is public, only available for ready recordings, expires after the retainUntil deadline, and that the expiry must be reported with the link. It does not detail error behavior or auth requirements, but the key behavioral facts are present.

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

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

The description is two sentences long, front-loads the main action, and contains no redundant wording. Every clause adds useful information about the link, the readiness precondition, or the expiry reporting requirement.

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 specifies what the caller should expect: a public link plus the retainUntil expiry. For a simple single-parameter getter, this is largely complete; only minor gaps like exact response format or behavior for non-ready recordings remain.

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 0%, and the description does not mention videoId explicitly. However, the phrase 'for a ready recording' implies the parameter identifies a recording, adding mild context beyond the schema. The single required string parameter is otherwise self-explanatory.

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 action and resource: 'Get a public link for a ready recording'. This clearly distinguishes it from the sibling upload, delete, list, and search tools, and the mention of 'public link' and 'ready recording' adds useful scope.

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 the key precondition: the recording must be ready, implying this tool is used after upload completion. It does not explicitly name alternatives or when-not-to-use cases, but the condition is clear enough to guide selection.

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

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

With no annotations present, the description carries the full behavioral burden and does so extensively. It discloses case/whitespace folding and variants, the 14–60 day retention window, default scoping to the caller's uploads, sort ordering, truncation semantics, and the nuanced counting behavior when filters or query are used. This goes well beyond a simple 'list' label.

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

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

The description is long, but nearly every sentence carries useful information and the most important purpose is front-loaded in the first sentence. It would benefit from light structural formatting, such as separating query behavior from filter behavior, but there is little redundancy given the complexity of the 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?

Despite having no output schema, the description thoroughly explains the response-relevant concepts: variants, recordingCount, untagged, firstUsedAt/lastUsedAt, truncated, and totalTasks. It also covers default ordering, retention-based visibility, and query-mode differences, giving an agent enough context to invoke the tool correctly and interpret its results even without an explicit response schema.

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

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

Schema description coverage is only 33%, so the description must compensate — and it does. It explains limit via truncation semantics, query via semantic matching and shortlist behavior, createdAfter/createdBefore as ISO timestamps affecting scope, and mine's default and override. It also adds meaning to taskName by explaining substring matching and normalized folding.

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

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

The description opens with a specific action and resource: 'List the task names already used in this API key's project.' It then gives the motivating purpose (reuse an existing task name instead of inventing a near-duplicate) and names the downstream tool, create_video_upload, which clearly distinguishes this tool's role from its sibling video-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?

The description clearly states when to use the tool — to find and reuse an existing taskName before calling create_video_upload. It also explains how different modes are selected (plain filters versus semantic query). It does not explicitly contrast this tool with list_videos or search_videos, but the task-focused purpose and the cross-reference to create_video_upload provide clear context without needing 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?

With no annotations provided, the description carries the full behavioral disclosure burden and handles it well. It explains that expired recordings are omitted, defines retainUntil as the deletion time for the recording and its public link, clarifies that firstViewedAt is null until first playback, and explicitly warns to ignore expiresAt as misleading plumbing.

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

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

The description is three sentences with no filler, and each sentence earns its place: the first states scope, the second explains row-field semantics, and the third prevents a likely misinterpretation. It is dense but appropriately sized for the behavioral details it must convey.

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 rightly supplies return semantics for key fields and the omission of expired recordings. It could add pagination or ordering behavior, but for a parameterless list endpoint the description is largely sufficient for correct invocation and interpretation.

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

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

The input schema has zero parameters and full schema coverage, so there are no parameter semantics for the description to add. The baseline of 4 applies because parameter documentation is effectively irrelevant for this parameterless tool.

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

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

The description opens with a specific verb and resource, 'List the recordings in this API key's project,' and enumerates what is included (dashboard reviewer comments and viewed status). This clearly differentiates it from search_videos and list_tasks as a project-wide listing operation.

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

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

The description implies when to use it: to retrieve all non-expired recordings for the current API key's project, with expiration behavior clarified. However, it never explicitly contrasts itself with siblings like search_videos or list_tasks, so an agent must infer the selection criteria rather than being told directly.

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

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

With no annotations, the description carries the full burden. It discloses that expired recordings are never returned, that matching is semantic and language-dependent, and that results are ranked. This goes beyond basic operation, though it could specify the return shape more precisely.

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 paragraph that is front-loaded with purpose, then usage, then filters. It's longer than average but every sentence contributes, covering rationale, filters, and caveats.

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 there is no output schema, the description explains ranking and expired exclusion, but doesn't describe result format. It covers language nuances and filter semantics, making it fairly complete for a search tool.

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

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

Schema coverage is only 17% (taskName). The description explains all optional filters: taskName substring matching, mine's behavior, createdAfter/Before ISO timestamps, and limit. It adds meaning beyond the schema, though it doesn't detail the query parameter's constraints.

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

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

The description clearly states it finds recordings by meaning and wording, and explicitly contrasts with list_tasks, which searches only your own uploads. This differentiates it from siblings.

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

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

It explicitly says to use it before inventing a new TASK value, and it notes that unlike list_tasks, it searches all project members' recordings unless 'mine' is passed. This provides clear when-to-use and when-not guidance.

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