This server connects any MCP client to Voxell's Forge hosted text-embedding API, enabling you to generate vector embeddings for text.
Available Tools:
embed — Convert one or more texts into vector embeddings for use in:
Semantic search (use input_type: 'query' for queries, input_type: 'document' for indexed content)
Retrieval-Augmented Generation (RAG) pipelines
Finding similar or duplicate text by comparing vectors
Text clustering or classification
Choose from three quality/cost tiers: turbo (1024d, fast default), pro (2560d), or ultra (4096d, highest quality)
Optionally truncate dimensions via Matryoshka (MRL) by setting dim, producing smaller and cheaper vectors
list_models — Retrieve all available Forge embedding models along with their dimensions and default, helping you pick the right model before embedding
Key Characteristics:
Compatible with MCP clients like Claude, Cursor, Cline, Windsurf, and VS Code
Also accessible via an OpenAI-compatible API
Stateless — no text or vectors are stored (only usage/token metadata for billing)
Purely an embedding tool — no built-in vector storage, search index, or RAG orchestration
Free to start with 10M tokens, no credit card required
Compatible with the OpenAI embeddings API, allowing OpenAI clients to use Forge's embedding models with no code changes.
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., "@@voxell/forge-mcp Embed 'How to train a model?' with input_type query."
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.
An MCP server for Forge — Voxell's hosted text-embedding API. It exposes Forge to any MCP client (Claude, Cursor, Cline, Windsurf, VS Code, …) as two tools:
embed — turn text into vectors
list_models — list available models and their dimensions
You bring a Forge API key. The server is stateless, and Voxell does not store the text you send or the vectors it returns — only usage metadata (token counts) is recorded, for billing. It does embeddings only — no storage, no search, no RAG. Those are different products.
One-click install in your editor (then replace your-key-here with a real key from
dash.voxell.ai):
Claude Code — one command:
claude mcp add forge -e FORGE_API_KEY=your-key-here -- npx -y @voxell/forge-mcpAny other client (Claude Desktop, Cline, Windsurf, Zed, …) uses the standard mcpServers
block — see Use it below.
Related MCP server: @restforge-dev/mcp-server
Quality you can dial. Forge runs the Qwen3-Embedding family; ultra is the 8B — ~75+
average task score on MTEB, currently #4 on MTEB (English), and the top usable model (the
three ranked above it are research-only). turbo (0.6B) is the fast/cheap default. Pick your
quality/cost point.
Matryoshka (MRL). Set dim to truncate (re-normalized) for ~4× smaller, cheaper vectors.
Low latency (Go + CUDA engine), zero-trust (per-key auth; mTLS available), and free to start (10M tokens, no card — dash.voxell.ai; more at voxell.ai/forge).
Add semantic search — embed your documents with input_type: "document" and each query
with input_type: "query", then rank by cosine similarity.
Build RAG — embed a knowledge base, store the vectors, and retrieve the closest chunks to ground an LLM.
Find similar or duplicate text — embed two texts and compare their vectors.
Cluster or classify — embed a batch, then cluster or train a classifier on the vectors.
Shrink vector storage — set dim to truncate (Matryoshka) and trade a little accuracy
for smaller, cheaper vectors.
Straight from your editor — ask your AI agent (Cursor, Claude, …) to embed a snippet, a
batch, or a file via the embed tool — no separate script.
Node.js ≥ 18 (tested on 20)
A Forge API key — create one at https://dash.voxell.ai. New accounts start with 10M free tokens, no credit card.
Most MCP clients run it on demand with npx. Add this to your client's MCP config:
{
"mcpServers": {
"forge": {
"command": "npx",
"args": ["-y", "@voxell/forge-mcp"],
"env": { "FORGE_API_KEY": "your-key-here" }
}
}
}(Cursor, Claude Desktop, Cline, Windsurf, and VS Code all use this mcpServers shape.)
embedarg | type | default | notes |
| string or string[] | — | text(s) to embed (required) |
| string |
|
|
| number | model default | truncate to N dimensions (Matryoshka) — works on every model |
|
|
| use |
Returns the vectors plus the model, dimension, and token count.
Default is turbo — the one you probably want. pro/ultra trade size and speed for more
dimensions.
list_modelsLists the available models and their dimensions.
env | required | default |
| yes | — |
| no |
|
Forge speaks the OpenAI embeddings API. Point any OpenAI client at Forge — no code change, and your existing vector dimensions are preserved:
from openai import OpenAI
client = OpenAI(base_url="https://api.voxell.ai/v1", api_key="your-forge-key")
# the exact call you already make — now on a higher-ranked engine:
client.embeddings.create(model="text-embedding-3-large", input=["hello world"]) # -> 3072-dYour OpenAI model names map to a matching-dimension Forge tier (text-embedding-3-small/
ada-002 → 1536-d, text-embedding-3-large → 3072-d), so existing vector stores slot in
unchanged. Or address Forge tiers directly — turbo | pro | ultra. Also supports dimensions
(Matryoshka, re-normalized) and encoding_format: "base64".
It's an upgrade on every path. Forge's smallest tier (turbo, Qwen3-Embedding-0.6B)
outranks OpenAI's largest embedding model (text-embedding-3-large) on MTEB — so there's no
drop-in that lands worse. ultra (Qwen3-Embedding-8B, ~75+ average task score, #4 on MTEB English)
is a different league.
Why re-embedding onto Forge is worth it. Embedding is a one-way door: whatever an encoder discards at write time is gone — no reranker, longer prompt, or bigger LLM downstream reconstructs what the vectors never captured. The model you embed with sets the ceiling on everything above it. Re-embed once onto a higher-ranked engine and that ceiling rises — permanently.
MIT © Voxell, Inc.
Generate vector embeddings for one or more texts with Forge (Voxell's hosted embedding API). Use it to turn text into vectors for semantic search, RAG, clustering, or similarity. Set input_type='query' for search queries and 'document' for content you index. Choose model by quality/cost: turbo (1024d, fast, default) -> pro (2560d) -> ultra (4096d, #4 on MTEB English, top usable). Optionally set dim to truncate (Matryoshka, re-normalized).
| Name | Required | Description | Default |
|---|---|---|---|
| input | Yes | A text, or array of texts, to embed. | |
| model | No | Model by quality/cost: turbo (1024d, fast, default), pro (2560d), ultra (4096d, #4 on MTEB English, top usable). | |
| dim | No | Truncate to N dimensions (Matryoshka, re-normalized) — fewer dims = smaller, cheaper vectors. Omit for the model's native size. | |
| input_type | No | 'query' applies a retrieval prefix; 'document' is raw. Default 'document'. |
| Name | Required | Description |
|---|---|---|
| model | Yes | |
| dim | Yes | |
| count | Yes | |
| tokens | Yes | |
| embeddings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses embedding behavior, model options, dimension truncation (Matryoshka, re-normalized), and input_type prefix. Could mention rate limits or error handling, but adequate for typical use.
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?
Description is a single paragraph, detailed but not overly long. Front-loaded with main action. Could be improved with bullet points for readability, but still concise.
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 presence of output schema (context indicates true), description adequately covers purpose, parameters, and usage. Might miss batch limits, but overall 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 coverage is 100%, but description adds extra meaning: model quality/cost ranking, Matryoshka truncation explanation, and retrieval prefix for input_type. Adds significant value beyond 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 'Generate vector embeddings for one or more texts with Forge', specifies use cases (semantic search, RAG, clustering, similarity), and distinguishes from sibling 'list_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?
Provides clear guidance on when to use (various NLP tasks) and specific instructions for input_type ('query' vs 'document') and model selection with quality/cost trade-offs. Missing explicit when-not-to-use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the available Forge embedding models and their dimensions. Call this to pick a model before embedding.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| models | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavior. It states the tool lists models and dimensions, which is read-only. However, it does not cover authentication, caching, or side effects. For a simple list tool, this is adequate but not richly transparent.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no wasted words. The first sentence states the action, the second provides usage guidance. Ideal 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 tool is simple (no parameters, has output schema), the description is sufficient: it explains what is listed and why to call it. The output schema handles return value details.
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 no parameters, and schema coverage is 100% vacuously. Per guidelines, 0 parameters yields a baseline of 4; no additional parameter information is needed.
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 the tool lists available Forge embedding models and their dimensions, with a clear verb and resource. It also distinguishes from the sibling 'embed' by advising to call this before embedding.
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 a clear usage context: 'Call this to pick a model before embedding.' This implicitly directs away from the sibling 'embed' tool. However, it does not explicitly state when not to use it or alternative scenarios.
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.
v0.1.5embed2 fields changedInput schema / properties / dim / descriptionPrevious value: -"Truncate vectors to this dimension (Matryoshka); omit for model default."New value: +"Truncate to N dimensions (Matryoshka, re-normalized) — fewer dims = smaller, cheaper vectors. Omit for the model's native size."Input schema / properties / model / descriptionPrevious value: -"Model: turbo (1024d, default), pro (2560d), or ultra (4096d)."New value: +"Model by quality/cost: turbo (1024d, fast, default), pro (2560d), ultra (4096d, #4 on MTEB English, top usable)."v0.1.0embedlist_modelsScored across 2 tools
The two tools have entirely distinct purposes: embedding text and listing models. There is no overlap or ambiguity.
While 'embed' is a single verb and 'list_models' follows verb_noun pattern, the naming is still clear and predictable. Minor inconsistency but not confusing.
With only 2 tools, the server feels minimal. However, for a focused embedding API, this may be sufficient. It is borderline but not extreme.
The tool set covers the core operations for an embedding service: generating embeddings and listing available models. No obvious gaps for the stated purpose.
MCP server for Flux AI image generation
MCP server for AI dialogue using various LLM models via AceDataCloud
