Click on "Install 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., "@parallelix-mcp Bulk classify these product reviews as positive or negative"
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 (Model Context Protocol) server for the ParalleliX Compute API. It gives an MCP client (Claude Code, Claude Desktop) tools to offload parallel inference sub-tasks to the ParalleliX network, paid in $PRLX credits.
The pattern: your frontier agent orchestrates and reasons; the distributed open-source fleet runs the cheap, embarrassingly-parallel parts. Bulk classify, extract, summarize, or translate hundreds of items in one parallel_map call instead of burning frontier tokens on a loop.
An API key. Create one in the ParalleliX app under Developers (connect a wallet, add $PRLX credits, create a key). The key looks like pk_live_… and is shown once.
Node 18 or newer.
Related MCP server: Local AI MCP
parallel_map(items, instruction, model?) Run the same instruction over many items in parallel across the network. Returns one result per item with a Proof-of-Execution hash.
infer(prompt, model?) Run a single prompt on the network. Returns the completion, the serving node id, and its PoE hash.
network_status() List the models the network currently serves.
usage() Show this key's request count, $PRLX credits spent, and remaining balance.
Add this to claude_desktop_config.json:
{
"mcpServers": {
"parallelix": {
"command": "npx",
"args": ["-y", "parallelix-mcp"],
"env": {
"PARALLELIX_API_KEY": "pk_live_your_key_here"
}
}
}
}claude mcp add parallelix --env PARALLELIX_API_KEY=pk_live_your_key_here -- npx -y parallelix-mcpEnv var | Required | Default | Notes |
| yes | none | Your |
| no |
| Point at a local coordinator for testing. |
The network runs open-source models (currently 7B-class, e.g. qwen2.5:7b). It is not a frontier model and is not meant to replace one. It is a cheap parallel executor for bulk independent sub-tasks.
Capacity is real and finite. Large batches queue; usage and network_status show you what's available.
Credits are metered off-chain by the coordinator (deposit $PRLX once on-chain, no per-call gas). v1 is custodial.
MIT
Run a single prompt on the ParalleliX network. Returns the completion plus the serving node id and Proof-of-Execution hash. For bulk independent work, prefer parallel_map.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | ||
| model | No | Optional model id (see network_status). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses return values (completion, node id, hash). No side effects mentioned, but inference is likely read-only. Without annotations, the description reasonably informs the agent of what to expect.
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: first states action and return, second provides alternative. No wasted words, front-loaded with the core purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with two parameters and no output schema, the description covers the return value and usage context. Lacks discussion of errors or limits, but adequate for typical 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?
Schema coverage is 50% (only "model" has description). Description adds no further explanation for "prompt" or beyond schema. Fails to compensate for the missing parameter 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?
Clearly states verb ("Run"), resource ("ParalleliX network"), and singles out results ("completion plus serving node id and Proof-of-Execution hash"). Explicitly distinguishes from sibling "parallel_map" for bulk work.
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?
Explicitly states when to prefer alternative ("For bulk independent work, prefer parallel_map"), implying this tool is for single prompts. No additional prerequisites or context, but clear enough for simple usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the models the ParalleliX network currently serves.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the action without revealing behavioral traits such as data freshness, latency, or any side effects. Being read-only is obvious but not explicitly stated.
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 extraneous words. It is front-loaded and 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 the simplicity (no parameters, no output schema), the description provides the basic purpose. However, it does not specify the content of the list (e.g., model names, versions, status), which could be helpful for an agent to interpret results.
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 no parameters, so schema coverage is 100%. According to the rubric, zero parameters warrant a baseline of 4. The description does not need to add parameter details.
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 lists models served by the ParalleliX network. The verb 'List' and resource 'models' are specific. However, it does not explicitly differentiate from sibling tools like 'infer' or 'parallel_map', which might also involve 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?
No guidance on when to use this tool versus alternatives. Siblings are listed but not compared. The description lacks context for appropriate usage scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run the SAME instruction over MANY items in parallel on the ParalleliX network. Ideal for bulk classify / extract / summarize / translate where each item is independent. Returns one result per item with a Proof-of-Execution hash. Use this instead of looping single calls: it fans out across the network's nodes simultaneously.
| Name | Required | Description | Default |
|---|---|---|---|
| items | Yes | The inputs to process, one job each. | |
| instruction | Yes | What to do with each item, e.g. 'Classify the sentiment as positive, negative, or neutral.' | |
| model | No | Optional model id (see network_status). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, description must carry full burden. It discloses parallel execution, fan-out network, return format (one result per item with Proof-of-Execution hash), and independence requirement. Lacks details on failure handling or limits, but adequate for high-level understanding.
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 with no fluff, front-loaded with key verbs 'Run the SAME instruction over MANY items in parallel'. Every phrase adds info.
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 no output schema and no annotations, description covers purpose, usage, return structure, and independence. Missing details on max items, timeout, or error handling, but sufficient for initial selection.
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% (baseline 3). Description adds value by explaining model parameter as optional and linking to network_status, and emphasizes that items are independent and instruction is the same for all. This enriches the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool runs the same instruction over many items in parallel, distinguishing it from siblings like infer (presumably single-item) by emphasizing bulk processing. It also references network_status for model IDs, reinforcing distinction.
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?
Explicitly recommends use for bulk classify/extract/summarize/translate with independent items, advises against looping single calls, and directs to network_status for model info. Provides clear when-to-use and alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Show this API key's request count, $PRLX credits spent, and remaining credit balance.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full transparency burden. It discloses what the tool shows (request count, credits, balance) but does not mention whether it makes network requests, real-time vs cached data, or any behavioral characteristics beyond the displayed metrics.
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, front-loaded with the verb 'Show'. No wasted words, efficiently conveys 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?
Given the tool has no parameters and no output schema, the description provides sufficient information about the three metrics it returns. It is complete for this simple tool.
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, so schema coverage is 100%. The description adds value by explaining what the output contains, which is appropriate for a parameterless tool.
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 shows request count, credits spent, and remaining balance for the API key. It is specific (verb 'Show', resource 'this API key's'), and effectively distinguishes from sibling tools like infer, network_status, parallel_map which have unrelated 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 explicit guidance on when to use this tool versus alternatives. It only implies it's for checking API usage, but does not mention when to use it or 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.1infernetwork_statusparallel_mapusageEach tool serves a distinct purpose: infer for single prompts, parallel_map for bulk, network_status for model info, usage for account info. No overlap.
All tool names follow the same lowercase_with_underscores pattern (infer, network_status, parallel_map, usage), providing a predictable and clean interface.
Four tools is perfectly scoped for a focused API wrapping inference, network info, and usage. Each tool is necessary and there are no redundant ones.
Covers the essential operations: single inference, bulk inference, network status, and usage. Minor gap: no explicit model selection parameter in infer/parallel_map, but it may be handled elsewhere.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
Hosted MCP server for LLM cost estimation, model comparison, and budget-aware routing.
Hosted MCP server for task-first delegation to remote workstations and workers.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/parallelixnetwork/parallelix-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
