Understand your videos with Reka AI — search, ask questions, and extract insights.
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.
Average 4.2/5 across 17 of 17 tools scored. Lowest: 3.4/5.
Each tool targets a distinct purpose: video lifecycle management (upload, get, list, update, delete), group management, content retrieval (transcript, captions, scenes), search, QA, object detection, and metadata exploration. The boundaries are clear, and cross-references in descriptions guide when to use each tool.
All tool names follow a consistent verb_noun snake_case pattern (e.g., upload_video, get_transcript, search_videos). The verbs are imperative and descriptive, making the naming uniform and predictable across the entire set.
With 17 tools, the count is slightly above the ideal 3-15 range, but the breadth of features (video upload, indexing, multiple analysis modes, grouping) justifies the number. The tools are well-scoped with no redundancy, though a leaner design might consolidate some retrieval functions.
The tool surface covers the full video lifecycle: upload, index, retrieve, search, analyze, update, delete, and group management. Feature catalog and status checking fill any informational gaps, and the workflow guidance (search to find timestamps, then ask or segment) closes potential dead ends.
ask_videoAAsk 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only state readOnlyHint, so the description adds value by disclosing that it's 'Most effective on focused time ranges', requires 'qa_only or full pipeline', and supports follow-up context via conversation_id. However, it does not elaborate on the meaning of 'qa_only or full pipeline' or potential failure modes, which would be more transparent.
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-organized with a clear opening purpose, a bulleted workflow, and separate notes for single vs cross-video and follow-ups. Every sentence adds value, and the structure makes it easy to scan.
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 (7 parameters, two modes, follow-up behavior), the description covers most aspects: when to use, required pipeline, and parameter relationships. However, it omits the purpose of 'rationale' and doesn't clarify the 'qa_only or full pipeline' requirement, so it's 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?
With 0% schema description coverage, the description compensates by explaining start/end, video_id, videos, and conversation_id. However, the 'rationale' parameter is not mentioned at all, leaving its purpose unclear. Question is obvious but not explicitly described.
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 function: 'Ask a question about one or more videos with visual analysis.' It also distinguishes this tool from siblings by mentioning focused time ranges and cross-video questions, which is unique among the listed tools.
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 instructs to read a guide before calling, and provides a recommended workflow with alternatives: use search_videos, segment_video, and get_transcript first, then pass timestamps here. Also explains when to use video_id vs videos and how to handle follow-up questions with conversation_id.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
create_groupBInspectCreate 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are empty, so the description carries the full burden. It discloses a key behavioral trait: 'Returns the new group's ID and name.' However, it does not mention permissions, idempotency, or potential side effects beyond creation, which are relevant for a mutate operation.
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 three sentences long and front-loaded with the primary action. Every sentence adds context: what it does, what groups are, and what is returned. No extraneous information is present.
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 tool is simple, and the description covers the core purpose and return value. However, it omits parameter explanations and usage guidance. Since an output schema exists, return details are not a gap, but the overall description leaves room for improvement in parameter semantics.
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 explain the parameters 'name' or 'rationale'. It only mentions 'name' indirectly in the return value. The description provides no additional meaning beyond the schema's minimal titles, so it fails to compensate for the lack of parameter documentation.
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 ('Create a new video group'), identifies the resource ('video group'), and explains its purpose ('Groups organize videos into collections'). This distinguishes it from sibling tools such as list_groups and delete_group, which have different operations.
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 when to use the tool (to create a group) but provides no explicit guidance on alternatives or exclusions. Sibling tools like delete_group and list_groups exist, but the description does not reference them or explain when to prefer other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_groupADelete 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds valuable behavioral context beyond the destructiveHint and idempotentHint annotations by explicitly stating that videos in the group are not deleted, only removed from the group. This clarifies a potentially surprising side effect 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 a single, concise sentence that is front-loaded with the primary action. Every word serves a purpose, with no redundant or extraneous content.
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 deletion tool, the description covers the key nuance (videos not being deleted) adequately. With annotations and an output schema available, the missing details like return format or permissions are not critical, so the description is sufficiently 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?
The schema has 0% description coverage for parameters, and the description provides no explanation of group_id or rationale. It does not compensate for the lack of schema documentation, leaving parameter semantics entirely to the reader's inference.
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 deletes a video group, using a specific verb and resource. It also distinguishes this from deleting the videos themselves, which sets it apart from the sibling tool '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 by clarifying that videos are not deleted, suggesting that delete_video should be used for video deletion. However, it does not explicitly name alternatives or state when to use this tool over others, so guidance is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
delete_videoAPermanently 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the destructiveHint and idempotentHint annotations, the description specifies that deletion covers transcript, captions, embeddings, and other indexed data, and emphasizes irreversibility. This adds valuable context about the tool's effect scope and permanence.
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, directly to the point, with no redundancy. The key action and consequence are stated upfront.
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 delete operation, the description covers the essential behavior and scope. It does not explain the optional rationale parameter or any prerequisites, but the presence of an output schema mitigates the need to describe return values. Minor gaps remain 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?
The description does not mention the parameters (video_id, rationale) at all. While video_id is self-explanatory from its name, the rationale parameter's purpose is left entirely unexplained. Given 0% schema coverage, 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?
The description clearly states the tool's function: permanently deleting a video and its associated indexed data. It distinguishes from sibling tools like delete_group or update_video by specifying the resource (video) and the scope (all indexed data).
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 the tool is for video deletion but does not explicitly explain when to use it versus alternatives. There are no alternative delete tools for videos listed, so the intent is clear, but it lacks explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_captionsAGet 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the description adds beyond them by noting the captions feature requirement (qa_only or full pipeline) and the timestamped segment structure. This provides valuable operational context not present in 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 three sentences, front-loaded with the primary purpose, and every sentence adds value—purpose, use case, narrowing, and feature requirement. 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 that an output schema exists, the description does not need to detail return values. It covers the core function, the feature prerequisite, and how to filter results. However, it omits guidance on optional parameters like rationale and max_results, which would make it more complete for a 5.
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 elaborates on start/end ('narrow results'). Parameters like rationale and max_results are left unexplained, leaving a significant gap for an agent to understand their purpose.
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 of on-screen activity, distinguishing it from siblings like get_transcript (audio) and get_scenes (scene segmentation). It also specifies the output structure as short segments with timestamps.
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 clear context for when to use the tool ('understand the visual content without watching') and how to narrow results with start/end. It does not explicitly mention alternatives or exclusions, but the use case is well-defined.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_feature_catalogAList 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, covering safety. The description adds no extra behavioral context (e.g., permissions, rate limits, return format details), but this is acceptable since the output schema exists and annotations provide the safety profile.
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 fluff. The primary verb and resource are front-loaded in the first sentence, and the usage guidance is in the second. Every word 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?
For a read-only catalog tool with an output schema and annotations, the description is largely complete. It explains the tool's purpose and how to use it in the pipeline. The only gap is the rationale parameter, but that is minor compared to the overall context provided.
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% for the single 'rationale' parameter, and the description does not mention it at all. The name is somewhat suggestive, but the description fails to compensate for the lack of schema documentation, leaving the parameter's 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?
Description uses a specific verb "List" with a clear resource "available video analysis features" and specifies scope (dependencies and descriptions). It distinguishes itself from siblings like index_video and segment_video by indicating it's a catalog/planning tool, not a video operation.
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 clearly states when to use it: 'Use this to understand what features exist and what pipelines to use with index_video.' This gives actionable guidance, though it does not name alternative tools or 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_scenesAGet 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 value by disclosing the dependency on transcript indexing with scene detection enabled. It explains how this can be disabled (index_video with scene_detection=False), giving useful 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?
The description is three sentences, front-loaded with the core purpose, then using a concise bullet list for usage context. No fluff, every sentence 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?
For a read-only getter with an output schema, the description covers the tool's purpose, usage context, and prerequisite. It does not detail the output shape or max_results behavior, but the output schema appears to handle return semantics, and the prerequisite disclosure is a valuable completeness addition.
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 explain any of the three parameters (video_id, rationale, max_results). Although parameter names suggest meaning, the description fails to compensate for the missing schema descriptions, only indirectly referencing start/end timestamps as output, not input 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's function: 'Get detected scene boundaries with start/end timestamps.' This is a specific verb+resource that is distinct from sibling tools, and the description further differentiates by explaining how the output feeds into 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?
The description provides explicit when-to-use guidance: 'Use this to understand the video's structure' and then instructs to pass timestamps to ask_video or segment_video. It also names alternatives and even mentions a prerequisite involving index_video and the scene_detection setting.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_transcriptAGet 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safety profile is known. The description adds valuable behavioral context: it returns raw text rather than a summary, requires the transcript feature to be indexed, and supports start/end narrowing. This enriches understanding beyond the annotations without contradicting them.
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 three sentences, each earning its place: purpose, differentiation, and a usage tip. It is front-loaded with the core function and has zero fluff.
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 tool has seven parameters and an output schema. The description covers purpose, alternative, prerequisite, and one usage tip, but does not explain the meaning/impact of format, max_chars, max_results, or rationale. Given the complexity, more parameter-level context is needed for full invocation confidence.
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 compensate. It mentions start/end for narrowing but leaves other parameters (format, max_chars, rationale, max_results) unexplained. With seven parameters, 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?
The description opens with a specific verb and resource: 'Get the spoken words in a video.' It immediately distinguishes itself from the sibling tool ask_video by stating it returns the actual text, not a summary. This makes the purpose unmistakable.
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 this tool over ask_video ('Use this instead of ask_video when you need to read what was said'), provides a usage tip for long videos ('Use start/end to narrow results'), and states a prerequisite ('Requires the transcript feature to be indexed'). This is clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_videoAGet 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint and idempotentHint annotations already declaring safety, the description adds meaningful behavior context about the 'url' field being a short-lived presigned URL, including expiration and the need to re-fetch. This exceeds annotation coverage without contradiction.
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 every sentence carries essential information. No filler or 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?
With an output schema present, the description needn't detail return values. It effectively covers the tool's purpose, when to use it, and a critical operational warning about URL expiry. Complete for a read-only, idempotent tool with simple parameters.
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 compensate. It mentions 'video' but not explicitly 'video_id', and the 'rationale' parameter is never explained. The description adds negligible semantics beyond the parameter names themselves.
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 states a specific verb and resource: 'Get detailed information about a video' with explicit content types (upload status, metadata, per-feature indexing status). This clearly distinguishes it from sibling tools like get_scenes or get_transcript, which target specific content.
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 states when to use the tool: 'Use this to check if upload or indexing is complete.' Provides clear context for selection, though it does not explicitly name alternatives or when-not-to-use scenarios, which would warrant a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
index_videoAIndex 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds substantial behavioral context beyond annotations: processing times (3-7 minutes), timeout (10 minutes), default scene detection, and the prerequisite that the video must be in 'uploaded' status. It does not contradict the idempotentHint annotation and enriches the operability knowledge.
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 front-loaded with the primary purpose, followed by essential timing, pipeline breakdown, scene detection note, and prerequisite. It uses clear headers for pipelines and prerequisites, and every sentence adds operational value without fluff.
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 (multiple pipelines, 4 parameters, defaults, and an output schema), the description covers prerequisites, timeout, pipeline effects, and scene detection. The existence of an output schema means return values need not be described. The description is complete enough for an agent to correctly invoke and handle the 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%, but the description fully compensates by explaining the semantics of the pipeline parameter (search_only/qa_only/full), scene_detection (default true, skip with false), and the important 'uploaded' status requirement for video_id. Only the rationale parameter is left unexplained, but that is ancillary.
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 ('Index a video') and the resource, with specific purpose ('for search, QA, or full analysis'). It distinguishes from siblings like upload_video, segment_video, and search_videos by clarifying that this tool builds the index that enables those other tools.
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 specific pipeline types and includes a prerequisite instruction to check video status via get_video before calling. However, it doesn't explicitly state when NOT to use this tool (e.g., if only captions are needed) or mention alternative tools beyond the pipeline a enable relation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_groupsAList all video groups. Use list_videos with a group_id to see videos in a specific group.
| Name | Required | Description | Default |
|---|---|---|---|
| rationale | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and idempotentHint=true, so the safety profile is covered. The description adds the 'all' scope (no filtering), which is useful, but it does not disclose return format, pagination, or any other behavioral traits. This is consistent with annotations, adding modest value.
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 exactly two sentences, front-loaded with the core purpose ('List all video groups') followed by a relevant pointer to a sibling tool. Every word earns its place, with zero unnecessary content.
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 tool is simple and the output schema exists, so return values are likely documented. The description covers the primary use case and directs to list_videos for related needs. However, it does not mention the rationale parameter or any potential pagination/order behavior, leaving a minor gap for a complete picture.
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 schema has one optional parameter (rationale) with 0% description coverage. The tool description does not mention or explain this parameter at all, so it fails to compensate for the low schema coverage. While rationale is optional and may be self-explanatory, the description adds no meaning 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 clearly states 'List all video groups,' which is a specific verb+resource combination. It also distinguishes from list_videos by clarifying that list_videos is for viewing videos within a group, preventing role confusion.
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 names list_videos as an alternative for a related task ('Use list_videos with a group_id to see videos in a specific group'), providing clear context. However, it does not explicitly state when not to use this tool or mention other alternatives like create_group, so a full 'when/when-not' list is missing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_videosAList 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint and idempotentHint, so the safe nature is covered. The description adds significant behavioral context beyond annotations, notably that URLs are short-lived presigned URLs expiring within hours, advising immediate fetching and not storing. It also mentions output content (upload status, indexed features), which is useful 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?
The description is concise and front-loaded, immediately stating the main action. It uses three sentences that each carry substantive information: purpose, output details, and the critical URL-expiry caveat. 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 and the presence of an output schema, the description is nearly complete. It covers the primary use, optional filter, and a key behavioral warning. It does not mention pagination, ordering, or limits, but for a basic list tool this is acceptable. The output schema likely fills in return-structure details.
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 0% description coverage, so the tool description must compensate. It does explain group_id ('filter to a specific group by passing group_id'), adding meaning. However, the 'rationale' parameter is entirely unexplained in both the schema and the description, leaving a gap for one of the two 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's function: 'List all videos in your account, or filter to a specific group by passing group_id.' This is a specific verb+resource ('list videos') with scope options. It distinguishes itself from sibling tools like get_video (single video) and search_videos (search) by focusing on listing.
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 clear context on when to use the tool: to list all videos or filter by group. It also includes a practical guideline to fetch presigned URLs immediately and not store them. However, it does not explicitly mention alternatives or exclusions (e.g., 'use search_videos for full-text search'), so it lacks a strong when-not-to-use statement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_videosAFind 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnly and idempotent annotations, the description discloses the time-limited presigned URL behavior, instructing agents to fetch immediately and not store, and to call search_videos or get_video again for fresh URLs. This adds valuable operational 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 well-structured with a clear front-loaded purpose statement, a usage recommendation, a critical URL expiry warning, and a permissions note. Every sentence adds necessary information without redundancy, making it both concise and effective.
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, the description doesn't need to detail return values, but it still explains the timestamped result nature and URL expiry. It covers the workflow with ask_video and permission requirements, making it quite complete. Minor gap: no explanation of rationale or grouping options, but these are not essential for basic usage.
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 provides no explanation of any input parameters (query, group_id, video_ids, max_results, rationale). It mentions searching across videos but never details how to scope or filter, leaving agents without the necessary parameter semantics to invoke the tool correctly.
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 across videos, with timestamped ranked results. It explicitly differentiates itself from ask_video by recommending search first and using timestamps as start/end in ask_video, making its unique purpose unmistakable.
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 this is the recommended first step for most questions and advises against asking ask_video about the entire video, instead searching first to narrow down moments. It also notes the required permission (search_only or full pipeline), providing clear context for when to use this tool versus siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
segment_videoADetect 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it notes that no feature indexing is required, imposes a 15-second maximum range per call, and explains that specific labels are less reliable than visual categories. These nuances help an agent understand the tool's operational constraints and failure modes.
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 and bullet points, front-loading the core purpose. It is longer than minimal, but every section adds valuable guidance (prompt tips, time-range selection, limitations). It could be slightly more concise, but the structure aids readability.
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 is highly complete given the tool's complexity. It covers the main purpose, usage patterns, time-range selection, constraints, and alternatives. An output schema exists, so return values are not the description's responsibility. The combination of annotations and description gives an agent all necessary context to invoke the tool 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?
Despite 0% schema description coverage, the description compensates well for key parameters: it explains prompts semantics (broad visual categories, specific labels less reliable), defines the time range behavior for start/end (max 15s, use search_videos to find timestamps), and implicitly guides threshold usage by discussing confidence. However, it omits direct explanation of 'threshold' and 'rationale', so it doesn't fully cover all 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's purpose: 'Detect objects in a video segment using text prompts' and specifies the output ('per-frame detections with bounding boxes and confidence scores'). It also distinguishes itself from siblings by explaining its role in relation to search_videos and get_scenes, making it a distinct video analysis tool.
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 on when to use this tool ('Best for confirming whether a category of object appears in a time window') and how to pick time ranges, referencing alternatives like search_videos and get_scenes. It also gives practical advice on multiple calls for longer spans, which is clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
summarize_videoAStart 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 behavioral context by specifying the output content (metadata, indexed features, transcript preview, scene count) and notes that it is a 'compact' overview (implying truncated/preview data). This provides value beyond the annotations, though it doesn't address edge cases or performance, which is acceptable for a simple read-only tool.
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 three sentences, front-loaded with 'Start here', and each sentence earns its place: it states the purpose, lists what's included, and provides a clear next-step pointer. There is no redundancy or filler, making it highly concise and 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?
Given the tool is a lightweight read-only summary and has an output schema (which covers return values), the description is largely complete. It covers the core functionality and workflow context, and even mentions a sibling tool. The only gap is the lack of explanation for the rationale parameter, which is a minor omission but does not detract significantly from the overall completeness for a first-step 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?
The schema description coverage is 0%, so the description must compensate, but it only mentions 'a video' implicitly and says nothing about the 'rationale' parameter. While video_id is self-explanatory, the rationale parameter is left unexplained, leaving the agent unsure of its purpose or expected format. This is a notable gap for a tool with only two 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's purpose: 'Get a compact overview of a video' and lists the specific components (metadata, indexed features, transcript preview, scene count). It positions the tool as the entry point ('Start here') and explicitly distinguishes it from segment_video, which handles specific object detection. This makes the purpose unambiguous and differentiates it from sibling tools.
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 usage guidance: 'Start here' tells when to use this tool, 'Use this to decide which tools to call next' explains its role in the workflow, and it names a specific alternative (segment_video) for a different use case. This satisfies the requirement for when and alternatives, making it clear when to invoke this tool versus others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
update_videoAUpdate 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the idempotentHint annotation, the description discloses important behaviors: the requirement of at least one field and the null-group_id removal behavior. It does not contradict the annotation and adds useful constraints, though it omits details like whether fields are replaced or merged.
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 with no filler. It front-loads the main action, then states constraints and special cases. Every sentence adds value, and it is appropriately sized for the tool's 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?
Given the 7-parameter schema with an output schema available, the description covers the core purpose and key parameter behavior. It misses clarifications for rationale and move_group, but the essential usage is clear. Overall, it is reasonably complete for an update tool of this complexity.
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 names name, title, description, and group_id concepts, but does not explain the rationale or move_group parameters, nor the relationship between group_id and move_group. This leaves some parameters ambiguous, so compensation is only partial.
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 ('Update'), the resource ('a video'), and the specific fields affected ('display name, title, description') plus the ability to move it to a different group. This differentiates it from sibling tools like delete_video or upload_video by specifying exactly what is being updated.
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 practical usage guidance by specifying that at least one field must be provided and explaining how to remove a video from a group by passing group_id as null. However, it does not explicitly contrast with alternative tools or mention when to prefer this over others, though the context makes it implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
upload_videoAInspectUpload 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 |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With empty annotations, the description fully discloses the key behavioral traits: asynchronous upload, URL reachability requirement, and the need to poll get_video followed by index_video. This is rich contextual information that goes far beyond the schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences with no filler: what the tool does, the constraint on file paths/URLs, and the asynchronous workflow. Every sentence contributes essential information, and the main action is front-loaded.
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 full lifecycle for an upload operation, including asynchronous completion and dependencies on get_video and index_video. The output schema covers return values. However, the optional parameters are not elaborated, leaving a minor gap for a tool with five parameters.
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 only explains video_url. Optional parameters (name, group_id, rationale, description) are left entirely to their schema titles, which does not compensate for the coverage gap. The agent is left guessing about the meaning of these fields.
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 uses a specific verb ('Upload') and resource ('a video from a URL'), clearly distinguishing it from siblings like get_video and index_video. It also states the return value (video_id), making the tool's purpose unambiguous.
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 that local file paths are not accepted and requires a reachable video_url. It also provides a clear post-upload workflow: poll get_video until status is 'uploaded', then call index_video. This gives both exclusions and step-by-step guidance.
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.
No comments yet. Be the first to start the discussion!
