Unified AI API — 30+ models from OpenAI, Anthropic, Google, Groq, and xAI through one API key. Plus translation, weather, and utility endpoints.
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/5 across 8 of 8 tools scored.
Each tool targets a distinct capability: chat, embeddings, image generation, speech synthesis, transcription, currency exchange, translation, and weather. There is no overlap or ambiguity between them.
The five AI tools follow a consistent 'ai_' prefix pattern (ai_chat, ai_embeddings, etc.), but the three utility tools (currency, translate, weather) break this convention, creating a minor inconsistency.
With 8 tools, the server is well-scoped for a multi-purpose AI and utility toolkit. The count is neither too sparse nor overly heavy, and each tool has a clear role.
The toolset covers a broad range of AI modalities (text, embedding, image, audio) plus common utilities (currency, translation, weather). Minor gaps exist, such as video generation or web search, but these are not essential for the apparent scope.
ai_chatASend a message to any of 30+ AI models (OpenAI, Anthropic, Google, Groq, xAI). Returns the model's response. Supports conversation history via the messages array.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model to use, e.g. 'claude-sonnet-4.6', 'gpt-4.1', 'llama-3.1-8b'. Defaults to llama-3.1-8b | |
| messages | Yes | Array of chat messages, each with 'role' (user/assistant/system) and 'content' (text) | |
| max_tokens | No | Maximum tokens to generate in the response. Default 1024 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true, covering the safety profile. The description adds useful context about supporting conversation history via the messages array and supporting multiple AI providers, but it does not disclose external API dependencies, rate limits, or response structure in detail. There is 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 three short sentences, front-loaded with the primary action. Each sentence adds value: model variety, return value, and conversation history. There is no redundant or wasteful wording.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters and no output schema, the description covers the essential aspects: purpose, supported models, return value, and conversation history. While a more detailed response format would be beneficial, the description is adequate for a chat tool and is supported by clear annotations.
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% with well-described parameters (model, messages, max_tokens). The description reiterates and reinforces the messages parameter by mentioning conversation history, but it does not add significant format or syntax details beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb+resource combination: 'Send a message' to '30+ AI models', which clearly distinguishes it from sibling tools like ai_embeddings, ai_images, ai_speech, and ai_transcribe. It also mentions conversation history, making the chat-focused purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied through the description (message-based chat interaction), but there are no explicit when-to-use or when-not-to-use guidelines. The sibling tool names suggest different modalities, yet the description does not explicitly say 'use this for chat rather than embeddings/images'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ai_embeddingsAGenerate vector embeddings for text search and similarity comparison.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text or array of texts to generate embeddings for |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation readOnlyHint=true already indicates a safe read-only operation, so the description does not need to disclose side-effect risks. The description adds no additional behavioral context such as output format, rate limits, or error behavior beyond the basic generation of embeddings. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that immediately states the tool's primary function and purpose. There is no filler or redundant information, and every word contributes to understanding what the tool does.
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 tool with a read-only annotation, the description is fairly complete. It communicates the key purpose and the input type is covered by the schema. However, it does not clarify the output format (e.g., the dimension of the vectors) or whether the result is returned directly or asynchronously, which would be useful in the absence of an output schema. Minor gaps prevent a perfect score.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 100% coverage: the only parameter, 'text', includes a description explaining it accepts text or an array of texts. The tool description does not add any further parameter-specific semantics. Since the schema already documents the parameter well, a baseline score of 3 is appropriate.
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 generates vector embeddings, specifying the exact resource (embeddings) and the intended use case (text search and similarity comparison). This distinguishes it from sibling AI tools like ai_chat and ai_images, which have different purposes.
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: for text search and similarity tasks. It does not explicitly exclude alternatives or mention when not to use it, but the use case is clear enough. Sibling tools are not referenced, so no explicit alternatives are given, but the context implies these are the primary scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ai_imagesAGenerate images from text prompts using Flux models. Returns base64-encoded PNG.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Image model (e.g. 'flux-schnell') | |
| prompt | Yes | Description of the image to generate | |
| num_steps | No | Number of inference steps. More steps = higher quality. Default 4 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds useful context beyond the readOnlyHint annotation by specifying the return format (base64-encoded PNG). However, it does not disclose potential rate limits, costs, or model-specific behaviors, which the annotation does not cover. The annotation already ensures no mutation, so the additional output format info is valuable but not comprehensive.
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 action, and contains no filler. Every word contributes: the purpose, the model family, and the output format. It is concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (3 well-described parameters, no output schema), the description is adequately complete. It states the return format, which is essential for the agent to handle the response. It does not cover every edge case, but the schema and annotation fill the essential gaps.
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%, so the baseline is 3. The description mentions 'Flux models' and 'text prompts' which map to the model and prompt parameters, but it adds no extra meaning beyond the schema's parameter descriptions. The schema already explains num_steps, so the description does not need to compensate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Generate') and resource ('images from text prompts') and clearly states the output format ('base64-encoded PNG'). It is distinct from sibling tools like ai_chat or ai_embeddings by focusing on image generation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies the appropriate use case: generating images from text prompts. While it doesn't explicitly mention alternatives or exclusions, the context is unambiguous given the tool's name and purpose. The sibling context further differentiates it from chat, embedding, and transcription tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ai_speechAConvert text to natural-sounding speech audio. Returns base64-encoded WAV.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to convert to speech |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses the return format (base64-encoded WAV) beyond the annotations. The readOnlyHint annotation aligns with the non-mutating nature of the operation, and no contradictions are present.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two concise sentences, front-loaded with the main action and no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter tool with no output schema, the description covers purpose and return format sufficiently. It could mention limits or usage constraints, but the essential information is present.
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 fully describes the single parameter 'text' with 100% coverage, and the description does not add additional semantics beyond what the schema already provides. Baseline 3 is appropriate.
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 converts text to speech audio, using a specific verb and resource, and specifies the output format (base64-encoded WAV), which clearly differentiates it from sibling tools like ai_transcribe.
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 context implies use for text-to-speech synthesis, but it does not explicitly mention alternatives or when not to use it. However, the sibling names provide clear differentiation, so the usage context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
ai_transcribeATranscribe audio to text with timestamps using Whisper.
| Name | Required | Description | Default |
|---|---|---|---|
| audio | Yes | Base64-encoded audio file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds some behavioral context by noting the output includes timestamps and that it uses Whisper. However, it does not disclose whether the operation is synchronous, any audio size limits, or how the timestamps are structured. The readOnlyHint annotation indicates no side effects, but the description does not go beyond the annotation to provide deeper insight into runtime behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, concise sentence that immediately states the action and output. It contains no extraneous information and is well-structured for quick understanding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple one-parameter schema and absence of an output schema, the description is largely sufficient for basic invocation. It covers the core purpose and output, but could benefit from noting limitations such as supported audio formats, file size constraints, or synchronous/asynchronous behavior. Nevertheless, it is reasonably complete for a tool of this 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 schema fully documents the single parameter 'audio' as base64-encoded audio, providing 100% coverage. The description does not add any additional parameter-specific information, such as supported formats or maximum file size, so the baseline score of 3 is appropriate.
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: 'Transcribe audio to text with timestamps using Whisper.' It uses a specific verb (transcribe), identifies the resource (audio), names the output format (text with timestamps), and the method (Whisper), which clearly differentiates it from sibling tools like ai_speech or translate.
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?
There is no guidance on when to use this tool versus alternatives. The description only states what it does, without mentioning use cases, prerequisites, or exclusions. It does not explicitly compare to related tools like ai_speech, leaving the agent to figure out the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
currencyAGet live currency exchange rates and convert between 160+ currencies.
| Name | Required | Description | Default |
|---|---|---|---|
| to | No | Target currency code (e.g. 'GBP', 'JPY') | |
| from | No | Source currency code (e.g. 'USD', 'EUR', 'CAD') | |
| amount | No | Amount to convert. Default 1 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations indicate readOnlyHint=true, and the description's 'Get' and 'convert' align with a read-only operation. It adds 'live' and '160+ currencies' as useful context, but doesn't disclose potential error handling, rate source, or API limits. With annotations covering the safety profile, this is acceptable.
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 concise sentence that immediately communicates the core functionality without any fluff. 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?
For a simple read-only currency tool with no output schema, the description provides adequate context. It doesn't explain return value format or how to list supported currencies, but the core operation is clear enough for an agent to invoke 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 schema has 100% parameter coverage, so the description doesn't need to repeat parameter details. It adds the context of 'convert between 160+ currencies' which hints at the to/from parameters, but doesn't enrich beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'live currency exchange rates' with an added conversion capability. It differentiates from sibling tools like weather and translate, making its purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage when live rates or currency conversion are needed, which is clear in context. However, it doesn't explicitly state when NOT to use it or mention alternative tools, but given the distinct sibling set, it's adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
translateATranslate text between 75+ languages with auto-detection. Supports dynamic pricing based on text length.
| Name | Required | Description | Default |
|---|---|---|---|
| to | Yes | Target language code (e.g. 'es', 'de', 'ja') | |
| from | No | Source language code (e.g. 'en', 'fr'). Use 'auto' for auto-detection | |
| text | Yes | Text to translate |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the readOnlyHint annotation, the description adds useful behavioral details: auto-detection support and dynamic pricing based on text length. These are meaningful and do not contradict the annotation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the core purpose, and contains no extraneous information. Every word adds value.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple translation tool with full parameter documentation and a readOnlyHint, the description adequately covers features and contextual details. No output schema is needed, and the description is complete for the tool's 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 descriptions cover all three parameters with 100% coverage, but the description enhances this by explaining auto-detection, which directly relates to the 'from' parameter's 'auto' option, and hints at pricing implications tied to text length.
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 'Translate text between 75+ languages with auto-detection', using a specific verb and resource. It distinguishes this tool from siblings like ai_chat or currency by focusing on translation capabilities.
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 gives clear context that this tool is for translation and highlights auto-detection, but it does not explicitly mention when not to use it or alternative tools. The context is evident, so it earns a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
weatherAGet current weather for any city or coordinates worldwide. Returns temperature, humidity, wind, and conditions.
| Name | Required | Description | Default |
|---|---|---|---|
| lat | No | Latitude (alternative to location) | |
| lon | No | Longitude (alternative to location) | |
| location | No | City name (e.g. 'Toronto', 'London', 'Tokyo') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already establishes safe read-only behavior, and the description adds valuable context by stating the return payload (temperature, humidity, wind, conditions) and geographic scope. No contradictions or destructive behavior to disclose.
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 sentence conveys purpose and return values with zero filler. The structure is front-loaded with the action, then the scope, then the output—all in one efficient line.
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 no output schema, the description appropriately enumerates the key return fields (temperature, humidity, wind, conditions). For a low-complexity read-only tool with completely documented optional parameters, this is sufficiently complete, though units (e.g., Celsius vs Fahrenheit) are not specified.
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 for all three parameters is 100%, so the schema already documents lat, lon, and location. The description adds no new parameter-level meaning beyond acknowledging both city and coordinate inputs, which is redundant with the 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 starts with a specific verb+resource ('Get current weather') and clearly scopes it to any city or coordinates worldwide. This unambiguously distinguishes it from sibling tools like currency and translate, which are unrelated domains.
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 implicitly signals when to use the tool (for weather queries) and its worldwide coverage. Since there are no competing weather tools among siblings, no explicit exclusions are necessary, though it doesn't explicitly state when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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!
