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/5 across 17 of 17 tools scored. Lowest: 3/5.
Each tool targets a distinct aspect of video management and analysis: upload, deletion, metadata, search, question-answering, object detection, captions, transcripts, scenes, summarization, and group organization. Even closely related tools like get_transcript and ask_video are clearly differentiated—one returns raw text, the other provides contextual summaries.
All tool names follow a consistent verb_noun pattern using snake_case (e.g., create_group, get_video, search_videos, index_video). The verbs are imperative and descriptive, making the action clear. There are no deviations or mixed conventions.
With 17 tools, the server covers the full video analysis lifecycle: ingestion, indexing, querying, and organization. Each tool serves a clear purpose without redundancy. The count is appropriate for the domain—not too few to limit functionality, nor too many to cause confusion.
The tool set provides comprehensive coverage: video CRUD (upload, update, delete, get, list), indexing with multiple pipeline options (search, QA, full), analysis features (ask, search, segment, captions, transcript, scenes, summarization), group management, and a catalog for feature discovery. There are no obvious gaps for the intended use case of video analysis.
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 (full pipeline).
| 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 doesn't need to repeat that. It adds value by mentioning prerequisites, but lacks disclosure of potential errors or limitations (e.g., behavior when no scenes detected). Still good.
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: first states purpose, second gives usage context, third states prerequisite. No wasted words, well-structured.
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?
With output schema present, description need not detail return values. It provides integration context and prerequisite. Could mention typical use of rationale parameter, but overall 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 has 0% description coverage, so the description should explain parameters. It only implies video_id usage but does not describe its format or the rationale parameter. This is a significant gap.
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 detected scene boundaries with start/end timestamps', specifying the action (get) and resource (scene boundaries). It distinguishes from sibling tools by explaining how the output integrates 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?
Explicitly tells when to use the tool ('to understand the video's structure') and how to use its output with other tools. Also states prerequisite: requires transcript indexed with scene detection. Excellent guidance.
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.
| 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?
Beyond the readOnlyHint and idempotentHint annotations, the description adds specifics about what information is returned (upload status, metadata, indexing status), which is valuable for the agent.
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 with no wasted words. Front-loaded with the purpose and followed by usage advice.
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?
With an output schema available, the description doesn't need to detail return format. It covers core purpose and usage context adequately. The only minor gap is not mentioning the required video_id parameter, but that is captured in the 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?
Schema description coverage is 0%, and the description does not mention any parameter (video_id or rationale). It provides no help understanding what the parameters mean or how to use them.
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 it gets detailed information about a video including upload status, metadata (duration, resolution, fps), and per-feature indexing status. Distinguishes from sibling tools like list_videos (listing) and delete_video (destructive).
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 recommends using it to check if upload or indexing is complete, providing clear context. However, does not offer when-not-to-use or alternative tools.
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. This may take 2-10 minutes depending on video length.
Pipelines:
search_only: transcription + captions + embeddings (enables search_videos)
qa_only: transcription + captions (enables ask_video)
full: all features including object detection (enables all tools)
Prerequisites: if using video_id, the video must be in 'uploaded' status. Use get_video to check status before calling this tool.
Accepts either video_id (for an already-uploaded video) or file_path (a local file to upload and index in one step). Provide exactly one.
| Name | Required | Description | Default |
|---|---|---|---|
| pipeline | No | search_only | |
| video_id | No | ||
| file_path | 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?
The description discloses the time estimate (2-10 minutes), the pipeline processing nature, and the prerequisite for video_id. The annotation idempotentHint=true is not contradicted; the description does not address idempotency, but this is a minor omission. Overall, it adds useful behavioral context beyond 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 concise (about 100 words) and well-structured with a main sentence, a time estimate, bullet points for pipelines, and a note on prerequisites. 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?
Given the tool's complexity (4 parameters, no required, output schema present, 15 siblings), the description covers the core functionality, input options, pipelines, and prerequisites. It does not explain the output, but an output schema exists. It could briefly mention idempotency or re-indexing behavior, but overall it is fairly 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 the pipeline enum values and their effects, and clarifies the mutual exclusivity of video_id and file_path. The rationale parameter is not explained, but the description adds significant meaning beyond the schema structure.
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 begins with 'Index a video for search, QA, or full analysis,' clearly stating the verb and resource. It further elaborates with three specific pipelines (search_only, qa_only, full) that directly relate to sibling tools like search_videos and ask_video, distinguishing the tool's role as a preprocessing step.
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 states prerequisites (video must be 'uploaded' status for video_id) and instructs to provide exactly one of video_id or file_path. It also implies when to use by linking pipelines to downstream tools (search_videos, ask_video). However, it does not explicitly state when not to use this tool (e.g., if already indexed).
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.
| 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 declare readOnlyHint and idempotentHint, covering the safety profile. The description adds value by specifying that the tool shows upload status and indexed features. However, it does not disclose other behavioral aspects like pagination or ordering, keeping the score from being a 5.
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, consisting of two clear sentences. The first sentence states the main purpose and filtering capability, and the second adds what information is returned. No redundancy or unnecessary detail.
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, presence of an output schema, and annotations covering safety, the description provides sufficient context: listing videos optionally filtered by group, and showing upload status and indexed features. It lacks mention of pagination or ordering, but for a typical list tool, this is acceptable.
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 explain the parameters. It explains the 'group_id' parameter for filtering but does not mention the 'rationale' parameter at all. This leaves one parameter undocumented, which is insufficient for an agent to use the tool effectively.
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 'List' and the resource 'videos', and mentions a filtering option by group_id. It also indicates what information is shown (upload status, indexed features). However, it does not explicitly differentiate from the sibling tool 'search_videos', which could provide similar functionality.
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 listing all videos or filtering by group, but does not provide explicit guidance on when to use this tool versus alternatives like 'search_videos'. There is no mention of exclusions or context-specific recommendations.
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.
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 indicate read-only and idempotent; description adds that results are timestamped and ranked by relevance, providing useful behavioral context beyond 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 sentences and a requirement line, front-loaded with key info; nearly concise but could be more structured.
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?
With an output schema present, description doesn't need to detail returns, but it mentions ranked timestamped results. Lacks explanation of optional parameters, making it adequate but not fully 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?
Schema coverage is 0%, but description only explains the query parameter by implication; optional params like group_id, rationale, video_ids, and max_results are not described, leaving the agent without guidance.
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 finds when and where something happens in videos and returns timestamped results, distinguishing it from ask_video as the recommended first step.
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 advises using this tool before ask_video to narrow down moments, and mentions required permissions (search_only or full pipeline).
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 indicate read-only and idempotent behavior. The description adds value by explaining that no feature indexing is required and that it works on any uploaded video. It does not contradict annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with a one-sentence summary, followed by prompt tips, time range guidance, and limitations. Every sentence adds value, and it is concise without unnecessary details.
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, 3 required) and the presence of an output schema, the description covers all essential aspects: purpose, prompt usage, time range selection, limitations, and references to complementary tools. No obvious gaps remain.
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 prompts (broad visual categories, tips), start/end (timestamps from search_videos, 15s limit), but does not explicitly describe threshold or rationale parameters. Overall, it provides enough context for key parameters.
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, returning per-frame detections with bounding boxes and confidence scores. This distinguishes it from sibling tools like search_videos (finds when something appears) and get_scenes (provides scene boundaries).
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 explicit guidance: use search_videos to find timestamps, use get_scenes for systematic scanning, and call segment_video once per scene. It also gives prompt tips (use broad categories, avoid specific labels) and explains the 15-second maximum range with advice for longer spans.
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!