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., "@Venice MCP Server generate an image of a sunset over mountains"
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.
A Model Context Protocol (MCP) server for Venice AI. Gives AI assistants like Claude access to Venice's text generation, image creation, text-to-speech, embeddings, and account management APIs.
This MCP server lets Claude (or any MCP-compatible assistant) use Venice AI's features directly:
Chat with Llama, DeepSeek, Qwen, and other open models
Generate images using Stable Diffusion, FLUX, and more
Create speech from text with natural-sounding voices
Generate embeddings for search and RAG applications
Manage API keys and monitor rate limits
Related MCP server: sora-mcp-server
Sign up at venice.ai and create an API key in Settings → API.
npm install -g venice-mcpAdd to your config file:
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json
Linux: ~/.config/Claude/claude_desktop_config.json
{
"mcpServers": {
"venice": {
"command": "npx",
"args": ["-y", "venice-mcp"],
"env": {
"VENICE_API_KEY": "your-api-key-here"
}
}
}
}Restart Claude Desktop. You'll see Venice tools available in the 🔧 menu.
Tool | Description |
| Chat with Venice AI language models |
| Generate images from text descriptions |
| Upscale and enhance images |
| Convert text to spoken audio |
| Generate text embeddings |
Tool | Description |
| List available models (text, image, code) |
| List character personas |
Requires an admin-level API key:
Tool | Description |
| List all API keys |
| Create a new API key |
| Get details for a key |
| Delete an API key |
| View rate limits and usage |
| View rate limit history |
Ask Claude to generate an image:
"Use Venice to create an image of a sunset over mountains"
Chat with a specific model:
"Ask Venice's DeepSeek model to explain quantum computing"
Check your usage:
"Show my Venice API rate limits"
Language Models: Llama 3.3 70B, DeepSeek R1, Qwen 3, Mistral, and more
Image Models: Stable Diffusion 3.5, FLUX, Fluently XL
Embeddings: BGE-M3 (1024 dimensions)
TTS: Kokoro with multiple voice options
Run venice_list_models to see all currently available models.
Node.js 18+
Venice AI API key
git clone https://github.com/georgeglarson/venice-mcp.git
cd venice-mcp
npm install
npm run buildnpm test # Run tests
npm run test:watch # Watch mode
npm run test:coverage # Coverage reportContributions are welcome! Please see CONTRIBUTING.md for guidelines.
Venice AI - Platform home
Venice API Docs - API reference
MCP Documentation - Protocol spec
MIT - see LICENSE
Send a message to Venice AI and get a response from an LLM
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | Model ID (e.g., llama-3.3-70b, deepseek-r1-llama-70b) | llama-3.3-70b |
| message | Yes | The user message to send | |
| max_tokens | No | Maximum tokens to generate | |
| temperature | No | Sampling temperature (0-2) | |
| system_prompt | No | Optional system prompt |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states basic functionality without disclosing behavioral traits such as statelessness, rate limits, or side effects.
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 with no superfluous words, but it could be structured to include more helpful context.
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 (5 parameters, no output schema), the description is minimally adequate but lacks explanation of overall behavior, such as the stateless nature of requests.
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 schema already documents parameters. The description adds no additional meaning beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'send a message' and resource 'Venice AI get a response from an LLM', which is distinct from sibling tools like image generation or text-to-speech.
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, nor any context about 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.
Create a new API key
| Name | Required | Description | Default |
|---|---|---|---|
| expiresAt | No | Optional expiration date (ISO 8601 format) | |
| apiKeyType | No | API key type (ADMIN or INFERENCE) | INFERENCE |
| description | Yes | Description for the new API key | |
| consumptionLimit | No | Optional consumption limits |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, and the description does not disclose behavioral traits such as permissions, reversibility, rate limits, or side effects.
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 very short but lacks necessary detail. It is concise but not effectively structured to aid selection or invocation.
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 4 parameters including a nested object and no output schema, the description is minimally complete—it does not explain usage context or return value.
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?
Although schema coverage is 100%, the description adds no additional meaning to the parameters—it does not mention the required description parameter or clarify optional ones like consumption limits.
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 'Create a new API key' is clear, specific, and distinguishes from sibling tools like delete or list API keys.
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, nor any prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate text embeddings for semantic search and RAG
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | Text or array of texts to embed | |
| model | No | Embedding model | text-embedding-ada-002 |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It only states 'generate', implying a non-destructive operation, but omits details like output format, rate limits, or side effects.
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 sentence of 7 words, which is concise but lacks important information like usage context and behavioral details. It is functional but too brief for optimal clarity.
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 absence of an output schema and annotations, the description does not explain return values, constraints, or any additional context needed for proper use. It is incomplete for a tool with two parameters and no other structured documentation.
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%, with clear descriptions for both 'input' and 'model'. The description adds no extra meaning beyond the schema, so 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 text embeddings and specifies the use cases (semantic search and RAG). It uniquely identifies the tool among siblings, which include chat, image generation, and API key management.
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, nor does it mention any prerequisites or exclusions. Agents receive no help in deciding between this and sibling tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delete an API key
| Name | Required | Description | Default |
|---|---|---|---|
| key_id | Yes | The API key ID to delete |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It only says 'Delete' with no mention of whether deletion is irrevocable, permission requirements, or side effects like cascading to associated sub-resources.
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?
Extremely concise: one short sentence. No filler, but arguably too minimal. Efficient but front-loads the action.
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 deletion with a single parameter, the description covers the basic function. However, it lacks information about success/failure responses or error conditions, which would improve 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?
Schema coverage is 100% and the schema already describes the parameter as 'The API key ID to delete'. The description adds no additional meaning beyond that. 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 action (Delete) and the resource (an API key), distinguishing it from sibling tools like create, list, and retrieve. It is specific but lacks detail on whether deletion is permanent or immediate.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool vs alternatives (e.g., when to delete versus deactivate). No prerequisites or context provided.
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 Venice AI
| Name | Required | Description | Default |
|---|---|---|---|
| size | No | Image size (e.g., 512x512, 1024x1024, 1792x1024) | 1024x1024 |
| model | No | Image model (e.g., fluently-xl, flux-dev) | fluently-xl |
| prompt | Yes | Text description of the image to generate | |
| style_preset | No | Style preset name | |
| negative_prompt | No | What to avoid in the image |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only says 'generate an image' without disclosing processing time, rate limits, cost, or safety considerations. Very minimal.
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?
Single sentence is concise but borderline under-specified. For a tool with 5 parameters, more detail could be helpful without being verbose.
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 5 parameters, no output schema, and no annotations, the description is incomplete. It does not explain return value, error handling, or prerequisites.
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 schema already documents all parameters. The description adds no extra meaning beyond what's in the schema, earning a baseline 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 it generates an image from a text prompt using Venice AI, with a specific verb and resource. It distinguishes from sibling tools like venice_chat and venice_upscale_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?
No guidance on when to use this tool versus alternatives (e.g., upscaling, chatting). No mention of prerequisites or conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get rate limit usage history logs
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description should disclose behavioral traits like read-only or authentication needs. It merely restates the name without any operational details, such as whether logs are private or cumulative.
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 clear sentence with no unnecessary words. It is efficient but could be slightly expanded to include a brief note on usage context without losing conciseness.
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 lack of annotations, output schema, and parameters, the description provides minimal context. It does not explain what the logs contain (e.g., timestamps, limits) or typical scenarios, leaving the agent with incomplete information for correct 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 tool has zero parameters and the schema coverage is 100%, so the description does not need to add parameter details. The baseline for no parameters is 4, which is appropriate since no additional meaning is required.
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 ('Get') and the resource ('rate limit usage history logs'), making the tool's purpose unambiguous. It differs from sibling venice_get_rate_limits, which deals with current limits, by focusing on historical logs.
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 like venice_get_rate_limits. There are no prerequisites, context, or exclusion criteria mentioned, leaving the agent without decision support.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get current rate limits, usage, and account information
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description implies a read-only operation with 'Get', but does not explicitly confirm no side effects or disclose any behavioral traits such as authentication requirements or rate limit frequency. With no annotations, more transparency would be ideal.
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, clear sentence with no unnecessary words. Efficiently communicates the tool's 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 zero-parameter tool with no output schema, the description adequately covers the functionality. It does not elaborate on return values, but output schema is missing and not required by the rubric.
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?
There are zero parameters, so per the rubric baseline is 4. The description adds no parameter details, but no parameters exist, so it's acceptable.
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 ('Get') and the resources ('rate limits, usage, and account information'), providing specific and distinct purpose from sibling tools like venice_chat or venice_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?
No explicit guidelines on when to use this tool versus alternatives. While it's a straightforward getter, the description does not mention best practices like checking limits before requests, but it's minimally acceptable given the tool's simplicity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all API keys on the account (requires admin API key)
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It mentions the admin API key requirement, which is important, but lacks details on side effects (read-only implied), pagination, or rate limits.
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 effectively conveys the tool's purpose and a key constraint. No unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with no output schema, the description is mostly complete, covering purpose and an important prerequisite. However, it omits details about the output format or any limits.
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?
There are zero parameters, so baseline is 4. The description does not need to add parameter semantics beyond the schema, which is sufficiently empty.
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 'List all API keys on the account', using a specific verb and resource. It also distinguishes from sibling tools like create, delete, and retrieve by name and action.
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 with 'requires admin API key' but does not explicitly state when to use this tool versus alternatives (e.g., retrieve vs list). No when-not or exclusion guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Venice AI character personas for roleplay
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of characters to return (default: 20) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavior. It only states 'List available' without clarifying pagination, auth requirements, rate limits, or handling of the optional limit parameter. This leaves behavioral gaps.
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 conveys the tool's purpose. No extraneous words, and the key action is front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional parameter, no output schema), the description adequately covers the core functionality. However, it could mention the default limit or result format. The sibling context provides enough differentiation.
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 a single parameter 'limit' well-described in the schema. The description adds no additional meaning beyond the schema, meeting the 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 specifies the verb 'List', the resource 'Venice AI character personas', and the context 'for roleplay'. It clearly distinguishes from sibling tools like venice_chat (chat initiation) and venice_list_models (AI models).
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 roleplay preparation but lacks explicit guidance on when to use this tool versus alternatives (e.g., venice_chat) or when not to use it. No exclusion criteria or context are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List available Venice AI models by type
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | Filter by model type (text, image, embedding, tts, asr, upscale, inpaint, video, or all) | all |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It only mentions listing by type, with no disclosure of behavioral traits like authentication requirements, output format, pagination, or potential errors. This is minimal for a tool with no 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, front-loaded sentence that efficiently conveys the tool's core function without unnecessary words. Every word is purposeful.
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 a simple one-parameter tool with full schema coverage, the description is adequate for a basic understanding. However, the lack of output schema or any behavioral annotations leaves gaps in what the agent can expect regarding return format or usage constraints.
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 already describes the 'type' parameter fully (enum with default 'all'), achieving 100% schema description coverage. The description adds no additional meaning beyond the schema, so 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 explicitly states 'List available Venice AI models by type', which clearly identifies the action (list), the resource (available models), and the main filtering dimension (by type). This distinguishes it from sibling tools like venice_chat or venice_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?
No guidance is provided on when to use this tool versus alternatives, such as when a broader list versus filtered list is needed, or what to do if no models are returned. The description lacks explicit context for when to choose this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details for a specific API key
| Name | Required | Description | Default |
|---|---|---|---|
| key_id | Yes | The API key ID to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided; the description does not disclose behavioral traits such as read-only nature, idempotency, or authentication requirements beyond the implied retrieval action.
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 phrase with no wasted words, appropriately sized for the tool's simplicity.
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 one parameter, no output schema, and no annotations, the description is too brief; it does not explain what 'details' includes, response format, or error conditions.
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 description repeats the schema's parameter description without adding further meaning, earning 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 uses the specific verb 'Get' and resource 'details for a specific API key', clearly distinguishing it from sibling tools like list, create, and delete.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus alternatives; no exclusions or prerequisites mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert text to speech audio using Venice AI
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to convert to speech | |
| model | No | TTS model | tts-kokoro |
| voice | No | Voice ID (e.g., af_sky, af_bella, am_adam) | af_sky |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations exist, so the description bears full responsibility. It only states the basic function without disclosing audio format, length limits, language support, or any side effects. This is insufficient for an agent to understand behaviors.
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, well-structured for quick reading. However, it could be slightly expanded to include more context without losing conciseness, hence a 4.
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 parameters, no output schema), the description covers the main function but misses important details like output media type, typical use cases, or any limitations. It is minimally viable but not comprehensive.
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 baseline is 3. The description adds no additional meaning beyond what the schema already provides for each parameter. It does not clarify default behavior, value constraints, or output format.
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 'Convert text to speech audio using Venice AI', which directly specifies the action (convert), the input (text), and the output (speech audio). It distinguishes itself from sibling tools like venice_chat or venice_generate_image, which serve 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?
No guidance is provided on when to use this tool vs alternatives (e.g., venice_chat for text responses). There is no mention of context, prerequisites, or use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Upscale an image using Venice AI
| Name | Required | Description | Default |
|---|---|---|---|
| image | Yes | Base64-encoded image data or URL | |
| scale | No | Upscale factor (2, 4, etc.) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must convey behavioral traits. It only states the general purpose without describing side effects, authorization requirements, rate limits, or output characteristics. The agent cannot determine if the operation is destructive or idempotent.
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, but it lacks critical details that would make it informative for an AI agent. It is not necessarily wasteful, but it sacrifices completeness for brevity.
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 (2 parameters) and lack of output schema or annotations, the description should provide more context about expected output, file size limits, supported formats, or error handling. The current description is insufficient for complete 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 input schema already provides descriptions for both parameters (image type and scale factor) with 100% coverage. The description adds no additional semantic information beyond what the schema offers, so 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 action (upscale) and the resource (an image) using a specific provider (Venice AI). It effectively distinguishes from the sibling tool 'venice_generate_image', which creates new images rather than processing existing ones.
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 like 'venice_generate_image' or the other sibling tools. There is no mention of prerequisites, limitations, or scenarios where this tool is appropriate or not.
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.2.4venice_chatvenice_create_api_keyvenice_create_embeddingsvenice_delete_api_keyvenice_generate_imagevenice_get_rate_limit_logsvenice_get_rate_limitsvenice_list_api_keysvenice_list_charactersvenice_list_modelsvenice_retrieve_api_keyvenice_text_to_speechvenice_upscale_imagev1.2.1venice_chatvenice_create_api_keyvenice_create_embeddingsvenice_delete_api_keyvenice_generate_imagevenice_get_rate_limit_logsvenice_get_rate_limitsvenice_list_api_keysvenice_list_charactersvenice_list_modelsvenice_retrieve_api_keyvenice_text_to_speechvenice_upscale_imagev1.1.2venice_chatvenice_create_api_keyvenice_create_embeddingsvenice_delete_api_keyvenice_generate_imagevenice_get_rate_limit_logsvenice_get_rate_limitsvenice_list_api_keysvenice_list_charactersvenice_list_modelsvenice_retrieve_api_keyvenice_text_to_speechvenice_upscale_imagevenice_chatvenice_create_api_keyvenice_create_embeddingsvenice_delete_api_keyvenice_generate_imagevenice_get_rate_limit_logsvenice_get_rate_limitsvenice_list_api_keysvenice_list_charactersvenice_list_modelsvenice_retrieve_api_keyvenice_text_to_speechvenice_upscale_imageScored across 13 tools
Each tool has a unique purpose (chat, API key CRUD, embeddings, image generation, TTS, etc.) with no overlap, making it easy for an agent to select the correct tool.
All tools follow a consistent 'venice_verb_noun' pattern (e.g., venice_create_api_key, venice_list_models), which is predictable and clear.
13 tools covering chat, image, embeddings, TTS, API key management, and monitoring is well-scoped for an AI API server without being excessive.
Core functionalities are covered (chat, images, embeddings, TTS, API key CRUD minus update, rate limits). Minor gaps like no streaming or API key update do not hinder basic workflows.
Manage ElevenLabs voice agents and generate speech, music, sound effects, images, and video.
Connect your AI assistant to Revensi OS agents, workflows, and business data.
Generate AI images, videos, music, SFX & speech in any AI assistant. Results appear inline in chat.
Carbon Voice MCP serves as a bridge that connects AI assistants like ChatGPT, Claude, and Cursor to a user's Carbon Voice account, turning voice messages and conversations into a private, on-demand knowledge base. It provides 28 specialized tools for comprehensive voice messaging management, including creating and sending messages, accessing conversation history with instant transcription, running AI actions (summarization, TLDR generation, meeting notes), and managing workspace collaboration through folders, contacts, and team communications.
