Server Quality Checklist

Tool Scores

• get_frame_burstA
  4.1/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description does not contradict these. It adds useful behavioral context beyond annotations, such as platform requirements (yt-dlp for certain sources), the default count, and the note that native frames are context-expensive.

  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 with a clear lead sentence, use-case paragraph, example, supported formats list, and Args section. It is slightly long but each section earns its place; the example effectively clarifies the even distribution behavior.

  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 tool has no output schema, and the description explains the return (N images, either file paths or base64 via returnBase64). It covers the supported source types, the motion-analysis context, and the maxWidth tradeoff. Sufficient for a 6-parameter tool with rich annotations.

  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%, so the schema already documents all parameters thoroughly. The description's Args section repeats url/from/to/count but omits maxWidth and returnBase64, though the schema descriptions for those are rich (e.g., context cost warning). The description adds minimal value beyond the 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?

  The description opens with 'Extract multiple frames evenly distributed across a time range,' which is a specific verb+resource+scope. It also differentiates from siblings by positioning itself for motion and vibration analysis, distinguishing it from get_frame_at (single frame) and scene-change-based tools.

  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 clearly states the intended use case — motion and vibration analysis where scene-change detection fails — and provides concrete 'Works for' examples like shaking, flickering, and animations. It lacks explicit exclusions or named alternatives, but the context is strong enough to guide an agent.

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

• get_frame_atA
  4.2/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds useful behavioral context beyond annotations: supported video sources, dependency on yt-dlp for many platforms, and a return type of a single image. It does not contradict 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 well-structured and front-loaded: purpose, use case, supported inputs, args, and return value. Every sentence earns its place; the supported-source list is long but necessary, and there is no filler.

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

  Completeness4/5

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

  For a tool with no output schema, the description adequately states what is returned. It covers supported input types, timestamp format, and use case. Minor gaps remain, such as not explicitly stating the default output is a file path unless returnBase64 is set, though that is covered in the schema.

  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%, and the schema contains detailed descriptions for all four parameters including maxWidth and returnBase64. The description repeats only url and timestamp with brief examples, adding little beyond what the schema already 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 opens with a specific verb+resource+scope: 'Extract a single video frame at a specific timestamp.' It clearly differentiates from siblings like get_frame_burst and get_frames by emphasizing a single frame at a precise moment.

  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 says it is 'Useful for inspecting what's on screen at a particular moment' and even outlines an AI workflow of reading a transcript and requesting a critical frame. It provides clear context but does not explicitly state when to prefer siblings like get_frame_burst or get_frames.

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

• get_framesA
  4.3/5.0
  Behavior4/5

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

  Annotations already establish read-only and non-destructive behavior. The description adds value by stating the output format ('optimized, deduplicated JPEG frames'), the extraction modes, and the list of supported sources. It does not mention rate limits or auth, but given annotations and the nature of the tool, this is adequate.

  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 front-loaded with the core purpose, then details modes and supported sources. Every sentence provides useful information without redundancy. It is slightly long but each segment earns its place, so it remains appropriately concise.

  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 covers the main operational aspects: purpose, modes, output, and supported sources. It does not explain every parameter (threshold, maxFrames) but those are documented in the schema. There is no output schema, yet the return type is mentioned. Given the tool's complexity and the richness of sibling comparisons, the description is sufficiently 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?

  The input schema covers all parameters with descriptions, achieving moderate schema coverage. The tool description enhances understanding by explaining the dense mode and providing practical guidance for maxWidth ('Raise it when the video is a screen recording whose meaning lives in small text'). This 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 verb 'Extract' and resource 'key frames from a video URL', and explicitly distinguishes itself from siblings by noting 'without transcript or metadata' and focusing on key frames rather than single frames or bursts. It also lists supported video sources, which further pinpoints its scope.

  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 two extraction modes (scene-change default vs dense) and when dense is appropriate ('full video coverage'). It does not explicitly name sibling tools like get_frame_at or get_frame_burst as alternatives, but the mode guidance and source list provide 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.

