This MCP server provides comprehensive AI capabilities through DeepInfra's OpenAI-compatible API:
Image Generation - Create images from text prompts using models like Bria-3.2, returning the generated image URL
Text Generation - Generate text completions and responses from prompts using LLMs like Llama-2
Text Embeddings - Convert text into vector embeddings for semantic analysis and similarity comparisons
Speech Recognition - Transcribe audio files from URLs to text using Whisper models
Zero-Shot Image Classification - Classify images into custom categories by comparing against provided candidate labels
Object Detection - Detect and describe objects within images using multimodal models
Image Classification - Analyze and classify image contents with detailed descriptions
Text Classification - Analyze text for sentiment and categorization
Token Classification (NER) - Extract and classify named entities (people, places, organizations) from text
Fill Mask - Predict and fill in masked/missing words in text sequences
All tools are configurable via environment variables, support custom model selection, can be selectively enabled/disabled, and require a DeepInfra API key for authentication.
Provides AI capabilities using DeepInfra's OpenAI-compatible API, including image generation, text processing, embeddings, speech recognition, image classification, object detection, and various NLP tasks like sentiment analysis and named entity recognition.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@MCP DeepInfra AI Tools Server generate an image of a futuristic city at sunset with flying cars"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
This is a Model Context Protocol (MCP) server that provides various AI capabilities using the DeepInfra OpenAI-compatible API, including image generation, text processing, embeddings, speech recognition, and more.
mcp-deepinfra/
├── src/
│ └── mcp_deepinfra/
│ ├── __init__.py # Package initialization
│ └── server.py # Main MCP server implementation
├── tests/
│ ├── conftest.py # Pytest fixtures and configuration
│ ├── test_server.py # Server initialization tests
│ └── test_tools.py # Individual tool tests
├── pyproject.toml # Project configuration and dependencies
├── uv.lock # Lock file for uv package manager
├── run_tests.sh # Convenience script for running tests
└── README.md # This fileRelated MCP server: Hugging Face MCP Server
Install uv if not already installed:
curl -LsSf https://astral.sh/uv/install.sh | shClone or download this repository.
Install dependencies:
uv syncSet up your DeepInfra API key:
Create a .env file in the project root:
DEEPINFRA_API_KEY=your_api_key_hereYou can configure which tools are enabled and set default models for each tool using environment variables in your .env file:
ENABLED_TOOLS: Comma-separated list of tools to enable. Use "all" to enable all tools (default: "all"). Example: ENABLED_TOOLS=generate_image,text_generation,embeddings
MODEL_GENERATE_IMAGE: Default model for image generation (default: "Bria/Bria-3.2")
MODEL_TEXT_GENERATION: Default model for text generation (default: "meta-llama/Llama-2-7b-chat-hf")
MODEL_EMBEDDINGS: Default model for embeddings (default: "sentence-transformers/all-MiniLM-L6-v2")
MODEL_SPEECH_RECOGNITION: Default model for speech recognition (default: "openai/whisper-large-v3")
MODEL_ZERO_SHOT_IMAGE_CLASSIFICATION: Default model for zero-shot image classification (default: "openai/gpt-4o-mini")
MODEL_OBJECT_DETECTION: Default model for object detection (default: "openai/gpt-4o-mini")
MODEL_IMAGE_CLASSIFICATION: Default model for image classification (default: "openai/gpt-4o-mini")
MODEL_TEXT_CLASSIFICATION: Default model for text classification (default: "microsoft/DialoGPT-medium")
MODEL_TOKEN_CLASSIFICATION: Default model for token classification (default: "microsoft/DialoGPT-medium")
MODEL_FILL_MASK: Default model for fill mask (default: "microsoft/DialoGPT-medium")
The tools always use the models specified via environment variables. Model selection is configured at startup time through the environment variables listed above.
To run the server locally:
uv run mcp_deepinfraOr directly with Python:
python -m mcp_deepinfra.serverConfigure your MCP client (e.g., Claude Desktop) to use this server.
For Claude Desktop, add to your claude_desktop_config.json:
{
"mcpServers": {
"deepinfra": {
"command": "uv",
"args": ["run", "mcp_deepinfra"],
"env": {
"DEEPINFRA_API_KEY": "your_api_key_here"
}
}
}
}This server provides the following MCP tools:
generate_image: Generate an image from a text prompt. Returns the URL of the generated image.
text_generation: Generate text completion from a prompt.
embeddings: Generate embeddings for a list of input texts.
speech_recognition: Transcribe audio from a URL to text using Whisper model.
zero_shot_image_classification: Classify an image into provided candidate labels using vision model.
object_detection: Detect and describe objects in an image using multimodal model.
image_classification: Classify and describe contents of an image using multimodal model.
text_classification: Analyze text for sentiment and category.
token_classification: Perform named entity recognition (NER) on text.
fill_mask: Fill masked tokens in text with appropriate words.
To test the server locally, run the pytest test suite:
# Install test dependencies
uv sync --extra test
# Run all tests
pytest
# Run with verbose output
pytest -v
# Run specific test file
pytest tests/test_tools.py
# Use the convenience script
./run_tests.shThe tests include:
Server initialization and tool listing
Individual tool functionality tests via JSON-RPC protocol
All tests run synchronously without async/await complexity
uvx is designed for running published Python packages from PyPI or GitHub. For local development, use the uv run command as described above.
If you publish this package to PyPI (e.g., as mcp-deepinfra), you can run it with:
uvx mcp-deepinfraAnd configure your MCP client to use:
{
"mcpServers": {
"deepinfra": {
"command": "uvx",
"args": ["mcp-deepinfra"],
"env": {
"DEEPINFRA_API_KEY": "your_api_key_here"
}
}
}
}For local development, stick with the uv run approach.
Generate embeddings for a list of texts using DeepInfra OpenAI-compatible API.
| Name | Required | Description | Default |
|---|---|---|---|
| inputs | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the API provider but lacks details on rate limits, authentication needs, error handling, or output format. For a tool that likely involves external API calls, this is a significant gap in 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 a single, efficient sentence that directly states the tool's purpose without unnecessary words. It is front-loaded with the core action and resource, making it easy to understand quickly. Every part of the sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (external API call), no annotations, and an output schema exists, the description is moderately complete. It covers the basic purpose but lacks behavioral details like rate limits or error handling. The output schema likely handles return values, so the description doesn't need to explain those, but it should provide more context for safe usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, so the description must compensate. It adds meaning by specifying that inputs are 'a list of texts' and mentions the API, but doesn't detail constraints like text length limits or supported languages. With 1 parameter, the baseline is 4, but the description only partially compensates for the lack of schema details, resulting in a moderate score.
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 action ('Generate embeddings') and the resource ('for a list of texts'), specifying the API provider ('DeepInfra OpenAI-compatible API'). It distinguishes from siblings like text_generation or text_classification by focusing on embeddings. However, it doesn't explicitly differentiate from all siblings, such as token_classification, which might also process text.
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 no guidance on when to use this tool versus alternatives. It doesn't mention use cases like semantic search or text similarity, nor does it compare to other text-processing siblings like text_generation or text_classification. There are no explicit when-to-use or when-not-to-use instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fill masked tokens in text using DeepInfra OpenAI-compatible API.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While it mentions the API being used, it doesn't describe what 'filling masked tokens' actually does operationally, what the typical output looks like, whether there are rate limits, authentication requirements, or any side effects. The description is too minimal for a tool that presumably performs text transformation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise - a single sentence that directly states the tool's function and the API used. There's zero wasted language, and it's appropriately sized for what it communicates.
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 that there's an output schema (which handles return values), the description doesn't need to explain outputs. However, for a text transformation tool with no annotations and minimal parameter documentation, the description should provide more context about what 'masked tokens' are and typical use cases. It's minimally adequate but leaves significant gaps in understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no information about the single parameter 'text' beyond what's in the schema (which has 0% description coverage). However, with only one parameter and no schema descriptions, the baseline is 3 since the description doesn't add any parameter-specific details but also doesn't need to compensate for multiple undocumented parameters.
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 the tool 'fills masked tokens in text' which gives a general purpose, but it's vague about what 'masked tokens' are and doesn't specify the exact resource or mechanism. It mentions using the 'DeepInfra OpenAI-compatible API' which provides some context, but doesn't clearly distinguish this from sibling tools like text_generation or text_classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance is provided on when to use this tool versus alternatives. The description doesn't mention any specific scenarios, prerequisites, or exclusions. With multiple sibling text-processing tools available, the lack of differentiation leaves the agent without clear usage criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate an image from a text prompt using DeepInfra OpenAI-compatible API.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | 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 of behavioral disclosure. It mentions the API source but lacks details on rate limits, authentication needs, output format, quality constraints, or error handling. For a tool that likely involves external API calls and image generation, this is a significant gap in 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 a single, efficient sentence that front-loads the core functionality ('Generate an image from a text prompt') and adds necessary context ('using DeepInfra OpenAI-compatible API'). There is no wasted text, 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 tool's complexity (image generation via external API), no annotations, and an output schema that likely handles return values, the description is minimally complete. It covers the basic purpose but lacks usage guidelines, behavioral details, and parameter semantics, leaving gaps that could hinder effective tool selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds minimal meaning beyond the input schema, which has 0% coverage. It implies the 'prompt' parameter is a text input for image generation but doesn't elaborate on format, length, or content guidelines. With one parameter and low schema coverage, the description partially compensates but leaves key details unspecified, aligning with the baseline for moderate coverage.
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 action ('Generate an image') and the resource ('from a text prompt'), specifying the API source ('DeepInfra OpenAI-compatible API'). It distinguishes from siblings like text_generation or image_classification by focusing on image creation rather than text processing or analysis. However, it doesn't explicitly contrast with all siblings, such as zero_shot_image_classification, which also involves images.
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 no guidance on when to use this tool versus alternatives. It doesn't mention scenarios like creative image generation, limitations compared to other tools, or prerequisites. For example, it doesn't clarify if this is for artistic prompts versus technical diagrams, or how it differs from text_generation for visual content.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify an image using DeepInfra OpenAI-compatible API with multimodal model.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the API provider (DeepInfra) and model type (multimodal), but fails to describe critical behaviors such as rate limits, authentication needs, error handling, or what the classification output entails. For a tool with no annotations, this is insufficient.
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, efficient sentence that directly states the tool's function and implementation. It avoids unnecessary words and is front-loaded with the core purpose. However, it could be slightly more structured by separating purpose from technical details.
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 (image classification with an external API), no annotations, and an output schema (which reduces the need to describe return values), the description is minimally adequate. It covers the basic purpose and API context but lacks details on usage, parameters, and behavioral traits, making it incomplete for effective agent use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, meaning the schema provides no semantic details. The description doesn't add any parameter-specific information beyond implying an image is needed. It doesn't explain what 'image_url' should contain (e.g., format, size limits) or how it's used, leaving a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Classify an image' specifies the verb and resource, and 'using DeepInfra OpenAI-compatible API with multimodal model' adds implementation context. However, it doesn't explicitly distinguish this tool from sibling tools like 'zero_shot_image_classification' or 'object_detection', which prevents a score of 5.
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 no guidance on when to use this tool versus alternatives. It doesn't mention when to choose this over 'zero_shot_image_classification' or 'object_detection', nor does it specify prerequisites or exclusions. This lack of usage context leaves the agent without direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Detect objects in an image using DeepInfra OpenAI-compatible API with multimodal model.
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | 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 of behavioral disclosure. It mentions the API provider and model type, but fails to disclose critical behavioral traits such as rate limits, authentication requirements, error handling, or what the output contains (though an output schema exists). For a tool with no annotation coverage, this leaves significant gaps in understanding how the tool behaves operationally.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise and front-loaded, consisting of a single sentence that directly states the tool's purpose and context. Every word earns its place, with no redundant information or fluff. It efficiently communicates the core functionality without unnecessary elaboration.
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 moderate complexity (object detection via an external API), no annotations, and the presence of an output schema, the description is minimally complete. It identifies the tool's purpose and API context but lacks details on behavioral constraints, error cases, or usage nuances. The output schema mitigates the need to describe return values, but other gaps remain, making it adequate but with clear room for improvement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description adds no parameter-specific information beyond what the input schema provides. With 0% schema description coverage and only one parameter ('image_url'), the schema alone defines the parameter. The description doesn't explain what format the image URL should be in, supported protocols, or size limitations. Since schema coverage is low, the description fails to compensate, resulting in a baseline score of 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: 'Detect objects in an image' specifies the verb and resource. It distinguishes from siblings like 'image_classification' or 'zero_shot_image_classification' by focusing on object detection rather than classification. However, it doesn't explicitly differentiate from other potential object detection tools, keeping it at a 4 rather than a 5.
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 minimal usage guidance. It mentions the API provider (DeepInfra OpenAI-compatible API) and that it uses a multimodal model, but offers no explicit guidance on when to use this tool versus alternatives like 'image_classification' or 'zero_shot_image_classification'. There's no mention of prerequisites, limitations, or specific scenarios where object detection is preferred over classification.
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 using DeepInfra OpenAI-compatible API (Whisper).
| Name | Required | Description | Default |
|---|---|---|---|
| audio_url | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the function (transcription) but lacks details on performance traits such as accuracy, latency, rate limits, authentication requirements, or error handling. This leaves gaps in understanding how the tool behaves in practice.
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, efficient sentence that directly states the tool's purpose and technology. It is front-loaded with no unnecessary words, making it easy to parse quickly. Every part of the sentence contributes essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (audio transcription with one parameter) and the presence of an output schema (which likely covers return values), the description is minimally adequate. However, it lacks context on usage scenarios, behavioral details, and parameter specifics, leaving room for improvement in completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 1 parameter with 0% description coverage, so the description must compensate. It implies the parameter is an audio URL but doesn't specify format requirements (e.g., supported audio types, size limits) or provide examples. The description adds minimal value beyond the schema's title ('Audio Url'), resulting in a baseline score.
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 ('Transcribe') and resource ('audio to text'), specifying the action and target. It also identifies the technology used ('DeepInfra OpenAI-compatible API (Whisper)'), which helps distinguish it from generic transcription tools. However, it doesn't explicitly differentiate from sibling tools like 'text_generation' or 'text_classification', which operate on text rather than audio.
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 no guidance on when to use this tool versus alternatives. It mentions the API and model (Whisper) but doesn't specify use cases, prerequisites, or exclusions. For example, it doesn't indicate if it's for real-time or batch processing, or if there are limitations on audio formats or lengths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify text using DeepInfra OpenAI-compatible API.
| Name | Required | Description | Default |
|---|---|---|---|
| text | 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 of behavioral disclosure. It mentions the API provider (DeepInfra) but doesn't describe traits like rate limits, authentication needs, output format, or error handling. This leaves significant gaps for a tool that interacts with an external service.
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, efficient sentence with zero waste. It's front-loaded with the core action and resource, making it easy to parse quickly.
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 (external API call), no annotations, and an output schema present, the description is minimally adequate. It identifies the API but lacks details on behavior, parameters, or usage context, making it incomplete for safe and effective tool invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage, but the description adds no parameter semantics beyond implying 'text' is the input. It doesn't explain what types of text are suitable, length constraints, or expected formats, so it doesn't compensate for the schema's lack of documentation.
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 'Classify' and the resource 'text', specifying it uses the DeepInfra OpenAI-compatible API. However, it doesn't differentiate from sibling tools like 'zero_shot_image_classification' or 'token_classification', which might also involve classification tasks but for different data types or methods.
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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'text_generation' or 'embeddings', nor does it specify use cases, prerequisites, or exclusions for text classification.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate text completion using DeepInfra OpenAI-compatible API.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It mentions the API (DeepInfra OpenAI-compatible) but lacks details on behavioral traits such as rate limits, costs, response format, or potential side effects (e.g., if it's a read-only or mutating operation). The description is minimal and doesn't compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero waste. It front-loads the core action ('Generate text completion') and includes essential context ('using DeepInfra OpenAI-compatible API') without unnecessary elaboration, 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 tool's moderate complexity (text generation with one parameter) and the presence of an output schema (which likely handles return values), the description is minimally complete. However, without annotations and with low schema coverage, it lacks details on usage context, behavioral traits, and parameter guidance, leaving clear gaps for an AI agent to understand full tool behavior.
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 implies the 'prompt' parameter is used for text generation but doesn't add meaning beyond the schema's basic title. No details on prompt formatting, length limits, or examples are provided. With one parameter and low coverage, the description adds minimal value, meeting the baseline for adequate but incomplete documentation.
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 action ('Generate text completion') and the resource/API ('using DeepInfra OpenAI-compatible API'), making the purpose understandable. It distinguishes from siblings like embeddings or image generation by focusing on text completion. However, it doesn't specify what type of text completion (e.g., chat, continuation, instruction-following) or differentiate from potential text-based siblings like text_classification.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. The description mentions the API type but doesn't explain scenarios where text generation is appropriate compared to other text tools like text_classification or fill_mask, or when to choose this over other generation tools like generate_image.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Perform token classification (NER) using DeepInfra OpenAI-compatible API.
| Name | Required | Description | Default |
|---|---|---|---|
| text | 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 of behavioral disclosure. It states the action and API but lacks details on rate limits, authentication needs, error handling, or what the tool returns. For a tool with no annotations and an output schema, this leaves significant gaps in understanding its 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, efficient sentence with no wasted words. It front-loads the core purpose and includes relevant API context, making it appropriately sized and well-structured for quick comprehension.
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 moderate complexity (NER task with one parameter) and the presence of an output schema, the description is minimally complete. It covers the basic purpose and API but lacks usage guidelines, behavioral details, and parameter semantics, leaving the agent reliant on the output schema for return values.
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 implies the 'text' parameter is for input to the NER model but doesn't elaborate on format, length constraints, or language requirements. The description adds minimal value beyond what the schema's title ('Text') suggests, resulting in an adequate but incomplete parameter understanding.
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 action ('Perform token classification (NER)') and specifies the resource ('using DeepInfra OpenAI-compatible API'), which distinguishes it from siblings like text_classification or text_generation. However, it doesn't explicitly differentiate token classification from other NLP tasks in the sibling list beyond the NER acronym.
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 no guidance on when to use this tool versus alternatives like text_classification or other siblings. It mentions the API but doesn't specify use cases, prerequisites, or exclusions, leaving the agent to infer usage from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Classify an image with zero-shot labels using DeepInfra OpenAI-compatible API (CLIP).
| Name | Required | Description | Default |
|---|---|---|---|
| image_url | Yes | ||
| candidate_labels | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
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 mentions the API (DeepInfra OpenAI-compatible) and model (CLIP), but lacks details on behavioral traits such as rate limits, authentication needs, error handling, or what the output looks like (though an output schema exists). For a tool with no annotations, this is a significant gap in 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 a single, efficient sentence that front-loads the core purpose ('Classify an image with zero-shot labels') and adds necessary context ('using DeepInfra OpenAI-compatible API (CLIP)'). There is no wasted text, and it's appropriately sized 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 tool has an output schema (which covers return values) and no annotations, the description is minimal but covers the basic purpose. However, for a classification tool with 2 parameters and no annotation coverage, it lacks details on usage context, parameter semantics, and behavioral aspects, making it incomplete for optimal agent understanding.
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 schema provides no parameter descriptions. The description doesn't add any meaning to the parameters 'image_url' and 'candidate_labels' beyond what their names imply. It mentions 'zero-shot labels' which relates to 'candidate_labels', but doesn't explain format, constraints, or examples. Baseline is 3 due to low coverage, but the description doesn't fully 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 clearly states the action ('Classify an image') and the resource ('image'), with the specific method 'zero-shot labels using DeepInfra OpenAI-compatible API (CLIP)'. It distinguishes from siblings like 'image_classification' by specifying the zero-shot approach, though it doesn't explicitly contrast with other image-related tools like 'object_detection' or 'generate_image'.
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 for zero-shot classification with CLIP, suggesting it's for when you have candidate labels but no pre-trained model. However, it doesn't explicitly state when to use this versus alternatives like 'image_classification' (which might be supervised) or other siblings, nor does it mention prerequisites or exclusions.
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.
v1.0.0embeddings2 fields changedInput schema / properties / modelRemoved value: -{
- "default": null,
- "title": "Model",
- "type": "string"
-}Input schema / titleAdded value: +"embeddingsArguments"fill_mask2 fields changedInput schema / properties / modelRemoved value: -{
- "default": null,
- "title": "Model",
- "type": "string"
-}Input schema / titleAdded value: +"fill_maskArguments"generate_image2 fields changedInput schema / properties / modelRemoved value: -{
- "default": null,
- "title": "Model",
- "type": "string"
-}Input schema / titleAdded value: +"generate_imageArguments"image_classification2 fields changedInput schema / properties / modelRemoved value: -{
- "default": null,
- "title": "Model",
- "type": "string"
-}Input schema / titleAdded value: +"image_classificationArguments"object_detection2 fields changedInput schema / properties / modelRemoved value: -{
- "default": null,
- "title": "Model",
- "type": "string"
-}Input schema / titleAdded value: +"object_detectionArguments"speech_recognition2 fields changedInput schema / properties / modelRemoved value: -{
- "default": null,
- "title": "Model",
- "type": "string"
-}Input schema / titleAdded value: +"speech_recognitionArguments"text_classification2 fields changedInput schema / properties / modelRemoved value: -{
- "default": null,
- "title": "Model",
- "type": "string"
-}Input schema / titleAdded value: +"text_classificationArguments"text_generation2 fields changedInput schema / properties / modelRemoved value: -{
- "default": null,
- "title": "Model",
- "type": "string"
-}Input schema / titleAdded value: +"text_generationArguments"token_classification2 fields changedInput schema / properties / modelRemoved value: -{
- "default": null,
- "title": "Model",
- "type": "string"
-}Input schema / titleAdded value: +"token_classificationArguments"zero_shot_image_classification2 fields changedInput schema / properties / modelRemoved value: -{
- "default": null,
- "title": "Model",
- "type": "string"
-}Input schema / titleAdded value: +"zero_shot_image_classificationArguments"embeddingsfill_maskgenerate_imageimage_classificationobject_detectionspeech_recognitiontext_classificationtext_generationtoken_classificationzero_shot_image_classificationScored across 10 tools
Each tool has a clearly distinct purpose targeting different AI tasks (embeddings, text generation, image generation, classification, etc.). No ambiguity exists as tools are specialized for specific operations like speech recognition vs. text classification, with clear boundaries between them.
All tool names follow a consistent snake_case pattern with descriptive verb_noun or noun_verb structures (e.g., generate_image, text_classification). The naming is uniform across all tools, making them easily predictable and readable.
With 10 tools, the count is well-scoped for an AI tools server covering diverse tasks like text, image, and audio processing. Each tool earns its place by addressing a specific AI function without redundancy or bloat.
The tool set provides comprehensive coverage for common AI tasks (text, image, audio) with clear operations like generation, classification, and detection. Minor gaps might include more advanced or niche AI functions, but core workflows are well-covered for the domain.
Image, video, music and text generation across 100+ models through one endpoint.
One API for 100+ AI video, image, music and speech models.
35 AI tools for image/video generation, TTS, transcription, OCR & embeddings via deAPI
Generate images, video, music, voice and 3D through one API. 30 tools, 200+ models.
