Framesleuth

by thestackhub1

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.1.0
Disambiguation5/5
Each tool targets a distinct resource or action: list_* for enumerating options, analyze_video for creation, get_* for specific report components, render for output formatting, and render_html_video for HTML-to-video conversion. Even the two visual retrieval tools (get_keyframe_image and get_video_gif) are clearly distinguished by static vs. animated output.
Naming Consistency4/5
Most tools follow a clear verb_noun pattern (list_*, get_*, analyze_video, render_html_video). The main deviation is the bare verb 'render' which lacks an object, and 'locate_in_code' uses a prepositional structure, but overall the naming is predictable and readable.
Tool Count5/5
With 14 tools, the server is well-scoped for a video analysis platform. Each tool serves a distinct purpose in the workflow—analysis, report retrieval, configuration enumeration, and rendering—without unnecessary bloat or redundancy.
Completeness5/5
The tool surface covers the full lifecycle from video analysis (analyze_video) through report retrieval (get_report, get_repro_steps, get_error_evidence, etc.) to output generation (render, render_html_video). It also provides supporting tools like list_skills, list_actions, and list_reports to avoid dead ends. No critical gaps are apparent.
Average 4.1/5 across 14 of 14 tools scored. Lowest: 3.3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 15 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under Apache 2.0.
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?
Annotations already declare readOnlyHint and idempotentHint, covering the safety profile. The description adds 'timestamped' as a trait of the returned data but doesn't disclose other behavioral details such as error handling, return format, or prerequisites.
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, efficient sentence that avoids redundancy and gets straight to the point.
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?
For a simple read-only tool with one parameter and an output schema, the description is minimal but somewhat sufficient. It lacks usage context and explicit differentiation from siblings, leaving some ambiguity about when to invoke it.
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?
The schema has a single parameter (report_id) with no description, and the description's phrase 'for a report' provides some semantic context linking the parameter to a report. However, it does not explain the expected format or value domain beyond the schema's type string.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/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 with a specific verb ('Return') and resource ('timestamped error evidence for a report'). It distinguishes from sibling tools like get_timeline and get_repro_steps by focusing on error evidence, though it doesn't explicitly contrast with them.
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?
No guidance is provided on when to use this tool versus alternatives like get_timeline or get_repro_steps. The description only states what it does, not in which situations it should be chosen.
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?
The annotations already declare readOnlyHint=true and idempotentHint=true, covering the safety profile. The description adds little beyond the 'numbered' qualifier, and no behavioral details like auth requirements or rate limits are mentioned. It does not contradict 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?
The description is a single, front-loaded sentence with no redundant information. Every word earns its place, and it is appropriately sized for a simple getter tool.
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 simplicity, the existing annotation and output schema cover return values and safety. The description is complete enough for basic invocation, though it lacks usage context which is already penalized under its own dimension.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters2/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It only ties the parameter to 'a report', adding minimal meaning beyond the field name 'report_id'. No format, source, or constraints are provided.
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 ('Return') and clearly identifies the resource ('numbered reproduction steps for a report'). This distinguishes it from sibling tools like get_report or get_timeline, which target different aspects of a report.
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?
No guidance is provided on when to use this tool versus siblings like get_report or get_error_evidence. The context is implied but not explicit, and there are no exclusions or alternative recommendations.
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 provide readOnlyHint=true and idempotentHint=true. The description adds valuable context by stating 'Returns the rendered text' and clarifying that 'issue' means GitHub issue text, which goes beyond what annotations offer.
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 extremely concise, using two short paragraphs to convey the purpose, formats, and return type. Every sentence adds functional 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?
For a simple, read-only tool with an output schema and good annotations, the description covers the core functionality and return type. The only notable gap is the lack of explicit guidance about when to prefer this over sibling tools, but the complexity is low enough that this is not critical.
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 0%, so the description must compensate. It clearly explains the 'format' parameter with all allowed values and their meanings, while 'report_id' is naturally implied by the phrase 'Render a report', making the schema self-explanatory enough.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
Immediately states 'Render a report as a shareable artifact' with a clear verb and resource. The format parameter is explained, and while it doesn't explicitly name sibling tools, the focus on reports vs. videos distinguishes it from render_html_video.
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?
No explicit when-to-use guidance or alternatives are mentioned. It does not tell the agent when to use this tool versus get_report or render_html_video, nor does it provide any exclusions.
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 declare readOnlyHint=true and idempotentHint=true, which are consistent with the 'Return' operation. The description does not add extra behavioral context such as output format, error handling, or index bounds. Since annotations cover the safety profile, this is adequate but not enriched.
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 one concise sentence, front-loaded with the action and resource. No wasted words, and it covers the essential information.
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 two-parameter getter with read-only and idempotent annotations, the description is mostly complete. It states what is returned and how it is selected. It could mention the return format (e.g., URL or binary) but given the simplicity, this is a minor gap.
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 0%, but the description clarifies that 'index' selects the keyframe by its position. The role of 'report_id' is not explicitly explained, though its name is self-descriptive. This partially compensates for the lack of 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 'Return a keyframe image for a report by its index' clearly states the action (return), the resource (keyframe image), and the selection method (by report and index). It distinguishes from sibling tools like get_video_gif and render by specifying 'keyframe image' and 'report' context.
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 when to use this tool: when a specific keyframe image from a report is needed, identified by an index. However, it does not provide explicit guidance on when to choose this over alternatives like get_video_gif or get_report, nor does it mention any exclusions or prerequisites.
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?
The description does not contradict the annotations (readOnlyHint and idempotentHint are consistent with 'Return'). However, it adds no behavioral context beyond the annotation title 'Fused event timeline' — it merely paraphrases it. Since annotations already disclose the safe read-only nature, the lack of additional context is acceptable but provides no extra insight.
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, front-loaded sentence that gets straight to the point. Every word earns its place; there is no waste or redundancy. It perfectly balances brevity with clarity.
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 read-only tool with one parameter and an existing output schema, the description is mostly complete. It defines the tool's core purpose and scope. However, it lacks a bit of context about what 'merged' means (e.g., merged from which sources) and does not provide any usage alternatives, but the simplicity of the tool and the presence of the output schema mitigate this gap.
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?
The schema has one parameter (report_id) with no description (0% coverage). The description says 'for a report,' which implicitly ties report_id to a report, but it does not explicitly explain the parameter's format or purpose beyond the name itself. This provides minimal compensation for the schema gap, but the parameter is self-explanatory.
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: 'Return the merged event timeline for a report.' It uses a specific verb ('Return') and a distinct resource ('merged event timeline') that differentiates it from sibling tools like get_repro_steps or get_error_evidence. The scope ('for a report') is explicit.
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 when to use the tool (when you need the merged event timeline for a report) but does not provide explicit exclusions or mention alternatives. No sibling tools are referenced, so the agent must infer usage from the purpose alone. This falls short of clear guidance but is not misleading.
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 declare readOnlyHint and idempotentHint, but the description adds a valuable behavioral constraint: repo_root is never inferred and is required when the bundle lacks candidates. This goes beyond the schema/annotations and alerts the agent to a potential failure mode.
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 sentences, front-loaded with the main action, with no fluff. The information about repo_root is essential and placed prominently.
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 two-parameter tool with an output schema, the description covers the core behavior and the critical condition. It doesn't explain return structure, but the output schema handles that; some context around 'bundle' is still absent.
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 0%, so the description must compensate. It clearly explains the semantics and conditional requirement of repo_root, but leaves report_id and 'bundle' undefined, relying on contextual inference.
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 ('Return') and resource ('code candidates') with an explicit conditional ('or re-ground now'), clearly distinguishing this from sibling report/video/action tools. The title 'Locate suspect code' reinforces the purpose.
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?
No explicit when-to-use or alternative guidance is provided; however, the core statement implies the tool is for retrieving or creating code candidates. The repo_root conditional offers parameter-level guidance but not tool-selection 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 already convey idempotent and non-destructive. The description adds clamping behavior and on-disk caching per parameter set, which are not in annotations. It explains the caching side-effect but doesn't elaborate on potential output format or resource implications.
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 short paragraphs, front-loaded with the purpose, then a use case and parameter constraints. Every sentence adds value with no redundant content.
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 five parameters and no output schema. The description covers purpose, use case, and parameter constraints, but lacks any mention of the return format (e.g., GIF URL, bytes) and does not clarify the meaning of report_id beyond the schema. Given the absence of an output schema, more detail on the return value would be helpful.
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 0%, so the description must compensate. It mentions fps/width/start/end are optional and clamped, but does not explain what each parameter controls (e.g., units, meaning of start/end) or the clamp ranges. This is partial 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 clearly states the tool's function: 'Render an animated GIF preview of the video for a report.' This is a specific verb+resource+output combination that distinguishes it from siblings like get_keyframe_image (static image) and render_html_video (HTML video).
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 a concrete use case: 'Useful for embedding a short looping preview in an issue, chat, or PR description.' This tells the agent when to use the tool, but it does not explicitly mention alternative tools 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only and idempotent. The description adds meaningful behavioral details: the result is 'recomputed from the current bundle' to reflect latest grounding/quality, and items can be presented or used for auto-invocation. This goes beyond the structured hints, though it doesn't cover error cases or edge effects.
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 exactly two sentences, with the first sentence delivering the core purpose immediately. The second sentence adds necessary detail on item structure and recomputation without any fluff or redundancy. Every word 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 tool with one parameter, an output schema, and read-only/idempotent annotations, this description covers the essential aspects: what it returns and the dynamic 'recomputed' behavior. The output schema handles return details, so the description need not elaborate further. It lacks error handling notes but is sufficient for a simple read-only 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?
The input schema has only report_id with no description (0% schema coverage), so the description must compensate. It does add some context by saying 'for a report' and referencing the 'current bundle', implying report_id refers to a report within that bundle. However, it does not explain the ID format, provenance, or validation, which is a partial compensation only.
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 'Return' and clearly specifies the resource: 'the machine-readable next-step menu for a report'. It distinguishes itself from siblings like get_report by focusing on suggested actions, and even outlines the item structure ({action, label, rationale, ref}), leaving no ambiguity about the tool's function.
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 context for when to use the tool: when a report's next-step menu is needed, to be presented or auto-invoked. It does not explicitly contrast with siblings like list_actions, but the purpose is evident. It lacks an explicit when-not-to-use or alternative comparison, preventing a 5.
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 declare readOnlyHint and idempotentHint, and the description adds only that the modes are 'built-in' and include names and descriptions. This provides some context but no additional behavioral detail beyond what annotations and the description already imply.
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, clear sentence that is perfectly sized and front-loaded. Every word contributes to understanding the tool's purpose.
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 tool has no parameters and an output schema (though not shown), and the description states exactly what is returned (names + descriptions). This is complete for a simple listing tool, and the connection to analyze_video provides the necessary context.
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, the description has no parameter semantics to explain. The baseline for no params is 4, and the description adds no confusion.
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 a specific verb (list) and resource (built-in action modes for analyze_video), and the phrase 'for analyze_video' distinguishes it from sibling tools like list_skills. It is immediately clear what the tool does.
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 context by specifying that it applies to analyze_video, implying use when needing to discover available action modes. However, it does not explicitly state when to use it over alternatives or mention any exclusions, so it falls short of a 5.
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 and idempotentHint, so the description only needs to add context. It adds that the tool returns IDs only and that it aggregates across any analyzed video, which is useful behavioral nuance. It does not cover ordering or result size, but for a simple list operation with output schema, this is 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?
A single sentence of eight words that is front-loaded with the action and resource. Every word adds value: 'all available' indicates completeness, 'report ids' specifies the return type, and 'from any analyzed video' defines the data source. No waste or 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?
Given zero parameters, an output schema (which explains return structure), and annotations covering safety, the description is complete. It provides the necessary context to understand the tool's purpose and scope without needing further elaboration.
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 0 parameters, so the baseline is 4. The description correctly implies no inputs are needed, and the empty schema confirms this. There is no ambiguity or missing parameter 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 uses the specific verb 'List' with the resource 'report ids' and clarifies scope ('from any analyzed video'). It clearly distinguishes from siblings like get_report (which retrieves a specific report) and list_actions/list_skills (which list other entity types).
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: you use this when you need the list of available report IDs. However, it does not explicitly state when not to use it or mention alternatives such as get_report for retrieving a specific report. The guidance is implicit rather than explicit.
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 and idempotentHint. The description adds valuable behavioral detail: the 'slim' view returns an action-relevant subset, and the Literal typing was introduced to prevent typos that previously caused silently returning the full bundle. 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.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized at four sentences. The first sentence states the core purpose, the second explains the parameter options, and the following sentences justify the type design. Every sentence earns its place, and the content is front-loaded.
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?
With an output schema present and clear annotations, the description covers the main decision a caller needs to make (full vs slim) and the semantic meaning of the view parameter. It does not enumerate the contents of a Context Bundle, but the sibling tools and output schema fill that gap. Adequate for tool selection and invocation.
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 0%, so the description must add meaning. It thoroughly explains the 'view' parameter, including the enum values, default, and the rationale for using a Literal type. The 'report_id' parameter is left implicit, but its meaning is obvious from the tool's name and context.
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 begins with a specific verb and resource: 'Return the Context Bundle for a report id.' This clearly distinguishes it from sibling tools like get_repro_steps or get_error_evidence, which retrieve narrower pieces of data.
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 offers clear guidance on choosing between view='full' and view='slim' based on context window size, but it does not explicitly state when to use get_report instead of sibling tools. Usage is implied by the tool's purpose rather than explicitly contrasted with 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 and idempotentHint, covering safety. The description adds that skills are built-in and specific to analyze_video, providing context about the tool's scope. No contradiction. It doesn't describe additional behavior beyond what annotations and output schema cover, but the added scope is valuable.
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, action-first, no unnecessary words. Highly concise and easy to process.
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, read-only list tool with an output schema, the description sufficiently conveys purpose and scope. No missing information that would prevent correct invocation.
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 accepts zero parameters, so there is no parameter semantics to document. The description adds no parameter details, but none are 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 uses a specific verb 'list' and identifies the resource as 'built-in summary skills' scoped to 'analyze_video'. This clearly distinguishes it from sibling list tools like list_actions and list_reports.
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 usage when the agent needs to discover available summary skills for analyze_video. The scope is clear, though no explicit exclusions or alternative tool names are given. This is sufficient given the tool's simple nature.
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 description adds substantial behavioral detail beyond annotations: frame-by-frame capture with no dropped frames/quality loss, specific codecs and formats, resolution/fps ranges, output written to the bundle directory, and dependencies (Playwright + ffmpeg). It does not contradict 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?
The description is two brief paragraphs, front-loaded with the core purpose. Every sentence adds value: purpose, use case, capture/encode behavior, output location, and dependency note. No waste.
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?
With an output schema present, the description need not explain return values. It covers the main operational aspects: self-contained HTML input, output formats, quality, resolution/fps limits, file location, and runtime dependencies. This is sufficient for a tool of moderate 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 description coverage is 0%, so the description must compensate. It adds meaning for format (mp4/gif/webm), fps range (5-60), resolution (up to 4K), and output path. It does not explicitly explain duration_s, but the parameter name and default make it reasonably clear.
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: 'Render an HTML document (CSS / JS / canvas animation) to mp4/gif/webm.' This clearly distinguishes it from sibling tools like analyze_video or get_video_gif, which focus on existing videos rather than generating new ones from HTML.
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 to export a self-contained animated HTML page (e.g. one you just designed) as a shareable clip,' giving clear context. It does not explicitly list when not to use it or name alternatives, but the use case is precise enough.
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?
Beyond the annotations, the description discloses important behavioral traits: analysis takes multiple minutes, progress is streamed via ctx, action is auto-picked when omitted, and system_prompt/action_prompt override skill/action. This adds meaningful context without contradicting 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?
The description is long but every section earns its place: a one-line summary, use-case framing, a complete Args block, and Returns expectations. It is well-structured and front-loaded with the core purpose.
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 is self-contained: it covers purpose, usage, all parameter semantics, behavioral notes, and return values. It references sibling tools like list_skills and list_actions for valid enum values, and the output schema is complemented by the explicit Returns list.
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?
Since schema description coverage is 0%, the description fully compensates by explaining every parameter in detail: path formats, repo_root grounding, intent examples and effect, skill/action enum hints with defaults, and override relationships. This goes far beyond the raw schema types and null defaults.
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 'Analyze any video and return the new report id', which clearly states the verb, resource, and output. It distinguishes itself from sibling get_*/list_* tools by emphasizing creation of a new report from video input, reinforced by the diverse video examples.
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 when-to-use context: any video that needs to be distilled into an actionable Context Bundle for a coding agent. It does not explicitly mention alternatives or exclusions, but the use case is specific enough for an agent to select it appropriately.
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:

[![framesleuth-agent MCP server](https://glama.ai/mcp/servers/thestackhub1/framesleuth-agent/badges/card.svg)](https://glama.ai/mcp/servers/thestackhub1/framesleuth-agent)

Score Badge

Copy to your README.md:

[![framesleuth-agent MCP server](https://glama.ai/mcp/servers/thestackhub1/framesleuth-agent/badges/score.svg)](https://glama.ai/mcp/servers/thestackhub1/framesleuth-agent)

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/thestackhub1/framesleuth-agent'

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