Unified AI API — 30+ models from OpenAI, Anthropic, Google, Groq, and xAI through one API key. Plus translation, weather, and utility endpoints.
Scored across 8 tools
Each tool targets a clearly distinct capability: chat, embeddings, image generation, speech synthesis, transcription, currency, translation, and weather. An agent can easily distinguish them by resource and action, with no meaningful overlap.
All names use readable snake_case, and the AI-related tools share an ai_ prefix while utility tools are bare nouns. This grouping is predictable, though the mixed prefixed/unprefixed pattern is a minor inconsistency.
Eight tools is well-scoped for a multi-capability AI utility server. Each tool represents a distinct, useful operation without obvious filler.
The surface covers core AI modalities plus several useful utilities, giving broad lifecycle coverage. Minor gaps remain, such as model listing/discovery or explicit image/audio understanding beyond generation and transcription.
Send a message to any of 40 AI models. 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.2-1b | |
| 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?
With readOnlyHint=true already declaring a non-mutating operation, the description adds that a response is returned and that multi-turn context is carried in messages. It omits anything about rate limits, cost, or model-selection tradeoffs, which are the real behavioral unknowns for a 40-model chat endpoint.
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 short sentences, front-loaded with capability and model breadth, followed by return behavior and history support. Slightly wasteful in that the return statement is nearly self-evident, but nothing is padded.
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?
No output schema exists, and the description does state that the model's response is returned, so the return contract is covered. For a simple three-parameter chat call with full schema coverage, the only missing piece is operational context such as cost or latency differences between models.
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 model enum, messages structure, and max_tokens default are already documented. The description only restates that conversation history is passed through the messages array, adding no syntax or selection guidance 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?
States a specific verb ('Send a message') and resource ('any of 40 AI models') plus the outcome ('Returns the model's response'). Sibling tools are all different modalities (embeddings, images, speech, translate), so the purpose is unambiguous even though no sibling is named explicitly.
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 by the naming of conversation history via the messages array, but there is no explicit when-to-use guidance, no mention of cost/latency tradeoffs across 40 models, and no exclusions. An agent must infer that this is the general text-chat entry point.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate 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?
Annotations already declare readOnlyHint=true, so the agent knows this is a safe read operation. The description adds the use-case context but says nothing about model choice, embedding dimensions, batching limits, or return format, which are the traits that would actually matter here.
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?
One sentence with zero waste, front-loading the action and resource before the 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?
For a simple one-parameter tool with no output schema, the description is adequate but silent on what comes back (vector size/shape) and whether array input yields batched embeddings, leaving a modest gap an agent might care about.
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% and the single 'text' parameter (string or array) is fully documented in the schema, so the description carries no additional parameter meaning. 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?
States a specific verb and resource ('Generate vector embeddings') plus the intended applications ('text search and similarity comparison'), which distinguishes it clearly from siblings like ai_chat, ai_images, and 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 use cases ('text search and similarity comparison') imply when to reach for this tool, but there is no explicit when/when-not guidance or reference to alternatives among the many ai_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate 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.
Convert 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.
Transcribe 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.
Get 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.
Translate 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.
Get 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
ai_chat2 fields changedInput schema / properties / model / descriptionPrevious value: -"Model to use, e.g. 'claude-sonnet-4.6', 'gpt-4.1', 'llama-3.1-8b'. Defaults to llama-3.1-8b"New value: +"Model to use, e.g. 'claude-sonnet-4.6', 'gpt-4.1', 'llama-3.1-8b'. Defaults to llama-3.2-1b"Input schema / properties / model / enumAdded value: +[
+ "llama-3.2-1b",
+ "llama-3.2-3b",
+ "llama-3.1-8b",
+ "llama-3.1-8b@workers-ai",
+ "gemini-2.5-flash-lite",
+ "gemini-2.0-flash",
+ "gpt-oss-20b",
+ "mistral-7b",
+ "glm-4.7-flash",
+ "qwen3-30b",
+ "gpt-4.1-nano",
+ "gpt-4.1-mini",
+ "gpt-4o-mini",
+ "gemini-2.5-flash",
+ "llama-3.3-70b",
+ "llama-3.3-70b@workers-ai",
+ "deepseek-r1-32b",
+ "claude-haiku-4.5",
+ "gpt-oss-120b",
+ "grok-4.1-fast",
+ "grok-3-mini",
+ "glm-5.2",
+ "gemma-4-26b",
+ "mistral-small-3.1-24b",
+ "qwen2.5-coder-32b",
+ "gpt-4.1",
+ "gpt-4o",
+ "o4-mini",
+ "o3-mini",
+ "o3",
+ "claude-sonnet-4.6",
+ "claude-opus-4.6",
+ "claude-opus-4.7",
+ "claude-opus-4.8",
+ "grok-3",
+ "kimi-k2.7-code",
+ "qwen3.8-27b",
+ "gpt-6-luna",
+ "gpt-6.1-sol",
+ "claude-sonnet-5.5",
+ "claude-opus-5.5",
+ "gemini-3.8-flash"
+]ai_embeddings2 fields changedInput schema / properties / text / oneOfAdded value: +[
+ {
+ "type": "string"
+ },
+ {
+ "items": {
+ "type": "string"
+ },
+ "type": "array"
+ }
+]Input schema / properties / text / typeRemoved value: -"string"ai_chatai_embeddingsai_imagesai_speechai_transcribecurrencytranslateweather
Add one secure layer between your agents and this server.