Future Video Studio
Server Details
Create and manage cinematic AI video renders through the Future Video Studio Agent API.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
- Repository
- ariadne-coil/fvs-mcp
- GitHub Stars
- 0
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.2/5 across 8 of 8 tools scored. Lowest: 3.5/5.
Each tool has a clearly distinct purpose: cancel, submit, status (two variants), download, quote, example, and app launcher. No overlap or ambiguity.
All tools use a consistent verb_noun pattern with the 'fvs_' prefix, e.g., fvs_cancel_render, fvs_submit_render, fvs_get_render_status.
8 tools are appropriate for a video rendering service, covering essential operations without being overwhelming or too few.
The tool surface covers the full render lifecycle: submission, status polling (both regular and paid), cancellation, download, quote creation, and an example request. No obvious gaps.
Available Tools
8 toolsfvs_cancel_renderCancel renderADestructiveInspect
Cancel a Future Video Studio render job.
Provide either `project_id` or the full `cancel_url` returned by
fvs_submit_render.
| Name | Required | Description | Default |
|---|---|---|---|
| cancel_url | No | ||
| project_id | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint=true and readOnlyHint=false. The description adds no new behavioral context beyond confirming cancellation, meeting baseline expectations.
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 short, focused sentences with no redundant information. Front-loaded with purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers essential usage and parameter selection. With an output schema present and simple parameters, lacks only minor behavioral details like potential side effects.
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 that `cancel_url` comes from fvs_submit_render and that one of the two parameters must be provided, adding meaningful 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 'Cancel a Future Video Studio render job' with a specific verb and resource. It distinguishes from sibling tools like fvs_submit_render and fvs_get_render_status.
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 provide either `project_id` or `cancel_url`, referencing where to get the URL (fvs_submit_render). No explicit when-not-to-use, but the context of cancellation is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fvs_create_paid_render_quoteCreate paid render quoteAInspect
Create a no-account Link payment quote for an FVS render.
The backend returns HTTP 402 payment details as data: `payment_url`,
`status_url`, `claim_token`, `amount_cents`, `currency`, and a raw
`www_authenticate` challenge. Pay `payment_url` with Link's MPP flow, then
poll with fvs_get_paid_render_status. Local file uploads are not available
in paid quote mode; use public HTTPS `upload_urls` when assets are needed.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Required render request object used for the paid quote. Include name. project_mode must be one of scene, music, or custom. Use assets[].purpose for asset intent. Usually include screenplay, instructions, shot_count, duration, and resolution. | |
| upload_urls | No | Optional public HTTPS reference asset URLs. Each object can include url and filename; filename should match request.assets[].filename. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate a mutation (readOnlyHint false) and not destructive. The description adds that the backend returns HTTP 402 with payment details, explaining the payment requirement and response structure. It also mentions the limitation on local uploads. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise with two paragraphs. The first sentence immediately states the purpose. Every sentence adds value without repetition. Front-loaded and efficient.
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 nested request object and output schema (implied), the description covers the essential workflow: creating a quote, payment steps, polling, and asset upload limitation. It doesn't repeat schema details but provides sufficient context for an agent to use 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?
Schema coverage is 100%, so parameter descriptions already exist. However, the description adds valuable guidance: 'Include name. project_mode must be one of scene, music, or custom. Use assets[].purpose for asset intent. Usually include screenplay, instructions, shot_count, duration, and resolution.' This helps the agent fill the parameters 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's purpose: 'Create a no-account Link payment quote for an FVS render.' It specifies the payment flow and distinguishes from sibling tools like fvs_get_paid_render_status by mentioning polling that tool afterward.
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: pay using Link's MPP flow, then poll with fvs_get_paid_render_status. It also states that local file uploads are not available and to use public HTTPS upload_urls instead, giving clear alternatives and context when to use this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fvs_download_final_videoDownload final videoADestructiveInspect
Download a completed Future Video Studio final render URL to a local file.
Use this only after fvs_get_render_status or fvs_get_paid_render_status returns a final_video_url for a completed render. The tool performs an unauthenticated HTTPS GET to that signed URL and writes the response bytes to output_path on the MCP server's local filesystem. It does not call the FVS Agent API, spend wallet credits, require FVS_AGENT_API_KEY, cancel jobs, or modify remote render state.
Side effects and constraints: output_path is a local filesystem path for the MCP server process, parent directories are created, existing files are not replaced unless overwrite is true, and large videos may take minutes to download. The request timeout is 600 seconds. Use a fresh status check to refresh expired signed URLs, and do not pass arbitrary or untrusted URLs.
| Name | Required | Description | Default |
|---|---|---|---|
| overwrite | No | Set true only when replacing an existing output_path is intended. Defaults to false to avoid accidental local file overwrites. | |
| output_path | Yes | Local filesystem path where the MCP server should write the video, for example C:/Users/me/Videos/fvs-result.mp4 or /tmp/fvs-result.mp4. Parent directories are created. Existing files are refused unless overwrite is true. | |
| final_video_url | Yes | HTTPS signed final_video_url returned by a completed fvs_get_render_status or fvs_get_paid_render_status response. Use a fresh status check if the signed URL has expired. |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only indicate destructiveHint=true. The description adds extensive detail: unauthenticated HTTPS GET, writes to local filesystem, does not call FVS API, no wallet credits, no API key required, no remote state modification. It also discloses side effects like parent directory creation, overwrite behavior, download time, and 600s timeout. No contradiction with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Seven sentences, each purposeful. Front-loaded with core action and usage condition, then side effects and constraints. No redundant information. Concise yet comprehensive.
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 destructiveHint annotation and the complexity of file download with side effects, the description covers all necessary aspects: purpose, prerequisites, constraints, behavioral properties, parameter guidance, and warnings. Nothing missing.
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 100% with detailed parameter descriptions. The tool description adds context about URL expiration and large video download time, but does not significantly enhance semantic understanding beyond the schema. Still, it provides useful contextual notes.
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 downloads a completed render URL to a local file, with specific verb 'download' and resource 'final video'. It distinguishes from sibling tools like fvs_cancel_render, fvs_submit_render, etc., by specifying it's only for use after a status check returns a final_video_url.
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 'Use this only after fvs_get_render_status or fvs_get_paid_render_status returns a final_video_url for a completed render.' Also warns against passing arbitrary/untrusted URLs and advises a fresh status check for expired signed URLs.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fvs_example_render_requestExample render requestARead-onlyIdempotentInspect
Return a minimal scene render request agents can adapt.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, destructiveHint, and idempotentHint. The description adds valuable context that the result is a minimal, adaptable scene render request, not a submission. No contradictions with annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise 8-word sentence that immediately conveys the core purpose. Every word is essential, and it is front-loaded with the key action and result.
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 no parameters, possesses a rich set of annotations, and has an output schema (which precludes needing to explain return values), the description fully covers what an agent needs: that this is a read-only template for building render requests.
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 tool has zero parameters, so per guidelines the baseline is 4. The description does not need to add parameter information since there are none.
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 returns a minimal scene render request that agents can adapt. It uses specific verb 'Return' and resource 'minimal scene render request', distinguishing it from sibling operations like submitting, canceling, or downloading renders.
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 this tool is for obtaining a template before creating a render request, but it does not explicitly state when to use it over alternatives like 'fvs_submit_render' or 'fvs_create_paid_render_quote'. No explicit when-not or alternative references are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fvs_get_paid_render_statusGet paid render statusARead-onlyIdempotentInspect
Check a no-account paid render created with fvs_create_paid_render_quote.
Provide the full `status_url` or pass both `quote_id` and `claim_token`.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | No | ||
| status_url | No | ||
| claim_token | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds behavioral context by specifying it checks status (non-mutating) and clarifies the input constraints. 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 sentences with no redundancy. First sentence states purpose and context; second provides clear usage instructions. Every word 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?
With an output schema available (not shown), the description adequately covers input requirements and context. Could optionally mention that status_url encapsulates the quote/claim info, but current completeness is sufficient for a status-check 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 coverage is 0%, so the description carries full burden. It explains that status_url alone suffices or that both quote_id and claim_token are needed for alternative input. This adds significant meaning beyond the bare schema, though claim_token's origin is implied rather than explicit.
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 the specific verb 'Check' and resource 'no-account paid render status', clearly distinguishing it from siblings like fvs_get_render_status (generic) and fvs_cancel_render. It also links to fvs_create_paid_render_quote, establishing context.
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 the two ways to invoke the tool: using status_url alone or combining quote_id and claim_token. While it doesn't specify when not to use the tool, the guidance is clear and actionable, and links to the creation tool for context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fvs_get_render_statusGet render statusARead-onlyIdempotentInspect
Check a Future Video Studio render job.
Provide either `project_id` or the full `status_url` returned by
fvs_submit_render.
| Name | Required | Description | Default |
|---|---|---|---|
| project_id | No | ||
| status_url | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destactiveHint=false, idempotentHint=true. The description adds minimal extra behavior (e.g., it doesn't mention what happens if both parameters are provided or if the job doesn't exist). With annotations covering safety, the description adds little 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?
The description is exactly two sentences, no redundant words. It front-loads the purpose and gives parameter guidance in the second sentence. Every part 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?
Given the tool's simplicity (2 optional params, read-only, idempotent) and the presence of an output schema, the description covers the essential usage. It could hint at the output format but the schema already handles that.
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 explains that project_id and status_url are alternative ways to identify the same render job, which provides meaning beyond the schema's property titles alone. This is helpful for an agent to choose which parameter to use.
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 'check' and resource 'render job', making the tool's purpose obvious. It does not explicitly differentiate from sibling tools like fvs_get_paid_render_status, but given the different purpose (free vs paid), it's still clear.
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 guidance on how to use parameters (either project_id or status_url), which indicates when each parameter is appropriate. However, it does not contrast with siblings or specify when to avoid this tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fvs_open_chatgpt_appOpen Future Video StudioARead-onlyIdempotentInspect
Open the Future Video Studio ChatGPT app widget without creating a render. Use this when the user wants the FVS app panel, wants to paste a status URL, or wants to prepare a render interactively before spending credits.
| Name | Required | Description | Default |
|---|---|---|---|
| quote_id | No | ||
| project_id | No | ||
| status_url | No | ||
| claim_token | No | ||
| final_video_url | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 the action is 'without creating a render', consistent with read-only behavior. No contradictions, and the description provides context beyond annotations, such as the interactive preparation use case.
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 extremely concise: two sentences that front-load the core function and add use cases. No filler words 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?
Despite having 5 optional parameters and an output schema, the description covers only high-level use cases and omits parameter behavior, response format, or prerequisites. The agent lacks sufficient detail to use the tool correctly in varied scenarios.
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 does not explain any of the 5 parameters (quote_id, project_id, status_url, claim_token, final_video_url). It vaguely hints at 'paste a status URL' but does not link to the parameter, leaving the agent without guidance on 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 uses specific verbs ('Open') and a clear resource ('Future Video Studio ChatGPT app widget') and distinguishes from sibling render-creation tools by explicitly stating 'without creating a render'. It leaves no ambiguity about the tool's action.
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 use cases (want app panel, paste status URL, prepare render interactively) and implies when not to use (when aiming to create a render). However, it does not explicitly name sibling alternatives like fvs_submit_render, slightly reducing directiveness.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
fvs_submit_renderSubmit renderADestructiveInspect
Submit a Future Video Studio render job through the FVS Agent API.
Pass the render payload in the required `request` object. For reference
assets, pass public HTTPS URLs in `upload_urls`; every
`request.assets[].filename` must match one uploaded URL basename or explicit
upload URL filename. Credentials come from the connector header,
marketplace account mapping, or FVS_AGENT_API_KEY in the MCP server
environment.
| Name | Required | Description | Default |
|---|---|---|---|
| request | Yes | Required render request object. Include name. project_mode must be one of scene, music, or custom. Use assets[].purpose for asset intent. Usually include screenplay, instructions, shot_count, duration, and resolution. | |
| upload_urls | No | Optional public HTTPS reference asset URLs. Each object can include url and filename; filename should match request.assets[].filename. | |
| poll_until_complete | No |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate destructiveHint: true and readOnlyHint: false. The description adds credential sourcing and asset matching details, but does not discuss side effects like cost, idempotency, or job lifecycle beyond submission.
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, each informative and front-loaded. No fluff. Efficiently covers purpose, key parameters, and credentials.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Covers basic usage and credential sources, but misses important context like payment prerequisites, cost implications, and the purpose of poll_until_complete. Output schema may compensate for return values, but some 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 description coverage is 67%; the tool description adds value by explaining the matching constraint between request.assets[].filename and upload_urls. However, poll_until_complete is not mentioned in the description, leaving a 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 'Submit a Future Video Studio render job through the FVS Agent API,' which provides a specific verb (submit) and resource (render job). This distinguishes it from sibling tools like cancel, quote, or status.
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 how to use the tool with request and upload_urls, but does not explicitly state when to use this tool versus alternatives (e.g., fvs_create_paid_render_quote for payment handling). It lacks '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.
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!