• analyze_momentA
  4.4/5.0
  Behavior4/5

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

  Annotations already provide readOnlyHint, idempotentHint, and destructiveHint values, so the safety profile is established. The description adds behavioral context by describing the composition of outputs (frames + transcript + OCR + unified timeline) and noting external dependencies like yt-dlp for certain platforms, which goes beyond the structured 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 front-loaded with a clear topic sentence, followed by a compact use-case list, a concrete example, and a concise support matrix. Each section earns its place and the structure makes it easy for an agent to scan and act on.

  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 tool with six parameters and no output schema, the description covers the core outputs, typical usage, parameter behavior, and supported input sources. It does not fully specify the exact response shape, but it provides enough context for an agent to select and invoke the tool appropriately.

  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 description coverage is 100%, so the baseline is 3. The description adds extra value by showing an example invocation mapping arguments to results, and by giving practical guidance on maxWidth for screen recordings with small text and context-cost tradeoffs. This meaningfully enriches the parameter understanding beyond the 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?

  The description clearly states it performs a 'deep-dive analysis' of a 'specific time range in a video' and names its combined outputs: burst frames, transcript filtering, OCR, and annotated timeline. This differentiates it from sibling tools like get_frame_at or get_transcript by emphasizing the integrated, segmented analysis. The example further concretizes the tool's purpose.

  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?

  It explicitly says 'Use this when you need to understand exactly what happens between two timestamps' and lists the visual and audio coverage of the tool. It does not name alternative tools to use instead, but the clear use case and supported platform list give strong contextual guidance.

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

• get_transcriptA
  4.5/5.0
  Behavior4/5

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

  Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it explains the fallback chain (native captions → Whisper), the dependency requirements (yt-dlp, @huggingface/transformers, whisper CLI, or OPENAI_API_KEY), and the sidecar file preference for local files. This goes beyond the annotations, though it doesn't detail error cases or rate limits.

  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 with a clear opening sentence, followed by return format, performance comparison, fallback details, and supported platforms. It's slightly long but every sentence adds necessary information. The platform list is dense but necessary for the agent to know what URLs are supported.

  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 (multiple platforms, fallback chain, dependencies), the description covers the key aspects: what it returns, when to use it, supported sources, and fallback behavior. It doesn't have an output schema, so the description's mention of 'timestamped transcript entries with speaker identification' is helpful. It could mention error scenarios (e.g., unsupported platform) but overall it's quite 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?

  Schema description coverage is 100%, so the schema already documents both parameters well. The description adds context by explaining the fallback behavior and that options only apply to the Whisper fallback, which is not fully clear from the schema alone. It also clarifies the 'url' parameter's accepted formats (Loom share link, platform URLs, direct video URLs, local paths). This adds value beyond the 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?

  The description clearly states the tool extracts only the transcript from a video URL, with a specific verb ('Extract') and resource ('transcript from a video URL'). It distinguishes itself from siblings by explicitly noting it's faster than analyze_video when only the transcript is needed, and the supported platforms are enumerated.

  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 guidance on when to use this tool vs alternatives: 'Faster than analyze_video when you only need the transcript.' It also details the fallback behavior (Whisper) and prerequisites (yt-dlp, API keys), which helps the agent decide if this tool is appropriate for the given URL type.

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

