Deploy and Operate AI Agents from Claude Code with MCP (2026)
Deploy, message, schedule and retire autonomous agents from Claude Code, Cursor or Codex through an MCP server, with spending guarded.
On this page
The Model Context Protocol (MCP) lets an assistant like Claude Code, Cursor or Codex call tools that live outside it. Most people use it to give the assistant read access to something: a database, a ticket tracker, documentation. It can also give it the power to run other agents: deploy them, send them work, schedule them and shut them down, all from the chat you already have open.
This guide shows how that works with Voight's open-source MCP server, what an assistant can and cannot do with it, and how spending stays under control when a model is the one pressing the buttons.
What you can ask for
Once the server is connected, requests like these become tool calls:
Deploy three research agents, give each a topic, and merge what they find.
Which of my agents are running, and how much did they use this week?
Schedule a daily 8:00 brief on my research agent.
Delete the test agents we deployed this morning.
The agents are autonomous Voight Agents: hosted, always on, with their own memory, model and channels. The MCP server is the remote control.
Step 1: Create a key with the right scope
Open agent.voight.xyz, open the account menu and choose MCP / API. There are two levels:
| Access | What the assistant can do | Expires |
|---|---|---|
| Agents: operate | List agents, read usage and tasks, chat, wake GPUs | Never |
| Agents: full | All of the above, plus deploy, renew, schedule and delete | After 90 days |
Start with operate. Give an assistant full only when you want it to spend credits.
Step 2: Add the server to your assistant
Claude Code:
claude mcp add --env VOIGHT_API_KEY=vk_your_key --transport stdio voight-agents -- npx -y @voightxyz/agents-mcp
Cursor, in ~/.cursor/mcp.json:
{
"mcpServers": {
"voight-agents": {
"command": "npx",
"args": ["-y", "@voightxyz/agents-mcp"],
"env": { "VOIGHT_API_KEY": "vk_your_key" }
}
}
}
Codex, in ~/.codex/config.toml:
[mcp_servers.voight_agents]
command = "npx"
args = ["-y", "@voightxyz/agents-mcp"]
startup_timeout_sec = 30
[mcp_servers.voight_agents.env]
VOIGHT_API_KEY = "vk_your_key"
To share a project setup without committing the secret, use a .mcp.json that reads VOIGHT_API_KEY from each person's environment. Then ask your assistant: "List my Voight agents."
What the server exposes
| Group | Tools |
|---|---|
| Read | list_agents, get_agent, get_credits, get_agent_usage, list_tasks, list_gpu_markets |
| Talk | chat_with_agent, get_reply, message_agents (up to 10 at once), get_replies |
| Run | wake_agent, wait_for_agent |
| Deploy and pay | quote_agent_deploy, deploy_agent, quote_agent_renewal, renew_agent |
| Schedule | create_task, update_task, delete_task |
| Retire | delete_agent |
Start the server with --read-only to expose only the tools that read.
How spending stays safe
When a model can deploy infrastructure, the guardrails have to live on the server, not in the prompt. A model can repeat any confirmation it is asked for. So:
- Every spend takes two steps.
quote_agent_deployreturns the price, your balance and whether the account may deploy, without spending anything.deploy_agentrepeats the quoted amount; if the real price is higher, nothing is charged. Your client asks for permission at the moment credits move. - Limits per account, across all keys: 10 deploys, 10 renewals and 10 deletes per 24 hours, 30 task changes per 24 hours, and at most 15 live agents deployed through keys.
- Deletes are narrow.
delete_agentneeds the exact name and only works on agents that were deployed with an API key. - Tasks on connected agents start paused. A task created from the MCP on an agent connected to GitHub, LinkedIn or X is saved paused, and a person enables it in the dashboard.
- The key goes to one place. The package only talks to
https://api.voight.xyz. - Agent output is fenced. Replies, task results and personas come back marked as untrusted content, so the assistant treats them as data, not instructions.
Orchestrate several agents
message_agents sends one instruction to many agents, or a different one to each, and waits once for all of them. Agents still working come back as running with a reference that get_replies collects later. It is the simplest way to run a research fan-out: three agents, three topics, one merged answer in your editor.
Schedule recurring work
A task is an instruction an agent runs on its own, once, daily or weekly (UTC). Each run is a normal agent turn with normal cost. Revoking a key does not stop the tasks it scheduled: pause or delete them from the MCP or the dashboard.
Known limits
- A reply still in progress is held in the local server's memory. If your client restarts it while an agent works, the pending reply is lost (the agent still finishes).
- Hourly tasks, editing an agent's persona or model, retrying a failed deploy, connectors and attachments are not exposed yet.
The package is open source at github.com/Voightxyz/agents-mcp, and the full reference is in the MCP documentation.