video-capture-mcp

by Corvus400

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

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

Latest release: v0.5.1
Disambiguation5/5
Each tool has a distinct purpose: permissions check, cleanup, frame extraction, window region detection, pointer movement, session management, and various recording start/stop variants. Even similar tools like start_recording and start_app_window_recording are clearly differentiated by target and use case.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern in snake_case (e.g., check_macos_permissions, list_active_sessions, stop_recording). No mixing of camelCase or inconsistent verb styles.
Tool Count5/5
With 12 tools, the server covers setup, recording, extraction, pointer control, and session management without being bloated. Each tool serves a clear function, and the count is appropriate for the domain.
Completeness4/5
Core workflows (record, stop, extract, cleanup, permissions) are covered. Minor gaps exist, such as no explicit tool to list available iOS simulators or Android devices, but the overall surface is comprehensive.
Average 4.5/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on May 25, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
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

Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries the full burden. It describes output files and forwarding of options, but lacks details on blocking behavior, permissions needed, or whether it kills existing recordings. More behavioral details would improve score.
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?
Description is concise with 6 sentences, front-loaded with purpose, followed by usage and output details. No wasted words, well structured.
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's complexity (combines recording and extraction) and that output schema exists (though not shown), description covers key aspects. Lacks error handling or timeout details, but is largely complete for typical use.
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% (all parameters have descriptions in schema). Description adds context like output directory structure and forwarded options, but does not add substantial new meaning beyond the schema. Adequate but not exceptional.
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?
Description clearly states the tool records a target for a fixed duration and extracts frames in one call. It distinguishes from siblings like start_recording, stop_recording, and extract_frames by combining both actions.
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?
Explicitly says to use when recording length is known upfront and no interactive stop needed, and mentions start_recording + stop_recording for unknown durations. Could be slightly improved by explicitly stating not to use when recording length is unknown.
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?
With no annotations provided, the description carries full burden. It discloses that the tool 'posts only mouse-move events and does not click,' and explains response fields like moved_count and final position. It also mentions app activation behavior. Missing details on permissions, but overall sufficiently transparent.
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 concise, with no redundant sentences. It front-loads the core purpose, then provides usage context, parameter explanations, and response details in a logical order. Every sentence 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?
Given the tool has 5 parameters, one required, and an output schema, the description covers the main behavioral aspects, parameter roles, and response fields. It is well-rounded but could mention potential limits or error conditions. Overall, it provides sufficient context for an agent to use the tool effectively.
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 schema has 100% description coverage, so baseline is 3. The description adds value by explaining the role of steps_per_segment and step_delay_seconds beyond their schema descriptions. It also clarifies the format of points, though the schema already covers this.
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 starts with 'Move the macOS pointer through hover/unhover points without clicking,' clearly stating the verb and resource. It distinguishes itself as a hover-only tool and mentions it is the preferred fallback for inaccessible pages, differentiating it from sibling tools like move_pointer.
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 when to use this tool: 'for canvas-style, WebGL, native, or otherwise inaccessible pages.' It provides guidance on parameters like app_name for activation. However, it does not explicitly mention when not to use it or alternatives, though the context implies it is for hover without clicking.
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?
With no annotations, the description fully discloses behavior: activates app, verifies window visibility, records via screencapture -R, and returns error with window details on validation failure. No contradictions and no hidden side effects omitted.
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?
Eight sentences, ~90 words, front-loaded with core purpose. Every sentence adds essential information with no redundancy. Highly efficient.
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?
Covers purpose, use case, workflow, error handling. References sibling tool (stop_recording). Output schema exists but description explains error response. Slightly missing info on what happens if recording already exists, but acceptable given other strengths.
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. Description adds workflow context for duration_seconds (manual vs timed) and explains options forwarding. This goes beyond raw schema 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 records only the visible front-window region of a macOS app, using specific verbs and resource. It distinguishes itself by noting it's the first choice for Chrome, Safari, and desktop-app debugging.
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?
Provides clear usage context: first choice for specific apps, workflow guidance (omit duration_seconds for manual-stop, then call stop_recording), and mentions error handling for visibility failures. Lacks explicit when-not-to-use but sufficiently guides correct invocation.
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?
No annotations are provided, so the description must disclose behavioral traits. It mentions filtering by target and response grouping, but does not explicitly state the destructive nature (e.g., loss of unsaved data) or how recordings are terminated. Some behavioral context is given, but more transparency would improve agent understanding.
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 four sentences with no unnecessary words. Each sentence serves a distinct purpose: main action, use cases, parameter guidance, response structure. Front-loaded with the primary function.
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 simplicity of the tool (one optional parameter, no required fields, output schema exists), the description covers all key aspects: when to use, how to filter, and what the response contains. It does not list all possible aliases but references start_recording, which is acceptable.
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% with a clear description for the single parameter. The description adds value by listing example aliases ('macos, ios_simulator, android') and explaining the effect of omitting the parameter, which goes beyond the schema's description.
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 action 'Stop all live recording sessions', specifies the context 'for this server process', and distinguishes from the sibling stop_recording by emphasizing 'all' sessions. The verb and resource 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit use cases are provided: client lost session_id, duplicate-target protection blocking start_recording, or before a fresh verification run. This gives clear guidance on when to invoke this tool versus 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?
No annotations, so description covers key behaviors: requires Accessibility permission, no clicking, returns coordinates. Could add more on error handling but sufficient.
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?
Three concise sentences, front-loaded with action, 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?
For a simple two-param tool with output schema, description covers purpose, usage, requirements, and return value. 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% with clear descriptions. Description adds context about hover-only purpose but doesn't repeat parameter details. 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?
Description clearly states it moves macOS pointer without clicking, distinguishes from hover_sequence by noting single-point vs multiple points. Verb+resource is specific.
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?
Explicitly mentions when to use (single-point hover-only desktop checks) and when not (multiple points prefer hover_sequence). Also notes alternative tool by name.
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 description discloses behavioral traits such as file verification (checking file_exists, file_size_bytes, pull_returncode) and potential failure modes (missing/empty file, permission failures). Since no annotations are provided, the description carries full burden; it covers key behaviors but does not discuss rate limits or authentication details.
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 concise (6 sentences) and well-structured: purpose, usage condition, verification steps, error recovery, and permission handling. Every sentence adds value with no redundancy.
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, combined with the input schema and presence of output schema, provides complete guidance for correct usage. It covers when to use, what to expect, and how to handle failures, making it fully adequate 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% (single parameter 'session_id' fully described in schema). The description does not add new semantic meaning beyond what the schema provides; it merely restates the parameter's origin. 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's purpose: 'Stop one manual recording session and verify the produced file.' It identifies the specific resource (a recording session) and distinguishes from the sibling tool 'stop_all_recordings' by specifying 'one manual recording session'.
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?
The description provides explicit usage context: call after 'start_recording' or 'start_app_window_recording' returns a session_id and UI interaction finishes. It also gives post-call verification steps and error recovery instructions, including alternative tools ('list_active_sessions', 'cleanup_stale_processes') and permission handling.
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?
Discloses behavioral traits beyond schema: max_frames limits and dropped_for_max reporting, inline_images warning about context exhaustion, rotate_degrees normalization, and threshold effect. Lacks error handling info (e.g., missing file).
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?
Concise and well-structured: front-loads main purpose, then explains modes, then other parameters. No redundant sentences.
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 8 parameters, 2 required, and presence of output schema, the description covers purpose, modes, parameter effects, limitations, and prerequisites. Adequate for the complexity.
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?
Adds significant meaning beyond schema descriptions: explains scene_threshold range and effect, fps ignored for scene mode, inline_images warning. Schema coverage is 100%, but description enhances 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 it extracts key frames or fixed-rate frames from a recorded video, with specific verbs and resource. It distinguishes two modes and explains their use cases.
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?
Provides clear context on when to use each mode (scene vs fixed_fps) and mentions prerequisite (ffmpeg/ffprobe). However, it does not explicitly state when not to use this tool or reference sibling tools like record_and_extract for 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?
Discloses important behavioral traits: macOS requires Screen Recording permission, describes workflow with stop_recording, and lists response fields. Without annotations, description carries burden and does so well, though could mention potential limitations like concurrent sessions.
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?
Well-structured with clear sections: general purpose, target aliases, options breakdown, workflow guidance, response info, permission note, and sibling pointer. Every sentence adds value with no redundancy.
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?
Covers multiple platforms, options, workflow choices, permission requirements, and alternative tools. Lacks details on error handling or concurrent recording limitations, but overall complete for a tool of this complexity.
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%, but description adds significant value: target alias mapping, platform-specific options details, workflow guidance for duration_seconds, and response content preview. Enhances understanding beyond schema.
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?
Description clearly states it starts recording a macOS, iOS Simulator, or Android screen target. It distinguishes from sibling tools like start_app_window_recording and stop_recording, which are explicitly mentioned as alternatives or complementary actions.
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?
Provides explicit guidance on when to use this tool vs start_app_window_recording for browser/desktop-app debugging. Also explains manual-stop workflow vs duration, and mentions target aliases to aid selection.
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?
With no annotations provided, the description carries full burden. It discloses that the tool returns visible, visible_ratio, region, frame, and screen details. It mentions the activate param defaults to true and sets expectations for measuring background windows. No destructive behavior is noted, but activation behavior is covered. This is good transparency, though it could mention potential side effects of activation.
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 concise, with 5 sentences covering purpose, usage, parameters, and response. No redundant information. It is well-structured and front-loaded with the core purpose. Every sentence adds value.
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 moderate complexity (4 parameters, 1 required) and the existence of an output schema (context signal), the description is complete. It explains the typical use case, parameter defaults, response structure, and error recovery. No gaps identified.
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 semantic value beyond schema descriptions: it explains that min_visible_ratio should be lowered only when partial visibility is intentional, and activate should be set to False only when measuring a background window intentionally. This provides important usage guidance that the schema alone lacks.
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 the visible front-window region for a macOS app, using a specific verb+resource. It distinguishes itself from siblings by explicitly mentioning its use before app window recording, indicating it is a verification step rather than a recording tool.
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?
The description provides explicit usage context: use before macOS app or browser recording to verify window visibility. It explains the min_visible_ratio default and advises when to lower it. It also instructs what to do if visible is false (reposition or unminimize), effectively guiding the agent on when and how to use the 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?
Discloses scope limitation (only current process) and lists all response fields; no annotations provided, so description carries burden adequately.
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-sentence description with immediate clarity, no fluff, and logical flow from purpose to constraints to output details.
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 simple list tool with output schema, description covers scope, sibling distinction, and return fields fully.
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?
No parameters exist; schema coverage 100% and baseline for 0 params is 4; description adds no param info as none 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?
Description uses specific verb 'list' and resource 'recording sessions owned by this running server process', clearly distinguishing it from sibling tools like cleanup_stale_processes.
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?
Explicitly states when not to use it and provides an alternative tool: 'use cleanup_stale_processes for that case'.
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?
Discloses key behavioral aspects: the response indicates whether Screen Recording works, which launcher process is evaluated, where permission must be granted, and that the MCP client must be fully restarted after changing the setting. No annotations exist, so description carries full burden and does it well.
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?
Description is concise at four sentences, front-loaded with purpose. Every sentence provides distinct value. Slight room for trimming but overall well-structured.
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 zero parameters, an output schema exists (so return values are documented), and no annotations, the description fully covers behavioral context, usage guidance, and outcomes. Nothing missing.
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?
No parameters exist in the input schema, and schema coverage is 100%. With no params to describe, the baseline of 4 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?
Clearly states the tool diagnoses macOS Screen Recording permission for Claude Code/Codex users, specifying the exact resource and action. Distinguishes from siblings by referencing other tools that need different permissions.
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?
Explicitly states when to use this tool (before retrying start_recording or start_app_window_recording when TCC may be blocking), when not to use it (iOS Simulator, Android recordings), and that pointer tools need Accessibility instead.
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?
Discloses scope (only processes owned by current OS user) and output format (killed records under 'cleaned'). No annotations, so full burden is met.
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?
Four sentences with zero waste. Front-loaded with purpose, then usage guidance, then behavioral detail. Efficient.
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?
Fully covers purpose, usage context, behavioral constraints, and output info. Output schema exists, so return values are covered. No gaps.
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?
No parameters in schema; description adds no param info, but none is needed. Baseline 4 applies for 0-param tools.
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?
Clearly states the tool cleans up recording processes left by dead server processes, with specific verb and resource. Distinguishes from sibling tools like start_recording which automates this check.
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?
Explicitly says when to use (after stale-process error or interrupted client run) and when not to (start_recording handles automatically). No confusion with alternatives.
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:

[![video-capture-mcp MCP server](https://glama.ai/mcp/servers/Corvus400/video-capture-mcp/badges/card.svg)](https://glama.ai/mcp/servers/Corvus400/video-capture-mcp)

Score Badge

Copy to your README.md:

[![video-capture-mcp MCP server](https://glama.ai/mcp/servers/Corvus400/video-capture-mcp/badges/score.svg)](https://glama.ai/mcp/servers/Corvus400/video-capture-mcp)

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/Corvus400/video-capture-mcp'

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