Verification videos for AI coding agents: upload recordings over MCP and share viewer links. Keep work moving in parallel and review results asynchronously, when you're ready, from your laptop or phone. Add video evidence to pull requests so teammates can see how your changes work during code review.
Scored across 7 tools
The lifecycle tools (create_video_upload → complete_video_upload → get_video_link → delete_video) are clearly distinct steps with explicit ordering constraints. The main overlap is between list_videos/search_videos and list_tasks/search_videos, but the descriptions explicitly spell out the difference (exhaustive listing vs semantic search, and search_videos' differing default scope for `mine`), so misselection is unlikely.
All seven tools use consistent snake_case verb_noun form (create_video_upload, complete_video_upload, delete_video, get_video_link, list_tasks, list_videos, search_videos). The verb set (create/complete/delete/get/list/search) maps predictably onto the nouns, with no style mixing.
Seven tools is well-scoped for a video-recording service: an upload lifecycle, retrieval (link, list, search) and one supporting vocabulary helper. Each tool earns its place and none appears redundant with another.
Coverage spans the full lifecycle: create upload, complete it, list/search recordings, fetch a public link, and delete. Minor gaps remain — there is no update tool to amend a recording's task/title/context metadata, and no explicit status/health check beyond re-listing, but agents can work around both.
Publish a pending recording after its direct upload finishes. Call only after create_video_upload and a successful PUT of the entire file to the returned upload URL; this tool does not upload bytes. Requires a project API key with video.upload permission. Checks the stored object's byte size, MIME type and MP4/WebM container signature, not the correctness of the work shown or the full media contents. On success, changes PENDING to READY and returns the recording; use get_video_link next to retrieve its public viewer link and report retainUntil. Anyone with that link can watch until retainUntil; delete_video can remove the recording earlier. A size, MIME type or container-signature mismatch refuses publication and initiates deletion of the uploaded object. Failure to inspect the stored object's metadata marks the recording FAILED. For either failure, create a new upload and upload the file again rather than retrying completion on that recording. Only PENDING recordings can be completed: calling again after success returns an error, so use get_video_link instead.
| Name | Required | Description | Default |
|---|---|---|---|
| videoId | Yes | The video.id returned by create_video_upload, after the file has been successfully uploaded using its upload URL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the entire behavioral burden and does so thoroughly: it discloses the required permission (video.upload), the PENDING→READY state transition and returned recording, the exact validation performed (byte size, MIME, MP4/WebM container signature, but not content correctness), the destructive consequence of a mismatch (object deletion), FAILED handling, and non-idempotency (a second call errors). This is far beyond what any annotation would 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?
Front-loaded purpose followed by preconditions, validation, and failure modes in a logical order, and every sentence is substantive. It is dense at roughly seven sentences and repeats the 'use get_video_link' routing twice (once after success, once in the closing idempotency note), a minor redundancy that keeps it from a 5.
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?
No output schema exists, yet the description states what is returned ('returns the recording') and points to get_video_link for the viewer link and retainUntil. Given the single-parameter, no-annotation surface, an agent has everything needed to call this correctly and interpret the outcome.
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 videoId parameter is already documented in the schema as the value returned by create_video_upload. The description reinforces the same origin/sequencing but adds no new syntax, format, or constraint beyond the schema, 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+resource ('Publish a pending recording') plus the precondition that scopes it. Distinguishes itself from siblings by explicitly naming create_video_upload, get_video_link, and delete_video, so an agent knows where this sits in the workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit precedence: 'Call only after create_video_upload and a successful PUT', 'use get_video_link next', 'delete_video can remove the recording earlier', and an exclusion that this tool 'does not upload bytes'. The when-not-to-retry rule ('create a new upload ... rather than retrying completion') is spelled out, 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.
Write title, taskName, ownerContext and publicContext in English (code en, locale en-US) — this project's language — and follow that locale for dates and numbers. The answer says so when what you sent is not in it. Leave code, identifiers, commands and file paths exactly as they appear in the repository, and leave worktreeName as the checkout's own directory name rather than translating it. This creates a direct R2 upload for an MP4 or WebM recording, filed under the project this API key belongs to. Worktree and task are public; ownerContext is shown to project members only, never through the public link; publicContext is shown only when explicitly supplied as public-safe. This project is currently closed to new recordings: create_video_upload will be refused until an owner turns uploads back on in the project's settings. Do not record a session to upload here — ask the person you are working with first.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | ||
| byteSize | Yes | ||
| filename | Yes | ||
| mimeType | Yes | ||
| taskName | No | Concise public task name. Omit it if the task name is not safe to publish. | |
| ownerContext | No | Detailed context shown to every member of the project, never to public-link viewers. | |
| worktreeName | No | Public git worktree or repository name. Omit it if the real name is not safe to publish. | |
| publicContext | No | Context explicitly confirmed safe for anyone with the public viewer link. Never derive it from private context. | |
| workspaceName | No | Deprecated alias for worktreeName, kept for agents on an older skill version. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does a lot: it discloses the refusal condition for closed projects, the visibility tier of each field (worktree/task public, ownerContext members-only, publicContext public-safe only), and that validation failures are reported back ('The answer says so when what you sent is not in it'). It does not cover auth scope beyond the API key, retryability, or what the created upload returns.
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 opens with a long locale/translation preamble rather than what the tool does, and the operationally critical fact (uploads are currently refused) lands near the end. Every sentence is substantive, but the ordering is not front-loaded and the language rules are verbose.
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 mutation tool with no annotations, no output schema, and only 56% schema coverage, the description supplies the missing operational context: refusal state, field visibility, locale requirements, and a caution against unsolicited recording. The main remaining gap is the return value / upload handoff, which nothing else documents.
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?
At 56% schema coverage, the description adds real meaning beyond the schema by specifying which fields must be written in English (title, taskName, ownerContext, publicContext), how worktreeName must be left as the checkout directory name, and the audience/visibility semantics of the context fields. It says nothing about filename, mimeType, or byteSize, which the schema covers.
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 third sentence names a specific verb and resource: 'creates a direct R2 upload for an MP4 or WebM recording, filed under the project this API key belongs to.' That is concrete and distinguishable from siblings like complete_video_upload or list_videos, though the description never explicitly contrasts itself with them, and the purpose is buried behind a long writing-conventions preamble.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives explicit when-not guidance ('This project is currently closed to new recordings: create_video_upload will be refused...') and a strong precondition ('Do not record a session to upload here — ask the person you are working with first'). It does not name the natural follow-up sibling (complete_video_upload) or explain the multi-step upload flow, so it stops short of full routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Permanently delete a recording.
| Name | Required | Description | Default |
|---|---|---|---|
| videoId | Yes |
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.
Get a public link for a ready recording, with the retainUntil deadline after which the link stops working. Report the expiry alongside the link.
| Name | Required | Description | Default |
|---|---|---|---|
| videoId | Yes |
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.
List the task names already used in this API key's project, so you can reuse an existing one instead of inventing a near-duplicate. Copy taskName verbatim into create_video_upload. Names are folded case-insensitively and on whitespace, so one entry can cover several spellings, listed as variants. recordingCount is how many recordings carry the task right now, and untagged counts the recordings filed under no task at all. A name is listed while at least one of its recordings is still inside its retention window — 14 to 60 days after upload depending on the project's plan — and once the last of them reaches that deadline the name goes from this list with it. firstUsedAt/lastUsedAt are upload times. Only your own uploads are counted by default; pass mine: false to count every project member's. Without query, entries come back most-recently-used first, truncated means more names exist than limit returned, and totalTasks says how many. Other optional filters: taskName (substring), createdAfter/createdBefore (ISO timestamps), limit. A filter narrows the recordings that are counted, so the counts and dates then describe that window rather than the project's whole history. Optional query instead returns the tasks of the recordings that best match a description of the work, ordered by match quality — only the best-matching recordings nominate a task, so that answer is a shortlist rather than the project's whole vocabulary, totalTasks and truncated describe just those tasks, and untagged is omitted. The counts and dates of a task shown that way still cover every one of its recordings, not only the matching ones. query matches by meaning in any language, and a query in English (code en, locale en-US) — this project's language — also matches on wording.
| Name | Required | Description | Default |
|---|---|---|---|
| mine | No | Count only your own uploads. Defaults to true; pass false to include every project member's recordings. | |
| limit | No | ||
| query | No | ||
| taskName | No | Substring of a task name, matched case-insensitively. | |
| createdAfter | No | ||
| createdBefore | No |
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.
List the recordings in this API key's project, including dashboard reviewer comments and viewed status. Expired recordings are omitted; each row's retainUntil is when that recording and its public link are deleted, and firstViewedAt is when someone first played the public link, or null if nobody has. Ignore expiresAt, which is upload-authorization plumbing and always reads as past on a published recording.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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.
Find recordings in this API key's project by meaning as well as by wording — describe what the session was about, or name a task, and the closest recordings come back ranked. Use it before inventing a new TASK value, to find the recordings an earlier session already filed under one. Optional filters: taskName (substring), mine (only your own uploads — unlike list_tasks, this one searches every project member's recordings unless you pass it), createdAfter/createdBefore (ISO timestamps) and limit. Expired recordings are never returned. A query in any language works, because matching is semantic; this project works in English (code en, locale en-US), and a query in that language also matches on wording, which is the more precise half.
| Name | Required | Description | Default |
|---|---|---|---|
| mine | No | ||
| limit | No | ||
| query | Yes | ||
| taskName | No | Concise public task name. Omit it if the task name is not safe to publish. | |
| createdAfter | No | ||
| createdBefore | No |
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
complete_video_upload1 field changedInput schema / properties / videoId / descriptionAdded value: +"The video.id returned by create_video_upload, after the file has been successfully uploaded using its upload URL."complete_video_uploadcreate_video_uploaddelete_videoget_video_linklist_taskslist_videossearch_videosTeam memory for AI coding agents and code reviews, reviewed by humans and served over MCP.
Video review and collaboration for teams and agents: a full review interface for agentic video and motion graphics, feedback by voice, screen and drawing on the frame, agents that iterate version by version, and every version's notes and source files saved for the team.
Versioned artifact review for people and AI agents, with contextual comments and human control.
Human-in-the-loop for AI agents over MCP: durable approvals with a hosted review page & audit trail
Add one secure layer between your agents and this server.
