media-downloader

Build Watch Skill

build_watch_skill

Create or update a video-derived skill document, managing frontmatter, provenance, and version bumps while refusing duplicate video entries.

Instructions

Write a video-built skill, or append another video's findings to one.

You supply the body - reading the transcript and frames is your job, not this tool's. It owns the mechanics: frontmatter, the provenance table every claim stays traceable to, the version bump, and WORKFLOW.md.

Appending a video the skill already lists is refused rather than duplicated, so re-running a pipeline is safe. Call list_watch_skills first to see which skill a new video belongs to.

Default to append. Use replace when the new source contradicts the skill, changes a conclusion, supersedes rather than extends it, leaves the body no longer reading as one document, or outgrows the description. A create or replace without a "What would change this skill" section is refused.

Input Schema

Name	Required	Description	Default
`body`	Yes	The markdown body you wrote from the bundle, starting with a '# Title' heading and ending with a '## What would change this skill' section naming the evidence that would revise it. Do not include a Sources section - it is generated from the manifest.
`mode`	No	'create' a new skill, 'append' a video's findings, or 'replace' the body	create
`name`	Yes	Skill name; becomes the directory name
`tags`	No	Comma-separated frontmatter tags
`description`	No	Skill description; required when creating
`skills_root`	Yes	Directory the skill lives in (one subdirectory per skill)
`manifest_path`	Yes	Path to the watch bundle's manifest.json, for provenance

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv4.4.7Oct 31, 2026

TDQS

A4.5/5.0

Behavior4/5

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

With no annotations, the description carries the burden well: it discloses idempotency ('Appending a video the skill already lists is refused... re-running a pipeline is safe'), the required body shape, the auto-generated artifacts (frontmatter, provenance table, WORKFLOW.md), and that create/replace without a 'What would change this skill' section is refused. It does not say what happens to the existing body on `replace` or what permissions/paths are needed, so a 4 rather than 5.

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

Conciseness4/5

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

Front-loaded with the action, then responsibilities, then mode selection, then hard refusals. Slightly long with a trailing paragraph on refusal rules, but every sentence carries operative information; no filler.

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

Completeness4/5

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 no explanation, and the description covers delegation of reading transcripts/frames, generated artifacts, and refusal conditions. The only meaningful gap is the mismatched `mode` default between prose and schema.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3; the description adds real decision semantics on `mode` (default append, when to choose replace) and on what `body` must contain. However, it states 'Default to `append`' while the schema declares `mode` default 'create' — a conflict the agent must resolve, which keeps this below 5.

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

Purpose5/5

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

Opening sentence names specific verbs (write / append) and a concrete resource (video-built skill), and the tool is clearly distinct from siblings like list_watch_skills and watch_media. An agent knows exactly what this tool produces.

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

Usage Guidelines5/5

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

Explicit routing guidance: 'Call `list_watch_skills` first to see which skill a new video belongs to', 'Default to `append`', and a clear enumerated set of conditions selecting `replace`. Alternatives and exclusions are both named.

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

Deploy Server