Skip to main content
Glama
KitDevUA

video-vision-mcp

by KitDevUA
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Server Quality Checklist

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

  • Latest release: v0.4.0

  • Disambiguation4/5

    Tools are generally distinct: analyze_video does full analysis, extract_frames_at targets specific timestamps, get_video_transcript_only is a fast path for transcript, and list_recent_analyses lists cache. However, get_video_transcript_only is a subset of analyze_video, which might cause some confusion for agents seeking only a transcript.

    Naming Consistency5/5

    All tool names use a consistent snake_case verb_noun pattern (analyze_video, extract_frames_at, get_video_transcript_only, list_recent_analyses), making them predictable and easy to understand.

    Tool Count5/5

    With 4 tools, the set is well-scoped for a video analysis server. Each tool serves a clear purpose without redundancy, and the number is neither too sparse nor excessive.

    Completeness4/5

    The tool surface covers core video analysis workflows: full analysis, targeted frame extraction, transcript retrieval, and cache listing. Minor gaps include lack of a delete cache tool or explicit backend configuration, but the set is functional for common use cases.

  • Average 3.9/5 across 4 of 4 tools scored. Lowest: 2.9/5.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • No commit activity data available
    • Last stable release on
    • 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

  • Behavior2/5

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

    With no annotations, description carries full burden. Only discloses that Gemini backend changes output format; no mention of auth, rate limits, mutability, or other behavioral traits.

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

    Conciseness3/5

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

    Very concise (3 sentences), but lacks structure. Some essential info missing; could be better organized.

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

    Completeness2/5

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

    Given 0% schema coverage and no annotation, the description is too sparse. Does not explain backend selection, parameter usage, or differentiate from siblings adequately.

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

    Parameters1/5

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

    Schema coverage is 0%, yet description provides no parameter details. Only says 'same inputs as analyze_video', which is insufficient for an agent to understand parameter meaning.

    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 it returns only transcript text (no frame images), and distinguishes from sibling tools like analyze_video. The mention of Gemini backend returning analysis text adds specificity.

    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?

    Implied usage as a faster alternative to analyze_video for text-only needs, but lacks explicit when-to-use or when-not-to-use guidance. Does not mention alternatives or exclusions.

    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 discloses important behavioral traits: backend-dependent output (real images vs textual descriptions) and timestamp format support. This adds significant value beyond the schema.

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

    Conciseness4/5

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

    The description is concise (two paragraphs) and front-loaded with the core purpose. Every sentence provides useful information, though the backend distinction could be more prominent.

    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 three parameters and an output schema, the description covers timestamp format and backend behavior but omits guidance on selecting url vs file_path and does not mention output schema contents.

    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 0%, so description must compensate. It explains timestamps format well but does not clarify the roles of url and file_path parameters, leaving ambiguity.

    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 extracts frames at specific timestamps. It distinguishes from siblings like analyze_video, get_video_transcript_only, and list_recent_analyses, which have different purposes.

    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 on timestamp format and backend differences (real images vs textual descriptions), but does not explicitly state when to use this tool versus alternatives or when not to use it.

    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 carries full burden. It implies a read operation (listing cached items) but does not disclose any potential side effects, rate limits, or refresh behavior beyond the generic description.

    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?

    Single sentence, front-loaded, every word adds value. No unnecessary content.

    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 zero-parameter list tool with an output schema, the description sufficiently explains what the tool does and what extra info it provides (backend). No missing crucial details.

    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, so schema coverage is trivially 100%. Baseline for 0 parameters is 4, and the description adds no parameter-specific info, which is acceptable.

    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 previously analyzed videos from the cache and includes backend info. It distinguishes from sibling tools which perform analysis, frame extraction, or transcript retrieval.

    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 vs alternatives. While context implies it is for retrieving past analyses, no exclusions or alternative suggestions are provided.

    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 provided; description carries full burden. Covers automatic backend selection, caching, frame budget cap, and that frame_interval is ignored by Gemini. 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?

    About 120 words, front-loaded purpose, clear sectioning for each parameter. No fluff, 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 output schema exists, description needn't detail return values. Covers inputs, parameters, caching, backend, and force_refresh. Complete for a tool with 4 params.

    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 description coverage is 0%, so description must compensate. It explains each parameter: url/file_path are mutually exclusive, frame_interval possible values and behavior, force_refresh bypasses cache. Adds significant meaning 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?

    Clearly states verb 'analyze', resource 'video', and outputs 'frames + transcript + metadata'. Differentiates from siblings like extract_frames_at and get_video_transcript_only by being comprehensive.

    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 requires exactly one source (file_path or url), provides guidance on frame_interval values, and mentions caching and force_refresh. Does not explicitly contrast with siblings but context implies this is the all-in-one tool.

    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

video-vision-mcp MCP server

Copy to your README.md:

Score Badge

video-vision-mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/KitDevUA/video-vision-mcp'

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