rnv-color-mcp, a hosted color-workflow MCP server (Python, Streamable HTTP).
Tools: mix (including Kubelka-Munk paint physics), convert between formats, generate harmonies, transform text case, and save/list/get named palettes. It resolves hex / CSS / custom brand color names and refuses unknown colors rather than guessing.
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.9/5 across 9 of 9 tools scored.
The color tools (difference, contrast, conversion, harmony, mixing, palette) are all clearly distinct and well-differentiated by their descriptions. The inclusion of transform_text is off-topic but clearly described as a text transformation tool, so it does not cause confusion with the color tools.
Most tool names follow a verb_noun pattern (generate_harmony, convert_color, mix_colors, etc.), but color_difference and contrast_check use noun_noun. This minor inconsistency prevents a perfect score, but overall the naming is predictable and readable.
With 9 tools, the server is well-scoped for its purpose. Each tool addresses a distinct color-related operation or palette management, and the count is within the optimal range for a focused MCP server.
The server covers core color operations (difference, contrast, conversion, harmony, mixing) and palette CRUD (create, read, list). Missing a delete palette tool and possibly advanced features like image extraction, but the essential workflows are present.
color_differenceAInspectPerceptual 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. Read-only and deterministic, with no side effects. Use ciede2000 for accuracy and pick cie76 only to match a legacy system; to test whether text is legible on a background (not raw difference) use contrast_check instead.
| Name | Required | Description | Default |
|---|---|---|---|
| color1 | Yes | ||
| color2 | Yes | ||
| method | No | ciede2000 |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It states 'Read-only and deterministic, with no side effects,' which covers the safety profile, and explains the return value ('Returns the value and a plain-language interpretation'). This meets the bar for transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured: purpose first, then parameter formats, method selection, return value, safety note, and usage guidance. Every sentence adds value, and the length is appropriate 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 output schema exists, the description needn't detail return structure, but it still does. It covers input formats, method semantics, output interpretation, safety, and comparative guidance. This is a complete, self-contained tool description.
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 fully explains all three parameters: color1/color2 accept hex, CSS name, RNV brand name, or saved-palette reference, and method is 'ciede2000' (default) or 'cie76'. This compensates completely for the sparse 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 opens with a specific verb and resource: 'Perceptual difference (Delta-E) between two colors.' It clearly distinguishes the tool from siblings by naming contrast_check, which serves a different purpose (legibility rather than raw difference). This is unambiguous and identifiable.
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 when to use each method ('Use ciede2000 for accuracy and pick cie76 only to match a legacy system') and provides a direct alternative ('to test whether text is legible on a background ... use contrast_check instead'). This gives the agent clear decision criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
contrast_checkAInspectWCAG 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. Read-only and deterministic, with no side effects. Use this for legibility and accessibility checks; to measure raw perceptual difference between two colors rather than readability use color_difference instead.
| Name | Required | Description | Default |
|---|---|---|---|
| background | Yes | ||
| foreground | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, but the description discloses key behavioral traits: it is read-only, deterministic, has no side effects, and returns the ratio plus pass/fail for AA/AAA at various text sizes and UI components. This fully covers the safety and output 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?
Four concise sentences, each serving a distinct purpose: purpose, input formats, output details, and usage guidance with alternative. No superfluous 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?
With a simple two-parameter input and an output schema present, the description covers input formats, output details, and use cases. It is complete for the tool's complexity and integrates well with the existing schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description compensates by explaining that both foreground and background accept hex, CSS name, RNV brand name, or saved-palette reference. This adds meaningful format information beyond the bare string type, though it could have elaborated on each parameter separately.
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 WCAG contrast ratio between foreground and background colors for accessibility. It explicitly distinguishes from sibling color_difference by noting the alternative for measuring perceptual difference rather than readability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool for legibility and accessibility checks, and names color_difference as the alternative for raw perceptual difference. This provides clear when-to-use and 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.
convert_colorAInspectConvert 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. Read-only and deterministic, with no side effects. Use for format conversion of a single color; to blend several colors into one use mix_colors, and to compare two colors use color_difference.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | ||
| color | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility and delivers: it states 'Read-only and deterministic, with no side effects,' and explains the conditional output when `to` is set versus omitted. This goes beyond structural fields and gives a transparent behavioral 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?
The entire description is two sentences. The first sentence states the purpose and input types, the second covers output logic and usage guidance. Every clause earns its place with no 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 presence of an output schema (which handles return value details), the description is complete: it covers input variability, the conditional output, side-effect safety, deterministic behavior, and alternatives. There are no significant gaps for a tool with two parameters and a single color conversion task.
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 does: 'color' is defined as accepting hex, CSS name, RNV brand name, or saved-palette reference, and 'to' accepts one of hex/rgb/hsv/hsl/lab, with the default behavior described. This adds rich meaning beyond the bare string type in 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 starts with 'Convert a color between formats,' a specific verb and resource. It clearly enumerates accepted input types (hex, CSS name, RNV brand name, saved-palette reference) and the output behavior, and explicitly distinguishes from sibling tools by naming mix_colors and color_difference as alternatives.
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 last sentence gives explicit guidance: 'Use for format conversion of a single color; to blend several colors into one use mix_colors, and to compare two colors use color_difference.' This is a direct when-to-use with named alternatives, satisfying the dimension fully.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_harmonyAInspectGenerate 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. Read-only and deterministic: it derives the colors from the base and stores nothing, so it has no side effects and is safe to call repeatedly. Use to expand one base color into a related set; to blend existing colors into a single color use mix_colors, and to persist a set you like use save_palette.
| Name | Required | Description | Default |
|---|---|---|---|
| base | Yes | ||
| scheme | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It explicitly states 'Read-only and deterministic,' 'stores nothing,' 'no side effects,' and 'safe to call repeatedly.' This fully discloses the behavioral profile of a safe, repeatable 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 efficiently structured: purpose in the first sentence, parameter details in the second, output in the third, side-effect safety in the fourth, and usage alternatives in the fifth. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Even with an output schema present, the description covers all necessary context: input types, scheme values, return type, side-effect behavior, and tool selection guidance. It is complete for a 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?
Schema coverage is 0%, so the description must compensate. It thoroughly explains base accepts 'a hex, CSS name, RNV brand name, or saved-palette reference' with an example, and lists all valid scheme values including synonyms. This far exceeds what the bare schema provides.
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: 'Generate a color harmony from a base color' and its output: 'Returns a list of hex colors.' It also explicitly distinguishes it from siblings by naming mix_colors and save_palette as alternatives for 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?
Provides explicit when-to-use guidance: 'Use to expand one base color into a related set; to blend existing colors into a single color use mix_colors, and to persist a set you like use save_palette.' It also details accepted input formats and scheme options, making selection straightforward.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_paletteAInspectRetrieve one saved palette by name, returning its colors and metadata. Returns null if no palette by that name exists. Read-only; no side effects. Use when you already know the palette name; to list available names first use list_palettes, and to create or update a palette use save_palette.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: it states 'Read-only; no side effects' and 'Returns null if no palette by that name exists.' This gives the agent a clear safety and error-handling context, going beyond minimal requirements.
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 serving a distinct purpose: primary action, return behavior, and usage guidance. It is front-loaded with the core purpose and contains no filler or redundant restatements.
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 one-parameter read-only tool, the description covers purpose, behavior (null return, read-only), usage context, and alternatives. Given the available output schema, the information is complete and sufficient for an agent 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?
The only parameter 'name' is clarified through the description's repeated references to 'by name' and the null condition for missing names. With 0% schema description coverage, this fills the gap and tells the agent exactly what the parameter represents, though it could have been more 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 explicitly states 'Retrieve one saved palette by name' with a specific verb and resource, and distinguishes itself from siblings by noting that 'list_palettes' provides all names and 'save_palette' handles creation/updates. This makes the tool's function 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?
It gives clear guidance: 'Use when you already know the palette name' and directs users to 'list_palettes' for listing names and 'save_palette' for modifications. This explicitly covers when to use this tool and when to choose an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_palettesAInspectList every saved palette as name + colors. Read-only; no side effects. Use to discover what palettes exist or to find a name before calling get_palette; to fetch one palette's full detail use get_palette, and to create or overwrite one use save_palette.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses 'Read-only; no side effects' and the return format 'name + colors', which adds context. It doesn't cover access control or edge cases, but for a read-only list tool 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?
Two sentences: the first states purpose and output, the second provides usage guidance. 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?
For a simple list tool with no parameters and an output schema (not shown), the description covers return content, safety, and use cases, making it complete for its scope.
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 schema coverage is trivially 100%. With 0 params, the baseline is 4; the description doesn't need to add parameter details.
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 'List every saved palette as name + colors' with a specific verb and resource, and clearly distinguishes from get_palette (full detail) and save_palette (create/overwrite).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly says to use this tool to discover what palettes exist or to find a name before calling get_palette, and directs users to get_palette for full detail and save_palette for creation/overwrite, providing clear alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
mix_colorsAInspectBlend 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, best for on-screen color); paint mixes pigments via Kubelka-Munk physics (colors darken like real paint, use it for physical-media matching); ryb is the artist's color wheel; cmy is subtractive like printer inks. Returns hex and rgb. Read-only and deterministic: it computes a result and stores nothing, so it is safe to call repeatedly with no side effects. Use to combine multiple colors into a single blend; to convert one color between formats use convert_color, and to measure how far apart two colors are use color_difference.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | lab | |
| colors | Yes | ||
| weights | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description carries the full burden. It discloses 'Read-only and deterministic: it computes a result and stores nothing, so it is safe to call repeatedly with no side effects.' This is a strong, clear behavioral guarantee absent from 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?
Despite being dense, every sentence earns its place: core function first, then input formats, weights, modes, return, safety, and usage guidance. The structure is logical and front-loaded with the essential 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?
The tool is complex with multiple modes and input formats; the description covers all aspects: inputs, defaults, mode semantics, return values, side-effect safety, and sibling relationships. An output schema covers return details further, so nothing major is 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 has 0% property descriptions, so the description fully compensates. It explains accepted color formats (hex, CSS, RNV brand, saved-palette references), weight behavior and defaults, and details each mode (rgb/hsv/lab, paint, ryb, cmy) with context. This goes far beyond the minimal 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 opens with 'Blend up to 12 colors into one,' a specific verb and resource with a clear limit. It explicitly distinguishes itself from siblings by stating 'to convert one color between formats use convert_color, and to measure how far apart two colors are use 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?
Explicitly states when to use the tool ('Use to combine multiple colors into a single blend') and names alternatives for other tasks (convert_color for conversion, color_difference for distance). It also guides mode selection with use cases (digital on-screen, paint matching, artist wheel, printer inks).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
save_paletteAInspectPersist a named color palette for later retrieval with get_palette or list_palettes. colors is a list of hex values; optional notes are stored as the palette's description. Author is recorded as RNVizion. This WRITES to the palette store and is the only tool here that does. Reusing an existing name overwrites that palette: save and update are the same call (an upsert), there is no separate update operation. Returns a durable flag: true if the palette reached durable storage (the HF Dataset) and will survive a restart, false if it saved to the local working copy only (which is lost on rebuild, e.g. when the Space HF_TOKEN is missing or lacks write scope). 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; to read a palette back use get_palette, and to see what already exists use list_palettes. The saved name can then be passed to mix_colors, convert_color, and generate_harmony as a palette reference.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Unique key the palette is stored under. Reusing an existing name overwrites that palette (upsert). Can be referenced later by other tools as 'name:index', e.g. 'Spring line:2'. | |
| notes | No | Optional human-readable description stored as the palette's notes. | |
| colors | Yes | Ordered list of hex colors, each '#RRGGBB' (e.g. '#d2bc93'). Order is preserved; at least one required. |
| Name | Required | Description |
|---|---|---|
| name | Yes | Name the palette was stored under. |
| notes | Yes | Description stored on the palette; empty if none given. |
| colors | Yes | The hex colors saved, in order. |
| durable | Yes | True if the palette was written through to the durable HF Dataset and will survive a Space rebuild; False if it saved to the local working copy only (e.g. the Space HF_TOKEN is missing or lacks write scope), meaning it will be lost on the next restart. |
| color_count | Yes | Number of colors in the saved palette. |
| overwritten | Yes | True if a palette with this name already existed and was replaced; False if newly created. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses the write operation, upsert behavior, the fact that it overwrites on name reuse, the author being set to RNVizion, and the durable flag semantics including the failure mode when HF_TOKEN is missing or lacks write scope. This is exceptionally 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 dense but every sentence adds critical information. It starts with the core action and then efficiently covers related tools, upsert semantics, durability, and when to use. No wasted words despite the depth.
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 (write, upsert, durability, cross-tool integration), the description covers all necessary context: purpose, behavior, edge cases, return value, alternatives, and downstream usage. Even with an output schema present, the description explains the meaningful part of the response (durable flag) which is essential for the 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 coverage is 100%, but the description adds meaning beyond the schema: colors are hex values, notes become the palette's description, the name acts as an upsert key, and the author is recorded as RNVizion. It also explains the return durable flag. This enriches the parameter context beyond the baseline.
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: 'Persist a named color palette for later retrieval.' It clearly distinguishes from siblings by naming get_palette and list_palettes as retrieval tools and stating this is 'the only tool here that does' write 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?
Provides explicit usage guidance: 'Use when the user wants to keep a set of colors under a name for reuse across sessions.' It gives alternatives: 'to read a palette back use get_palette, and to see what already exists use list_palettes.' Also explains how the saved name can be passed to other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
transform_textAInspectApply 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'. Read-only and deterministic: it returns the transformed string and changes nothing, safe to call repeatedly. Use whenever exact, reproducible case formatting matters rather than rewriting the text by hand or guessing the casing.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | ||
| operation | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses behavioral traits: 'Read-only and deterministic: it returns the transformed string and changes nothing, safe to call repeatedly.' Since no annotations are provided, this carries the full burden and does so excellently, covering side effects and repeatability.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the purpose and operations. The second sentence adds usage and behavior. Every word earns its place; no redundancy or 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?
For a simple two-parameter tool with an output schema, the description covers the tool's purpose, valid inputs, behavior, and usage. The output schema likely documents the return value, and the description explicitly states it 'returns the transformed string'. Complete for its 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?
The schema defines text and operation as plain strings with no enums. The description lists all valid operation values (UPPERCASE, lowercase, camelCase, etc.), which is essential parameter semantics that the schema lacks. It does not elaborate on the exact behavior of each case type, but the list is sufficient for basic 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 tool's function with a specific verb and resource: 'Apply an exact, deterministic text transformation.' It enumerates all supported operations, making it unambiguous. The sibling tools are all color-related, so this text tool is immediately distinguishable.
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 whenever exact, reproducible case formatting matters rather than rewriting the text by hand or guessing the casing.' This gives a clear context of use and a contrast to manual alternatives, though it does not name specific alternative tools (none exist among siblings).
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!
