rnv-color-mcp
Server Details
A complete color workflow over MCP: mix, convert, harmonize, measure, and remember palettes.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Tool Definition Quality
Average 4.2/5 across 9 of 9 tools scored.
The color tools are clearly distinct in purpose, but the inclusion of transform_text (text case transformation) is unrelated to color and may confuse agents about the server's domain.
All tools follow a consistent verb_noun pattern (e.g., color_difference, save_palette, transform_text), making them predictable and easy to navigate.
9 tools is a reasonable number for a color server, covering key operations. However, transform_text is out of scope, making the set slightly less focused.
The color tools cover essential operations like conversion, difference, contrast, harmony, and palette management. Minor gaps exist (e.g., no palette delete), but it's generally complete for its domain.
Available Tools
9 toolscolor_differenceAInspect
Perceptual difference (Delta-E) between two colors. color1 and color2 accept a hex, CSS name, RNV brand name, or saved-palette reference. method is 'ciede2000' (default, modern standard) or 'cie76'. A value near 1.0 is the threshold the eye can just notice; larger means more different. Returns the value and a plain-language interpretation.
| Name | Required | Description | Default |
|---|---|---|---|
| color1 | Yes | ||
| color2 | Yes | ||
| method | No | ciede2000 |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it accepts various color formats (hex, CSS name, etc.), has a default method, and returns both a value and interpretation. It is transparent about what the tool does.
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 (4 sentences), front-loaded with the main purpose, and efficiently covers purpose, parameters, method, and output interpretation with no unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema, the description explains the return value and interpretation sufficiently. It covers parameter semantics and behavioral traits but omits potential error handling. Overall, it is complete for the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds meaning for all three parameters: color1/color2 accept multiple formats, and method explains both 'ciede2000' and 'cie76' with context. This compensates well for the lack of schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it computes 'Perceptual difference (Delta-E) between two colors,' with a specific verb and resource. It distinguishes itself from sibling tools like mix_colors or contrast_check by focusing on perceptual difference calculation.
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 interpreting the return value (threshold near 1.0) and explains the method options, but does not explicitly state when to use this tool versus alternatives like contrast_check or mix_colors.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contrast_checkAInspect
WCAG contrast ratio between a foreground and background color, for accessibility. Both accept a hex, CSS name, RNV brand name, or saved-palette reference. Returns the ratio (1.0-21.0) plus pass/fail for AA and AAA at normal and large text sizes and for UI components. Use this to check if text will be readable on a background.
| Name | Required | Description | Default |
|---|---|---|---|
| background | Yes | ||
| foreground | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses output (ratio 1.0-21.0 and pass/fail for AA/AAA at normal/large text and UI components). 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?
Three sentences, front-loaded with purpose. No wasted words. Efficiently conveys necessary information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given output schema exists, description covers key return values (ratio and pass/fail by size). Could detail response structure, but sufficient for agent to understand 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 coverage is 0%, but description adds meaning: both parameters accept hex, CSS name, RNV brand name, or saved-palette reference. This significantly enhances beyond the schema's type string.
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 checks WCAG contrast ratio between foreground and background colors for accessibility. It specifies accepted color formats and what it returns, distinguishing it from siblings like color_difference.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: 'Use this to check if text will be readable on a background.' While it doesn't mention when not to use or alternatives, the context is clear and appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
convert_colorAInspect
Convert a color between formats. Input accepts a hex, CSS name, RNV brand name, or saved-palette reference. With to set to one of hex/rgb/hsv/hsl/lab, returns just that format; otherwise returns all of them.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| color | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It does not mention side effects, destructive actions, authentication needs, or rate limits. While it describes output behavior, it lacks transparency about safety or state changes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences with no wasted words. The first states purpose and input types, the second explains output behavior based on the 'to' parameter.
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 color conversion tool with an output schema, the description covers all key aspects: input formats, output options, and parameter behavior. Sibling tools are not relevant, so no need to address them.
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, but the description fully compensates: it specifies that 'color' accepts hex, CSS name, RNV brand name, or saved-palette reference, and that 'to' can be one of hex/rgb/hsv/hsl/lab. This adds essential meaning beyond the bare schema types.
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: 'Convert a color between formats.' It lists specific input types (hex, CSS name, RNV brand name, saved-palette reference) and distinguishes itself from siblings like generate_harmony and mix_colors by focusing solely on format conversion.
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 (color format conversion) and implies alternatives through sibling tool names. However, it does not explicitly state when not to use it or mention specific alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_harmonyAInspect
Generate a color harmony from a base color. base accepts a hex, CSS name, RNV brand name, or saved-palette reference (e.g. 'Spring line:2'). scheme is one of: complementary, analogous, triadic, split-complementary, tetradic (a.k.a. square), monochromatic, compound. Returns a list of hex colors.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | ||
| scheme | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It states the output format ('Returns a list of hex colors') but does not disclose potential side effects, auth requirements, or error handling. It is adequate for a simple read-only generation but lacks depth.
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 with the primary action. It uses three sentences with no redundancy. Could be slightly more structured, but it's efficient and covers all key points.
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 (two params, no nested objects) and the existence of an output schema, the description fully covers input and output. It explains all parameter formats and the return type, leaving no major gaps for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description fully compensates. It explains that 'base' accepts various color references and gives an example, and lists all seven valid values for 'scheme'. This adds significant meaning beyond the schema's plain string types.
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: 'Generate a color harmony from a base color.' It specifies the input formats (hex, CSS name, RNV brand name, saved-palette reference) and the scheme options, making it distinct from sibling tools like convert_color or mix_colors.
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 detailed parameter info but does not explicitly guide when to use this tool over siblings or when not to use it. It lacks context on typical use cases or exclusions, though the name and output make its role clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_paletteAInspect
Retrieve one saved palette by name, returning its colors and metadata. Returns null if no palette by that name exists.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description discloses key behavior: returns null if not found. No annotations provided, so description carries burden but could add read-only or idempotent traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two efficient sentences with no wasted words. Action and result are 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?
Description covers return values (colors, metadata) and null case. With one parameter and output schema present, it is adequately complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%; description only adds 'by name' context. For a single parameter, more detail (e.g., format restrictions) would help.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool's purpose: 'Retrieve one saved palette by name', with a specific verb and resource. It distinguishes from sibling tools like list_palettes and save_palette.
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?
Description implies usage (to get a specific palette by name) but lacks explicit guidance on when to use versus alternatives, such as list_palettes or missing palette handling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_palettesAInspect
List every saved palette as name + colors.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Output Schema
| Name | Required | Description |
|---|---|---|
| result | Yes |
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It implies read-only behavior but does not explicitly state safety, auth requirements, or side effects. Adequate but not thorough.
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?
A single, front-loaded sentence that efficiently conveys the tool's purpose and output without superfluous 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 no parameters and an existing output schema, the description fully captures what the tool does and what it returns, meeting the needs of a simple listing 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 tool has no parameters and schema coverage is 100%. The description adds no parameter info, which is acceptable 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 lists every saved palette and specifies the output includes name and colors, distinguishing it from siblings like save_palette or get_palette.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives like get_palette or convert_color. Lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mix_colorsAInspect
Blend up to 12 colors into one. Each color may be a hex (#d2bc93), a CSS name (red), an RNV brand name (brand gold, near-black), or a saved-palette reference (Spring line, or 'Spring line:2' for its 2nd swatch). Optional integer weights bias the blend (defaults to equal). mode selects the model: rgb/hsv/lab are digital blends (lab is perceptual and the default); paint mixes pigments via Kubelka-Munk physics (colors darken like real paint); ryb is the artist's color wheel; cmy is subtractive like printer inks. Returns hex and rgb.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | lab | |
| colors | Yes | ||
| weights | 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?
With no annotations, the description carries full burden. It discloses blending behavior, supported modes, and return format but does not cover edge cases like duplicate colors or zero-weight scenarios. The transparency is adequate but not exhaustive.
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 at around 100 words and front-loads the purpose. Each sentence adds value, though a more structured format (e.g., bullet points) could improve readability slightly.
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 modes, input formats, optional parameters) and existence of an output schema, the description covers key aspects. It does not mention error handling, but overall completeness is high.
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 description compensates fully. It explains the colors parameter (types, count limit), weights (optional, default equal), and mode (options and their behavior). This adds significant meaning beyond the raw 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 it blends up to 12 colors into one, specifies accepted color formats, optional weights, blending modes, and return values. This distinguishes it from siblings like convert_color and generate_harmony.
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 each blending mode (lab, paint, ryb, cmy) and provides context for selecting the appropriate model. It lacks explicit when-not-to-use guidance but effectively differentiates from sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_paletteAInspect
Persist a named color palette for later retrieval with get_palette or list_palettes. Use when the user wants to keep a set of colors under a name for reuse across sessions, such as a brand or launch palette. colors is a list of hex values; reusing an existing name overwrites that palette (upsert). Optional notes are stored as the palette's description. The saved name can then be referenced by other tools (mix_colors, convert_color, generate_harmony) as a palette reference. Author is recorded as RNVizion.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | ||
| notes | No | ||
| colors | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It reveals that the operation is persistent, has upsert semantics (overwrites on reusing name), stores optional notes as description, and records the author as RNVizion. This is comprehensive for a save 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 concise at about 100 words across 3 sentences, each serving a clear purpose: stating the main action, defining usage context, and detailing parameters/behavior. No redundant information, and the most critical point 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?
Given the tool's complexity (3 parameters, no annotations, but has an output schema), the description fully equips the agent with parameter semantics, usage context, and behavioral traits. It also mentions cross-referencing by other tools, which aids in understanding the tool's role.
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 compensates by clarifying each parameter: 'colors is a list of hex values', 'reusing an existing name overwrites that palette (upsert)', and 'Optional notes are stored as the palette's description.' This adds significant semantic value beyond the plain 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 the tool's purpose: 'Persist a named color palette for later retrieval with get_palette or list_palettes.' This is a specific verb-resource pairing that distinguishes it from sibling tools like get_palette, list_palettes, and other palette-related tools such as mix_colors and convert_color.
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 'Use when the user wants to keep a set of colors under a name for reuse across sessions' and notes the upsert behavior. While it does not list explicit alternatives for when not to use, the guidance is clear and contextually sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transform_textAInspect
Apply an exact, deterministic text transformation. operation is one of: UPPERCASE, lowercase, 'Title Case', 'Sentence case', camelCase, PascalCase, snake_case, CONSTANT_CASE, kebab-case, dot.case, 'iNVERTED cASE'. Use this rather than converting case by hand.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| operation | Yes |
Output Schema
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Tool Definition Quality
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description claims 'exact, deterministic' behavior, which is helpful. However, it omits details on error handling for invalid operations or non-string inputs. For a simple transformation, this is adequate.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with two sentences, no fluff, and front-loads the purpose. Every sentence adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the output schema exists, the description does not need to explain return values. It covers the main functionality and lists operation options. Minor missing details like special character handling do not detract significantly.
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 adds the list of operation values beyond the schema's string type. It does not elaborate on the 'text' parameter further. The examples provide useful context but not exhaustive semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool applies an exact, deterministic text transformation and lists specific operations. It is distinct from sibling color 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 context by stating to use this instead of manual case conversion, implying it is the appropriate tool for text transformations. However, it does not explicitly mention 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.
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!