Embed text into vectors and list available Forge models via MCP for semantic search, RAG, and related tasks.
Generate embeddings for one or more texts with the embed tool.
Choose model tier: turbo (1024d, default), pro (2560d), or ultra (4096d).
Set input_type to query for search queries or document for indexed content.
Optionally truncate vectors via dim (Matryoshka) to shrink storage and cost.
Get back the vectors plus model, dimension, and token count.
List available models and their dimensions with list_models.
Use for semantic search, RAG, finding similar/duplicate text, clustering/classification, and vector storage optimization.
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. Three tiers: turbo (1024d, fast, the default), pro (2560d) and
ultra (4096d, highest quality). Pick your point on the quality and cost curve.
Benchmark-leading. Voxell's Ingot-8B-R3 ranks #1 for English on the public MTEB leaderboard (English v2), with a 75.98 mean task score across 41 tasks: the top usable English embedding model. See the model card.
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 (turbo is free forever, 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) outranks OpenAI's
largest embedding model (text-embedding-3-large) on MTEB, so there's no drop-in that lands
worse. And Voxell's Ingot-8B-R3 ranks #1 for English on the public MTEB leaderboard: 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, highest quality). Optionally set dim to truncate (Matryoshka, re-normalized).
| Name | Required | Description | Default |
|---|---|---|---|
| dim | No | Truncate to N dimensions (Matryoshka, re-normalized) — fewer dims = smaller, cheaper vectors. Omit for the model's native size. | |
| input | Yes | A text, or array of texts, to embed. | |
| model | No | Model by quality/cost: turbo (1024d, fast, default), pro (2560d), ultra (4096d, highest quality). | |
| input_type | No | 'query' applies a retrieval prefix; 'document' is raw. Default 'document'. |
| Name | Required | Description |
|---|---|---|
| dim | Yes | |
| count | Yes | |
| model | Yes | |
| tokens | Yes | |
| embeddings | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden and largely meets it: it discloses defaults (turbo), native dimensions per model, the truncation behavior and that truncation is Matryoshka re-normalized, and the query-prefix behavior of input_type. It does not cover auth, rate limits, batch size limits for array input, or vector normalization of untruncated output, leaving some 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?
Information-dense and front-loaded: purpose first, then routing guidance, then model selection, then the optional truncation. No filler sentences, though the model-tier list duplicates schema content and could be trimmed.
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?
An output schema exists, so return values need not be explained, and the description covers model choice, input_type routing, and dim truncation adequately. Missing only edge-case behavior such as array/batch limits or error conditions for a tool with array input.
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 four parameters, including model tiers and dim truncation. The description's restatement of model dimensions and the quality/cost ordering adds light reinforcement but not new semantics beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Generate vector embeddings for one or more texts with Forge') and immediately differentiates from the only sibling (list_models) by describing the actual generation operation. The downstream use cases (semantic search, RAG, clustering, similarity) make the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear context for when to use the tool and, importantly, when to use each input_type ('query' for search queries, 'document' for content you index) and how to pick a model by quality/cost tradeoff. It lacks explicit when-not-to-use or alternative-tool routing, but with only one sibling that is a minor gap.
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.6embed1 field changedInput schema / properties / model / descriptionPrevious value: -"Model by quality/cost: turbo (1024d, fast, default), pro (2560d), ultra (4096d, #4 on MTEB English, top usable)."New value: +"Model by quality/cost: turbo (1024d, fast, default), pro (2560d), ultra (4096d, highest quality)."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
embed and list_models have clearly distinct purposes: one generates vector embeddings, the other lists available models. There is no overlap or ambiguity between them.
Both names use snake_case, but 'embed' is a bare verb while 'list_models' follows a verb_noun pattern. This is a minor deviation from a fully consistent convention.
With only 2 tools, the set feels thin relative to the typical 3-15 range. However, for a narrowly scoped embedding API, each tool earns its place, so it is borderline rather than mismatched.
The surface covers the core embedding workflow: generating embeddings with configurable model and dimension, plus discovering available models. Minor gaps exist (e.g., no batch job management or usage statistics), but the essential operations are present.
MCP server for Flux AI image generation
MCP server for AI dialogue using various LLM models via AceDataCloud
