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., "@microtensor-mcp ask a specialist how to optimize this slow Postgres 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 that gives Claude, ChatGPT, Microsoft Copilot, Cursor, VS Code and any other MCP host the Microtensor certified specialists as tools. Your API key stays in the server's environment; the agent only sees the tools.
Tool | What it does |
| Sends the request to |
| The models the API serves, with task, quality and whether an operator holds them now |
| The tasks |
context becomes the system message (for SQL, the schema as CREATE TABLE statements) and question the user message. Errors come back as {error, message, status} so the agent can decide what to do.
Related MCP server: Enterprise MCP Gateway and Tool Registry
pip install microtensor-mcpor run it without installing:
uvx microtensor-mcpSet MICROTENSOR_API_KEY to a key from https://www.microtensor.cloud/console/keys. MICROTENSOR_BASE_URL overrides the API (default https://api.microtensor.cloud/v1).
claude_desktop_config.json (macOS ~/Library/Application Support/Claude/, Windows %AppData%\Claude\):
{
"mcpServers": {
"microtensor": {
"command": "uvx",
"args": ["microtensor-mcp"],
"env": { "MICROTENSOR_API_KEY": "mt_sk_..." }
}
}
}Same shape. VS Code takes it in .vscode/mcp.json under servers with "type": "stdio"; Cursor under Settings → MCP.
Both connect to MCP servers over HTTP. Run microtensor-mcp --http --port 8765 behind your own HTTPS endpoint and register that URL.
pip install -e ".[dev]"
ruff check . && mypy microtensor_mcp && pytest -qDocs: https://www.microtensor.cloud/docs/integrations/agents/mcp
Send a request to a Microtensor specialist. context is the task context (for SQL, the schema as CREATE TABLE statements); model is mt/auto, mt/ or a pin.
| Name | Required | Description | Default |
|---|---|---|---|
| model | No | mt/auto | |
| context | No | ||
| question | Yes | ||
| quality_floor | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It omits whether the call is synchronous, how long it may take, what auth or quota applies, and what quality_floor actually controls — all material for a remote specialist-invocation tool.
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 tight sentences with the purpose front-loaded and no wasted words. The second sentence is a slightly run-on enumeration of two parameters, but the density is appropriate for the space available.
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?
The tool takes 4 parameters at 0% schema coverage with no annotations, and an output schema exists so return values need not be explained. Even so, quality_floor is never mentioned and no sibling-routing guidance is given, leaving the definition under-specified for its 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 description coverage is 0%, so the description must compensate for all 4 parameters. It usefully documents the model format ('mt/auto, mt/<arena> or a pin') and gives a concrete context example, but leaves quality_floor and the requirements of question completely undocumented.
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 and resource: 'Send a request to a Microtensor specialist.' An agent understands the action clearly, but the description does not distinguish this tool from siblings like list_models or routing_tasks, nor explain what a 'specialist' returns versus those alternatives.
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?
There is no explicit when-to-use or when-not-to-use guidance. The 'for SQL, the schema as CREATE TABLE statements' aside hints at context usage but never says when to call this tool instead of list_models or routing_tasks, leaving routing entirely to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the served models with task, quality and whether an operator holds them now.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are supplied, so the description carries the full burden. It does disclose the shape of what is returned (task, quality, current operator ownership), which is useful behavioral context, but it says nothing about permissions, filtering, or pagination. For a zero-parameter read-only listing, this is adequate but thin.
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 well-formed sentence with the resource front-loaded and no filler. Every clause carries 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?
With an output schema present and zero input parameters, the description does not need to enumerate return values, and it correctly avoids doing so. The only real gap is the absence of routing guidance relative to its siblings.
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 takes zero parameters, so there is no parameter semantics to document; the baseline for a no-parameter tool is 4. The description's mention of task/quality/operator describes output rather than inputs.
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 a specific verb ('List') and resource ('served models') and even names the returned fields (task, quality, operator-held status), so the agent knows exactly what it gets. It does not, however, explicitly distinguish itself from the siblings routing_tasks and ask_specialist, so it falls short of 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?
There is no explicit when-to-use or when-not-to-use guidance, and no mention of the sibling tools routing_tasks or ask_specialist. The intent (inspect available models) is only implied by the verb 'List'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the tasks mt/auto routes today and the specialist each one goes to.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. 'List' implies a read-only operation and 'today' establishes a temporal scope, but there is no mention of authentication, rate limits, pagination, or result freshness. It provides minimum viable context but leaves notable 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?
A single, front-loaded sentence with no filler. It communicates purpose, temporal scope, and return content efficiently.
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 list tool with an output schema, the description tells the agent exactly what the tool returns and the temporal scope. Return formatting is handled by the output schema, so no additional context is required to invoke it correctly.
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 the baseline is 4. The empty schema requires no parameter explanation, and the description appropriately focuses on the tool's output content.
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 ('List') and resource ('tasks mt/auto routes today and the specialist each one goes to'), making the scope and return content clear. It is easily distinguished from siblings ask_specialist and list_models, though 'mt/auto' is domain jargon that may not be self-explanatory.
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 when-to-use, prerequisites, or alternative tools are provided. Usage is only implied by the description of what it lists, leaving the agent to infer the appropriate context.
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.0ask_specialistlist_modelsrouting_tasksScored across 3 tools
The three tools are largely distinct: ask_specialist performs inference, list_models enumerates models, and routing_tasks enumerates task routes. list_models and routing_tasks are both read-only listing tools, so there is mild overlap, but the descriptions differentiate model attributes from task-to-specialist routing.
ask_specialist and list_models follow a clean verb_noun pattern, but routing_tasks is a noun phrase with no verb and breaks the convention. The set is readable but uses mixed styles.
With only 3 tools, the surface is thin for what appears to be a routing/inference service. Each tool earns its place, but the count is borderline minimal for the implied scope.
Core actions (ask, list models, list routes) are covered, but there is no way to manage or inspect pins even though ask_specialist references them, and no tool to query individual model or routing details. Notable gaps exist in the lifecycle.
MCP server for your apps' tools and custom tools, plus hosted AI agents and approval-gated workflows
Search and inspect source-pinned agent skills, plugins and tools through a free public MCP.
The OpenRouter for tools. One MCP connection gives any AI agent 254 hosted tools, pay per call.
Pay-per-use tool marketplace for AI agents. Search, price-check, and call APIs via MCP.