SkyCut

by smhunt

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.3.0
Disambiguation5/5
Each tool targets a distinct step in the video editing pipeline (init, scan, analyze, search, propose, edit, render, health), with clear descriptions preventing overlap. Even similar tools like scan and analyze are clearly distinguished by their operations and outputs.
Naming Consistency4/5
All tools use the 'skycut_' prefix and mostly follow verb_noun pattern. Exceptions like 'skycut_health' and 'skycut_project_status' use nouns, but the overall pattern is consistent enough for easy navigation.
Tool Count5/5
12 tools are well-scoped for a video editing MCP server, covering the full pipeline from setup to final render without unnecessary redundancy. Each tool serves a clear purpose.
Completeness4/5
The tool set covers the major workflow stages (init, scan, analyze, search, propose, edit, preview, render). Minor gaps exist (e.g., no standalone clip trimming or subtitle export), but the core pipeline is complete.
Average 4.2/5 across 12 of 12 tools scored. Lowest: 3.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 28 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=false and destructiveHint=false. The description adds key behavioral info: versions are immutable and results are saved as new versions. It details all operations, providing more transparency than the annotations alone. Missing details like atomicity or return behavior.
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?
The description is well-structured: purpose first, then immutability note, then compact operation list, then example. It is concise and front-loaded, using minimal text to convey essential information. Some redundant phrasing could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (multiple nested operations) and no output schema, the description provides operation details and the immutability behavior. However, it does not describe return values (e.g., new version ID) or error handling. This leaves gaps for an agent using the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has 100% coverage with descriptions for each parameter. The description summarizes the operations and provides an example, which adds slight value beyond the schema. However, the schema already covers the structure and constraints, so the description does not significantly enhance parameter understanding.
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?
The description clearly states the tool applies structured edits or replaces a timeline version. It lists all supported operations and distinguishes from sibling tools like skycut_get_timeline (read) or skycut_propose_cut (suggestion). The verb 'apply' and resource 'timeline edit' are specific and unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide explicit guidance on when to use this tool vs alternatives. It explains what the tool does but lacks when-to-use or when-not-to-use context. No sibling differentiation is mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate non-destructive and non-read-only behavior. The description adds context about using original files and requiring the drive, but does not disclose output location, potential overwriting, or side effects. It adds moderate value beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loading essential information. Every sentence is necessary and concise, with no fluff or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema and the description does not explain what the tool returns (e.g., file path, success status). For a simple tool, this is a notable gap, but other aspects like parameter and usage are adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear parameter description for 'version'. The description restates the requirement without adding new semantics. Baseline 3 is appropriate as the schema already handles parameter documentation.
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?
The description clearly states the tool performs a full-quality render with specific codecs, resolution, and audio from original files. The name 'render_final' is reinforced, and it distinguishes from siblings like 'render_preview' by specifying it's for final output.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly requires an explicit timeline version and a mounted drive. It warns against implicit 'latest' usage. While it doesn't name alternative tools, the sibling list suggests 'skycut_render_preview' for previews, providing clear context for when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate readOnlyHint=false and destructiveHint=false. The description adds valuable behavioral context: it saves an immutable timeline version and never renders. This clarifies side effects and boundaries 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise, front-loading the core action in the first sentence, then clarifying a critical behavioral note, and ending with an illustrative example. Every sentence serves a purpose. Could be slightly more structured (e.g., bullet points for constraints) but effective as is.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers key behavioral aspects and constraints. However, it lacks information about prerequisites (e.g., footage must be scanned) and the return value (e.g., a timeline ID for later retrieval via skycut_get_timeline). These gaps reduce completeness for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so all parameters are described in the schema. The description adds overall context (e.g., narrative arc, shot constraints) but does not enhance parameter-level meaning beyond the schema's descriptions. The example shows typical values, which is helpful.
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?
The description clearly states the tool assembles a timeline from the footage graph with specific narrative and technical constraints (narrative arc, 3-8s shots, crossfades, ±5% duration). It distinguishes itself from siblings like skycut_render_final (rendering) and skycut_apply_timeline_edit (applying edits) by explicitly stating it never renders.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: use when an AI director should create a timeline for review. It explicitly states what the tool does NOT do (rendering). The example gives a concrete scenario. However, it does not explicitly exclude cases or mention alternatives, like when to use skycut_apply_timeline_edit instead.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, so the description is consistent and adds context by explaining the query operation and listing searchable fields. No contradictions, and the description enriches the safety profile with a specific example and scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, all front-loaded with the verb. Every word is necessary, no fluff. Efficiently communicates the tool's purpose and key usage.
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?
Given 7 parameters and no output schema, the description explains the query capability and provides an example. It does not detail return format or pagination, but it is sufficient for understanding what the tool does. Annotations cover read-only behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 71%, which is high enough for a baseline of 3. The description provides an overview of filterable attributes but does not detail every parameter (e.g., exposure and stability are missing from description). The example adds some semantics but not full compensation.
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?
The description uses the specific verb 'Query' and specifies the resource 'footage graph for segments'. It lists multiple filter criteria (subject, camera movement, quality, aesthetic score, free text) and provides an example, clearly distinguishing this tool from siblings like skycut_analyze_footage or skycut_propose_cut.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for searching moments by various criteria, but it does not explicitly state when to use this tool versus alternatives or provide exclusions. No guidance on when not to use it or mention of sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, indicating the tool is safe and non-destructive. The description adds value by specifying the output format (JSON + human-readable shot list), going beyond what annotations provide. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that efficiently conveys the tool's purpose and output. Every word earns its place, with no superfluous information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one optional parameter, read-only, clear output description), the description fully covers what an agent needs to know. No output schema is needed as the description explicitly states the return format.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for the single optional parameter (version). The description's mention of 'timeline version; omit for latest' aligns with the schema but does not add additional semantic meaning beyond it. Baseline 3 is appropriate.
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?
The description clearly states the tool returns a timeline version (latest by default) as JSON plus a human-readable shot list. This specific verb+resource+output distinguishes it from siblings like skycut_propose_cut or skycut_apply_timeline_edit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this tool is for retrieving a timeline, but provides no explicit guidance on when to use it vs. alternatives (e.g., skycut_propose_cut, skycut_apply_timeline_edit) or when not to use it. The context is clear but lacks exclusions or comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavioral context beyond annotations: specifies proxy-based rendering, output destination, and operational conditions (source unplugged). Missing details like potential overwrite behavior but sufficient given the tool's simplicity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, no fluff, front-loaded with key information: resolution, speed, and source material. Every sentence is informative and earns its place.
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?
For a simple tool with one optional parameter and no output schema, the description covers purpose, behavior, output location, and edge case (source unplugged). Could explicitly confirm file creation but overall complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (description for 'version' parameter already present). The tool description reinforces 'latest by default' but does not add new semantic value beyond what the schema provides.
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?
The description clearly states it is a 'Fast 720p preview render of a timeline version from proxies', using specific verb and resource. It distinguishes from sibling 'skycut_render_final' by specifying 'preview', indicating a different use case.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use (for quick previews, when source drive is unplugged) but does not explicitly contrast with alternative tools like skycut_render_final. Provides clear context but lacks explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations provide readOnlyHint=true, so the description adds value by listing the specific dependencies checked (Node, ffmpeg, ffprobe, videotoolbox encoders, ANTHROPIC_API_KEY). It doesn't contradict annotations, and no additional behavioral context is necessary for a read-only health check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence plus an instruction, with no wasted words. It is front-loaded with the core purpose and then provides a usage tip, achieving high conciseness.
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?
Given the tool has no parameters, no output schema, and annotations cover safety, the description adequately covers what the tool checks and when to use it. It could optionally describe the output format, but the lack is not critical for a simple diagnostic tool.
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?
The tool has no parameters, and schema coverage is 100% through an empty schema. Per guidelines, 0 parameters and high coverage give a baseline of 4, and the description does not need to add parameter semantics.
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?
The description uses a specific verb 'Report' and clearly identifies the resource: status of required dependencies. It lists the exact dependencies, which distinguishes this tool from siblings that focus on editing, analysis, and rendering.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states to 'Run this first if any other tool returns unexpected errors,' providing clear context for when to use it. It doesn't specify when not to use it, but the guidance is sufficient for a diagnostic tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations provide idempotentHint and destructiveHint. The description adds valuable behavioral details: idempotent behavior (skipping existing clips/proxies on re-run), non-modification of source, and the specific outputs (database, manifest, proxies). This goes beyond annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action and file types, then details on idempotency and safety. No wasted words.
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?
The description explains what the tool does, its inputs (active project's source path), outputs (database, manifest, proxies), and behavioral traits. It lacks explicit mention of return value or error cases, but given no output schema and simple nature, it is mostly complete.
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?
With zero parameters, schema coverage is 100%, and no additional parameter info is needed. The description adds no param details, but baseline is 4 per guidelines.
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?
The description clearly states the tool's purpose: recursively index video files (specifying extensions), extract metadata using ffprobe, store in database and manifest, and build proxies. It is specific about the resource (active project's source path) and action (indexing and proxy creation), distinguishing it from sibling tools like skycut_analyze_footage which likely perform further analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives like skycut_analyze_footage. It implies usage for initial footage ingestion but lacks guidance on prerequisites or ordering, which would help an agent decide.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotent and non-destructive. The description adds that the source is read-only and derived files go to the workspace, which is valuable 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences plus an example, front-loaded with the main purpose, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description fully explains the initialization action, its side effects, and workspace behavior, sufficient for an agent to use it correctly given the sibling tools.
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 baseline is 3. The description adds meaningful context: the source path is read-only, name defaults to folder name and is slugified, plus an example. This goes beyond the property descriptions.
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?
The description uses a specific verb 'Create (or reopen)' and the resource 'SkyCut project', clearly distinguishing it from sibling tools like skycut_analyze_footage or skycut_render_final.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains that the source path is treated as read-only and derived files go to a specific workspace, providing context on when to use it. However, it does not explicitly state when not to use it or mention alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. The description adds value by listing the specific categories of state returned (scan progress, timeline versions, renders, drive mount), which informs the agent about the scope of data. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that efficiently lists the key state aspects without redundancy. Every word carries meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no parameters, no output schema, and clear sibling differentiation, the description fully specifies the tool's purpose and returns. No gaps remain for a simple status-read tool.
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?
There are zero parameters and schema coverage is 100% (trivial). The description adds meaning by detailing what the tool returns, which is sufficient for a no-parameter tool. Baseline is 4.
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?
The description clearly states the tool returns 'pipeline state for the active project' and enumerates specific aspects: scan/analysis progress, timeline versions, renders, and source drive mount status. This verb+resource combination distinguishes it from sibling tools like skycut_analyze_footage or skycut_get_timeline, which are action-oriented.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implicitly tells when to use this tool: when you need an overview of the pipeline state for the current project. While it doesn't explicitly state when not to use it or name alternatives, the context of siblings (e.g., skycut_health for system health, skycut_get_timeline for specific timeline details) provides indirect guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate idempotentHint true, readOnlyHint false, destructiveHint false. The description adds behavioral details beyond annotations: it discloses caching behavior (skips already-analyzed clips unless force=true), cost estimation for runs needing >500 frames, and the requirement to confirm large runs. No contradiction with annotations.
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?
The description is concise, using two sentences to cover purpose, caching, and cost estimate. It front-loads the key action. However, a slight restructuring (e.g., separating the cost estimate note) could improve readability.
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?
Given no output schema, the description adequately describes the output (scored segments with subjects, camera movement, quality flags). It also covers the caching and cost estimation behaviors. It is complete enough for an agent to understand the tool's function and side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters ('force' and 'confirm'). The description enriches meaning by linking 'force' to cache bypassing and 'confirm' to cost estimate approval, which goes beyond the schema's basic descriptions.
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?
The description clearly states the tool's purpose: sampling keyframes and analyzing with Claude vision to build a footage graph with scored segments, subjects, camera movement, and quality flags. It also mentions caching and cost estimation behaviors, distinguishing it from sibling tools like skycut_scan_footage (which likely just scans) and skycut_search_moments (which searches already analyzed data).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use 'force' (to skip cache) and 'confirm' (to proceed after cost estimate for large runs). It does not explicitly contrast with alternatives like scanning, but the caching and cost estimate details provide clear context for when to invoke this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds specific behavioral details: it lists volumes under /Volumes with free/total space in GB. This fully discloses what the tool does and returns, without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that is front-loaded with the action ('List volumes under /Volumes') and specifies the output format and purpose concisely.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no parameters, read-only annotations, and no output schema, this description is complete: it explains what is listed, the format, and the use case.
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?
There are no parameters, and schema coverage is 100% trivially. Per guidelines, 0 parameters yields a baseline of 4. The description adds no param info because none is needed.
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?
The description clearly states the tool lists volumes under /Volumes with free/total space in GB, and explicitly links its purpose to helping pick the source drive for skycut_init_project. This distinguishes it from siblings like skycut_init_project itself.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides context for when to use this tool (to pick source drive for skycut_init_project), but does not explicitly mention when not to use it or name alternatives. For a simple listing tool, this is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![skycut-drone-video-pipeline MCP server](https://glama.ai/mcp/servers/smhunt/skycut-drone-video-pipeline/badges/card.svg)](https://glama.ai/mcp/servers/smhunt/skycut-drone-video-pipeline)

Score Badge

Copy to your README.md:

[![skycut-drone-video-pipeline MCP server](https://glama.ai/mcp/servers/smhunt/skycut-drone-video-pipeline/badges/score.svg)](https://glama.ai/mcp/servers/smhunt/skycut-drone-video-pipeline)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/smhunt/skycut-drone-video-pipeline'

If you have feedback or need assistance with the MCP directory API, please join our Discord server