• analyze_videoA
  4.7/5.0
  Behavior5/5

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

  Beyond the annotations (readOnly, idempotent), the description reveals important behaviors: caching with forceRefresh, context cost implications of native frames, and fallback to uniform temporal sampling for static videos. This adds transparency that annotations alone don't provide.

  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 long but well-organized with bullet points and clear sections. Every sentence adds value; no fluff. Slightly verbose but appropriate given the tool's complexity.

  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?

  Covers all essential aspects: supported sources, return types, detail levels, options, and environmental defaults. No output schema is present, but the description enumerates the expected fields, making the tool's behavior fully understandable.

  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?

  All parameters have descriptive schema text (100% coverage), and the description adds practical guidance for each, e.g., 'maxWidth' explains when to raise it for screen recordings and the context cost. This goes beyond simple attribute names to explain intent and trade-offs.

  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 function: analyzing a video URL to extract transcript, key frames, metadata, comments, OCR text, and annotated timeline. It distinguishes itself from sibling tools like get_metadata or get_transcript by being the comprehensive analysis entry point.

  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 detailed usage instructions including supported video sources, detail levels, and customization options via the 'options' parameter. It does not explicitly compare to sibling tools, but as the primary analysis tool, this is rarely necessary. The description also explains when to adjust settings like maxWidth and threshold for specific use cases.

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

• analyze_videosA
  4.9/5.0
  Behavior5/5

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

  Even though annotations already declare readOnly, idempotent, and non-destructive, the description adds substantial behavioral context: per-item error isolation, cache/sidecar reuse, bounded responses with no inline frame images, and conditional field arrays based on options.fields. None of this contradicts the annotations and it meaningfully exceeds what the structured fields alone convey.

  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 well-structured with a clear lead sentence, a short pipeline/caching paragraph, a concise bulleted return-format section, and a final bounded-response note. Every sentence contributes information, and the formatting helps an agent scan it quickly.

  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 batch tool with no output schema, the description is remarkably complete: it explains the per-item success/failure shape, partial failure behavior, caching and sidecar persistence, response-size controls, and how it relates to analyze_video. An agent has enough context to select and invoke the tool correctly in most scenarios.

  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 description coverage is 100%, so the baseline is 3. The description adds useful semantic nuance by explaining that full transcript/OCR/timeline arrays are only returned when options.fields is set, otherwise counts are returned, and that frame images are never inlined. This goes beyond the schema's parameter descriptions without repeating every field.

  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 opens with a specific verb+resource: "Batch-analyze many videos in one call," and clearly distinguishes itself from the sibling analyze_video by emphasizing batch processing, per-item results, and a bounded response. It also states it runs the same pipeline as analyze_video, making the relationship explicit.

  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 explicitly says it is "Designed for processing a corpus of local files," recommends pairing with MCP_WRITE_SIDECARS=1, and tells the agent to "Use analyze_video on an individual source when you need the images or full data inline." This gives clear when-to-use and when-not-to-use guidance with a named alternative.

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

• get_metadataA
  4.9/5.0
  Behavior5/5

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

  Annotations already declare readOnlyHint, idempotentHint, and destructiveHint false, and the description does not contradict these. It adds valuable behavioral context: no video download or frame extraction, a yt-dlp requirement for certain platforms, and a performance comparison to analyze_video.

  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 three short, front-loaded paragraphs. The first sentence states the core purpose, the second adds a key behavioral distinction, and the third lists supported sources — every sentence earns its place with no filler or repetition.

  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 single-parameter, read-only, idempotent tool with rich annotations, the description is complete: it covers purpose, supported inputs, performance trade-offs, and key constraints. Even without an output schema, it clearly signals the expected deliverable types (metadata, comments, chapters, AI summary).

  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 covers the single url parameter at 100%, so the baseline is 3. The description adds meaning beyond the schema by specifying file:// URIs, the yt-dlp dependency for platform URLs, and concrete URL family examples, though the schema already includes most of the same type information.

  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 opens with 'Get video metadata, comments, chapters, and AI summary from a video URL,' giving a specific verb, resource, and output scope. It also distinguishes itself from sibling analyze_video by noting it is faster when only metadata is needed.

  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?

  It explicitly says to use this tool when you 'only need metadata' and directly compares to analyze_video ('Faster than analyze_video...'). The supported URL types and local file variants are enumerated, making applicability clear, and the 'without downloading the video or extracting frames' line implies when this tool is not appropriate.

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