Reka
Server Details
Understand your videos with Reka AI — search, ask questions, and extract insights.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.1/5 across 17 of 17 tools scored. Lowest: 3/5.
Each tool has a clearly distinct purpose. For example, search_videos finds timestamps, ask_video answers questions, get_transcript returns raw text, and segment_video detects objects. There is no overlap that would cause confusion.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., upload_video, get_transcript, list_groups). No deviations or mixed conventions are present.
With 17 tools, the count is slightly above the typical range for a focused server. However, each tool serves a necessary function in the video analysis pipeline (upload, indexing, search, QA, grouping, etc.), so the count is justified.
The tool set covers the full video lifecycle: upload, deletion, update, indexing with multiple pipelines, search, question-answering, transcript retrieval, scene detection, object segmentation, and group organization. There are no obvious gaps for the stated domain.
Available Tools
17 toolsask_videoARead-onlyInspect
Ask a question about one or more videos with visual analysis. Most effective on focused time ranges — use start/end to specify the segment to analyze.
BEFORE calling this tool, read the reka://docs/guide resource for recommended workflows. In most cases, you should first:
search_videos to find WHEN something happens, then pass those timestamps here as start/end
segment_video to detect and locate specific objects
get_transcript to read what was said
For single-video questions, pass video_id with start/end. For cross-video questions, pass videos — a list of video references with start/end each.
For follow-up questions, pass conversation_id from the previous response. You can add start/end to drill into a specific moment while keeping the conversation context.
Requires qa_only or full pipeline.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| videos | No | ||
| question | Yes | ||
| video_id | No | ||
| rationale | No | ||
| conversation_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description aligns with readOnlyHint=true (no destructive actions). It adds behavioral detail: 'Most effective on focused time ranges' and explains how to use start/end for precision. No contradictions. Minor missing details (e.g., response format) but output schema exists.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: starts with core purpose, then provides workflow guidance, then parameter details. Each sentence is informative and necessary. No redundancy or fluff. Ideal length given complexity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 7 parameters (1 required), 0% schema coverage, and an output schema, the description is complete. It covers single-video, cross-video, follow-up scenarios, and prerequisite steps. It also mentions 'Requires qa_only or full pipeline,' adding system context. No gaps for an agent to use correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 0% description coverage, but the description compensates by explaining parameter usage: video_id with start/end for single video, videos list for cross-video, conversation_id for follow-ups. It adds meaning beyond the schema, though video_id is optional but described as primary. The description effectively guides parameter usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Ask a question about one or more videos with visual analysis.' It identifies the resource (videos) and action (ask question with visual analysis), and distinguishes from sibling tools by referencing them (search_videos, segment_video, get_transcript) for different tasks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit guidance is provided: 'BEFORE calling this tool, read the reka://docs/guide resource... In most cases, you should first: search_videos... segment_video... get_transcript...' It also differentiates single-video vs cross-video usage and explains follow-up workflow. The description clearly states when to use this tool and suggests alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_groupBInspect
Create a new video group. Groups organize videos into collections. Returns the new group's ID and name.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| rationale | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description identifies the tool as a creation operation that returns ID and name, but does not disclose side effects, permissions, or constraints like name uniqueness.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences efficiently convey the purpose and return value, though the second sentence adds little new information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple create tool, it provides the basic purpose and return type, but lacks usage context and parameter details that would fully guide an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description only vaguely relates the 'name' parameter to organizing videos, with no explanation of 'rationale'.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states the action 'Create' and the resource 'video group', clearly distinguishing it from sibling tools like list_groups and delete_group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, prerequisites, or situations where it should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_groupADestructiveIdempotentInspect
Delete a video group. Videos in the group are not deleted — they are simply removed from the group.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | ||
| rationale | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructive and idempotent behavior. The description adds the critical detail that videos are only removed from the group, not deleted, which is valuable context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the main action, and every word adds value. No unnecessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and annotations, the description covers the key behavioral nuance. However, it omits potential prerequisites or error conditions, which would be helpful for a destructive operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, but the description does not explain the parameters. While 'group_id' is self-explanatory, 'rationale' is not mentioned, leaving its purpose ambiguous.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and the resource ('video group') and explicitly distinguishes that videos are not deleted, which differentiates it from sibling tools like delete_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for deleting groups without affecting videos, but it does not explicitly state when to use this tool over alternatives like create_group or list_groups, nor does it provide exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_videoADestructiveIdempotentInspect
Permanently delete a video and all its indexed data (transcript, captions, embeddings, etc.). This cannot be undone.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ||
| rationale | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint: true, so the description adds value by detailing what gets destroyed (transcript, captions, embeddings). It also emphasizes permanence, which aligns with the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, concise and front-loaded. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple delete operation, the description is mostly complete, especially with annotations present. However, missing parameter descriptions slightly reduce completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has two parameters (video_id, rationale) with no descriptions (0% coverage). The description does not explain either parameter, even though rationale is optional and its purpose is unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'delete' and the resource 'video', and specifies that it also deletes all indexed data (transcript, captions, embeddings). This distinguishes from siblings like update_video or upload_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that this is for permanent deletion, stating 'This cannot be undone,' but it does not explicitly say when to use it vs alternatives or when not to use it. No alternative tools are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_captionsARead-onlyIdempotentInspect
Get AI-generated visual descriptions of what happens on screen. Use this to understand the visual content without watching — each caption describes a short segment with timestamps.
Use start/end to narrow results.
Requires the captions feature (qa_only or full pipeline).
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| video_id | Yes | ||
| rationale | No | ||
| max_results | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds that captions describe short segments with timestamps and require a specific feature capability, providing behavioral context beyond the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three well-structured sentences with no wasted words. Front-loaded with purpose, then usage guidance, then prerequisite.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given annotations (read-only, idempotent) and an output schema (not shown), the description provides sufficient context for usage and prerequisite. However, it omits explanation of the rationale parameter and return format details that output schema may cover.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description adds meaning for start and end parameters (narrowing results) but does not explain video_id (required), rationale, or max_results. Partial compensation, but incomplete.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves 'AI-generated visual descriptions' with timestamps, specifying the resource (video captions) and action (get). It distinguishes from sibling tools like get_transcript (audio) or get_scenes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains when to use ('to understand visual content without watching') and how to narrow results with start/end. It mentions a prerequisite (captions feature) but does not explicitly state when not to use or list alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_feature_catalogARead-onlyIdempotentInspect
List available video analysis features with their dependencies and descriptions. Use this to understand what features exist and what pipelines to use with index_video.
| Name | Required | Description | Default |
|---|---|---|---|
| rationale | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. Description adds context about dependencies and pipeline planning, which is helpful beyond annotation flags. 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences that front-load the purpose and usage guidance. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity, good annotations, and presence of an output schema, the description provides sufficient context. However, the lack of parameter documentation prevents a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Input schema has one parameter 'rationale' with no description (0% coverage). The description does not explain this parameter, so it adds no meaning beyond the schema. With low coverage, description should compensate but fails.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'List available video analysis features with their dependencies and descriptions.' This is a specific verb+resource pair that distinguishes it from sibling tools like index_video or search_videos.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Use this to understand what features exist and what pipelines to use with index_video.' Provides clear context for when to use this tool, though it does not explicitly state 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.
get_scenesARead-onlyIdempotentInspect
Get detected scene boundaries with start/end timestamps. Use this to understand the video's structure, then pass scene timestamps as start/end to:
ask_video for per-scene contextual analysis
segment_video to detect specific objects per scene (scenes typically fit in segment_video's 15s max range)
Requires transcript indexed with scene detection (on by default; skipped only if index_video was called with scene_detection=False).
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ||
| rationale | No | ||
| max_results | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark readOnlyHint and idempotentHint. Description adds context about requiring transcript indexed with scene detection, and explains how scenes fit into other tool workflows.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise three-sentence description. First sentence defines purpose, second sentence provides usage guidance, third sentence states prerequisite. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with output schema and annotations, the description covers purpose, usage integration, and prerequisites. Complete for an agent to decide when and how to invoke it.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema has 3 parameters (video_id, rationale, max_results) with 0% description coverage. Description does not explain any parameter meaning or usage, leaving the schema to speak for itself.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Clearly states the tool retrieves detected scene boundaries with timestamps. Explicitly distinguishes from siblings by showing how to use scenes with ask_video and segment_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use: understand video structure. Gives specific alternatives for downstream analysis (ask_video, segment_video). Mentions prerequisite about scene detection during indexing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transcriptARead-onlyIdempotentInspect
Get the spoken words in a video. Use this instead of ask_video when you need to read what was said — it returns the actual text, not a summary.
Use start/end to narrow results for long videos.
Requires the transcript feature to be indexed.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | No | ||
| format | No | text | |
| video_id | Yes | ||
| max_chars | No | ||
| rationale | No | ||
| max_results | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already convey readOnlyHint and idempotentHint. Description adds that it returns verbatim transcript and requires indexing, but does not explain behavior like rate limiting, error handling, or the meaning of max_results and max_chars.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short, focused sentences. The core purpose is front-loaded, followed by usage guidance and a prerequisite note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists, so return values are not needed. However, with 7 parameters and a moderate complexity, the description omits explanation of most parameters and behaviors, relying heavily on defaults and schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Only two parameters (start, end) are hinted at for narrowing results. With 0% schema description coverage, the description fails to explain format, max_chars, max_results, or rationale, leaving the agent without needed semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Get the spoken words in a video' and explicitly distinguishes from sibling tool ask_video by noting it returns actual text rather than a summary.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides clear context for when to use this tool instead of ask_video, and suggests using start/end parameters to narrow results. Mentions the indexing prerequisite, but does not enumerate other alternatives or explicitly state when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_videoARead-onlyIdempotentInspect
Get detailed information about a video including upload status, metadata (duration, resolution, fps), and per-feature indexing status. Use this to check if upload or indexing is complete. The 'url' field is a short-lived HTTPS presigned URL (expires within hours) — fetch immediately and do not store; call get_video again for a fresh URL when needed.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ||
| rationale | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint. Description adds critical behavioral detail: the 'url' field is a short-lived presigned URL expiring in hours, requiring immediate fetch and not storage. This goes beyond annotations and prevents misuse.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose and then usage note. Every sentence adds value. Could be slightly more concise by merging the URL guidance into one clause, but no excess verbiage.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given an output schema exists (not shown), description correctly focuses on input behavior. It covers all important aspects: what info is returned (status, metadata, indexing, URL) and URL handling. Lacks mention of error cases or rate limits, but overall sufficient for a read-only tool with annotations.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, yet the description does not explain the two parameters. It implicitly mentions video_id by context but gives no semantics for the 'rationale' parameter (which is optional with default null). The description fails to compensate for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Get detailed information about a video' and enumerates specific data: upload status, metadata (duration, resolution, fps), and per-feature indexing status. This distinguishes it from sibling tools like get_captions (captions only) or get_scenes (scene info).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly tells when to use: 'Use this to check if upload or indexing is complete.' Also provides operational guidance on the URL field (fetch immediately, don't store, call again). Missing explicit mention of when not to use or alternative tools, but context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
index_videoAIdempotentInspect
Index a video for search, QA, or full analysis. Processes the video through a pipeline of AI features. Typically takes 3-7 minutes; longer for long videos or the 'full' pipeline. Times out after 10 minutes by default.
Pipelines:
search_only: transcription + captions + embeddings (enables search_videos)
qa_only: transcription + captions (enables ask_video)
full: transcription + captions + embeddings (enables all tools)
Scene detection is enabled by default and produces scene boundaries for get_scenes. Pass scene_detection=False to skip it.
Prerequisites: if using video_id, the video must be in 'uploaded' status. Use get_video to check status before calling this tool.
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline | No | search_only | |
| video_id | Yes | ||
| rationale | No | ||
| scene_detection | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses typical processing time (3-7 minutes), timeout (10 minutes), and scene detection being enabled by default. Adds significant behavioral context beyond the idempotentHint annotation, such as pipeline durations and default settings.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Well-structured with a clear overview, timing, pipeline details, scene detection, and prerequisites. Each sentence is informative, though slightly longer than minimal; still earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers operational context (time, timeout, pipeline capabilities, prerequisite status) and references sibling tools (get_scenes, search_videos, ask_video). With output schema present, return values are not needed, making the description complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Despite 0% schema description coverage, the description explains three of four parameters: pipeline enumerations and their effects, video_id prerequisite, and scene_detection boolean usage. The rationale parameter is not explained, but overall the description adds meaningful semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool indexes a video for search, QA, or full analysis, and distinguishes itself from sibling tools by being the prerequisite for downstream tools like search_videos and ask_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly describes when to use each pipeline (e.g., search_only enables search_videos) and mentions prerequisites (video must be in 'uploaded' status) and how to check via get_video. Does not explicitly state when not to use, but provides sufficient context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_groupsARead-onlyIdempotentInspect
List all video groups. Use list_videos with a group_id to see videos in a specific group.
| Name | Required | Description | Default |
|---|---|---|---|
| rationale | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds the important detail that it lists ALL groups with no filtering, which is transparent about its scope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with the main action, with zero wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema exists but is not shown; the description is minimal. For a simple list tool, it covers the main purpose and provides an alternative, but omits explanation of the rationale parameter, which is a gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'rationale' has 0% schema coverage and is not explained in the description. The description suggests the tool takes no parameters affecting results, but leaves the purpose of rationale unclear.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it lists all video groups, and differentiates itself from list_videos by noting that list_videos with a group_id shows videos in a specific group.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to use this tool (to list all groups) and when to use an alternative (list_videos with group_id for videos within a group).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_videosARead-onlyIdempotentInspect
List all videos in your account, or filter to a specific group by passing group_id. Shows upload status and which features have been indexed for each video. Each video's 'url' is a short-lived HTTPS presigned URL (expires within hours) — fetch immediately and do not store; call list_videos or get_video again for a fresh URL when needed.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | No | ||
| rationale | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate read-only and idempotent behavior. The description adds important context about the short-lived presigned URL and the need to fetch immediately without storing, which goes beyond annotations. No mention of rate limits or pagination, but overall adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three concise sentences with the most critical information first: purpose, output details, and a crucial behavioral note about URL expiration. No redundant text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists (covering return structure), the description covers the input parameter group_id, the output contents (status, indexed features), and the URL behavior. It does not address pagination or sorting, but for a simple list tool this is sufficient.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0%, so the description must compensate. It explains the group_id parameter well but does not mention the rationale parameter at all. Thus, only partial value added beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies 'List all videos' and explains the filtering via group_id, making the purpose clear. It implicitly distinguishes from siblings like get_video (single video) and search_videos (search-based filtering).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It provides guidance on when to call list_videos again to get a fresh URL, and mentions get_video as an alternative. However, it does not explicitly exclude cases like needing complex filters (where search_videos would be better).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_videosARead-onlyIdempotentInspect
Find WHEN and WHERE something happens across your videos. Returns timestamped results ranked by relevance — use these timestamps as start/end in ask_video for focused analysis.
This is the recommended first step for most questions. Instead of asking ask_video about the entire video, search first to narrow down the relevant moments.
Each result's 'video_url' is a short-lived HTTPS presigned URL (expires within hours) — fetch immediately and do not store; call search_videos or get_video again for a fresh URL when needed.
Requires search_only or full pipeline.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | ||
| group_id | No | ||
| rationale | No | ||
| video_ids | No | ||
| max_results | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the description adds valuable context: video URLs are presigned and expire within hours, requiring immediate fetching. Also mentions permission requirements ('Requires search_only or full pipeline'). 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and well-structured, using three short paragraphs to cover purpose, usage context, and a critical caveat about URL expiry. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the core purpose, usage recommendation, and an important behavioral detail (URL expiry). The output schema presumably covers return values. Missing details like pagination or behavior of max_results are minor gaps given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description does not explain the parameters in detail. With 5 parameters and 0% schema description coverage, the description should compensate, but it only implies the query parameter. Other parameters (group_id, video_ids, rationale, max_results) are left unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states 'Find WHEN and WHERE something happens across your videos' and explains that it returns timestamped results ranked by relevance. It distinguishes itself from ask_video by indicating that the timestamps can be used as start/end in ask_video for focused analysis.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'This is the recommended first step for most questions' and advises to 'search first to narrow down the relevant moments' before using ask_video. Also provides guidance on the short-lived URLs: 'fetch immediately and do not store'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
segment_videoARead-onlyIdempotentInspect
Detect objects in a video segment using text prompts. Describe what to look for and get per-frame detections with bounding boxes and confidence scores.
Prompt tips:
Use broad, visual categories: 'animal', 'vehicle', 'person', 'text on screen'
Specific labels ('rabbit', 'Toyota') are less reliable — the detector matches visual patterns, not semantic concepts
Best for confirming whether a category of object appears in a time window, not for precise identification
How to pick a time range:
Use search_videos to find WHEN something appears, then pass those timestamps here
Use get_scenes to scan systematically — call segment_video once per scene (scenes typically fit in the 15s window)
Or pass any range you already know
Maximum range is 15 seconds per call; for longer spans, make multiple calls with consecutive windows.
Does NOT require any feature indexing — works on any uploaded video.
| Name | Required | Description | Default |
|---|---|---|---|
| end | No | ||
| start | Yes | ||
| prompts | Yes | ||
| video_id | Yes | ||
| rationale | No | ||
| threshold | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true. The description adds useful behavioral context: works on any uploaded video without feature indexing, maximum 15-second range, and per-frame detection output. It does not contradict annotations and enhances transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with clear sections, concise sentences, and no redundancy. Every sentence provides necessary information, making it efficient for the agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (6 parameters, object detection), the description covers purpose, usage, constraints, and output format (per-frame detections with bounding boxes and confidence scores). The presence of an output schema reduces the need to detail return values. It is nearly complete, lacking only parameter-specific details for threshold/rationale.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must compensate. It explains the 'prompts' parameter with tips and the 'start'/'end' temporal semantics. However, 'threshold' and 'rationale' parameters are not described beyond default values, leaving gaps. Overall, it adds moderate value.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool detects objects in a video segment using text prompts. It specifies the verb 'detect', resource 'objects in a video segment', and method 'text prompts'. It distinguishes from siblings like get_scenes and search_videos by explaining when to use each.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly explains when to use this tool (confirming object categories in a time window), provides prompt tips, and instructs how to pick a time range using search_videos or get_scenes. It also states not to use for precise identification and mentions the 15-second maximum range, guiding when to split calls.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarize_videoARead-onlyIdempotentInspect
Start here. Get a compact overview of a video: metadata, which features are indexed, a transcript preview, and scene count. Use this to decide which tools to call next — then use segment_video to detect specific objects in time ranges of interest.
| Name | Required | Description | Default |
|---|---|---|---|
| video_id | Yes | ||
| rationale | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description does not need to repeat safety. The description adds value by disclosing the type of information returned (metadata, features indexed, transcript preview, scene count), which is behavioral context beyond annotations. No contradictions present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences long, front-loaded with 'Start here.' Every sentence adds value: defining the output, suggesting next steps. No wasted words, and it is well-structured for quick comprehension.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given that an output schema exists (so return structure is defined elsewhere), the description sufficiently covers key outputs (metadata, features, transcript preview, scene count) and provides usage guidance. Annotations cover safety, making the description complete for an overview tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 parameter context. It implicitly references video_id ('of a video') but does not explain the rationale parameter. For two parameters with undocumented schema, the description provides partial coverage but lacks explicit parameter semantics for rationale.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Get a compact overview of a video: metadata, which features are indexed, a transcript preview, and scene count.' It uses a specific verb (Get) and resource (overview of a video), and distinguishes itself from siblings by positioning as the initial step and referencing segment_video.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly says 'Start here' and advises using the overview to decide which tools to call next, specifically mentioning segment_video. This provides clear context for when to use this tool. However, it does not explicitly state when not to use it or list alternative tools beyond segment_video.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_videoBIdempotentInspect
Update a video's display name, title, description, or move it to a different group. At least one field must be provided. To remove a video from its group, pass group_id as null.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| title | No | ||
| group_id | No | ||
| video_id | Yes | ||
| rationale | No | ||
| move_group | No | ||
| description | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the idempotentHint annotation by stating the required fields and how to remove a video from a group (pass group_id as null). However, it does not explain the 'rationale' or 'move_group' parameters, nor the behavior when fields are omitted (though idempotency implies unchanged).
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences: first states purpose and fields, second provides a crucial usage hint. No unnecessary words. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having an output schema and idempotent annotation, the description lacks coverage of two parameters (rationale, move_group) and does not explain the output or side effects beyond the mentioned behaviors. Incomplete for a 7-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema coverage, the description must explain all 7 parameters. It covers name, title, description, and group_id but omits 'rationale' and 'move_group'. This leaves significant gaps for an agent to correctly invoke the tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Update' and specifies the resources: display name, title, description, or group. It differentiates from sibling tools like upload_video (create) and delete_video (delete). However, it does not mention the 'move_group' boolean parameter, slightly reducing clarity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a constraint ('At least one field must be provided') but offers no guidance on when to use this tool versus alternatives like search_videos or get_video. No explicit when-not-to-use or comparison with siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_videoAInspect
Upload a video from a URL. Returns a video_id. Local file paths are not accepted; upload files outside the MCP server and pass a reachable video_url. The upload runs asynchronously — poll get_video until status is 'uploaded', then call index_video to enable search and analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| group_id | No | ||
| rationale | No | ||
| video_url | Yes | ||
| description | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that upload runs asynchronously and requires polling. It mentions that local file paths are not accepted. However, with no annotations, it doesn't mention error handling, idempotency, or potential failures. Still, it covers key 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, each carrying essential information: first sentence states purpose and return value; second sentence adds constraints and follow-up steps. No wasted words, front-loaded with the key action.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 params, no annotations, and an output schema, the description explains the async workflow and follow-up steps (poll, then index). It lacks parameter details and error handling, but the overall usage context is well-covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description should explain all parameters. It only mentions 'video_url' and emphasizes it must be a reachable URL. The other four parameters (name, group_id, rationale, description) are not described, leaving the agent to infer from property titles. This is insufficient.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Upload' and the resource 'video from a URL', and it returns a video_id. It distinguishes from siblings like index_video, segment_video, etc., by specifying the source (URL) and the asynchronous nature.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use: when you have a URL. It explicitly says when not to use: local file paths are not accepted. It provides a clear workflow: upload, then poll get_video until status uploaded, then call index_video. This gives the agent a complete usage pattern.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!