Skip to main content
Back to Blog
how-to

Running Orbitable's Agent Fleet from Claude: What the MCP Server Does

The Orbitable Team·AI Agent Practice·17 Jul 2026·6 min read

Yes. Orbitable ships an MCP server that exposes all 50 specialist agents and the Dispatcher (the orchestrator that routes work between them, not a 51st specialist) as callable tools, so you can call them directly from Claude Desktop, Claude Code, or any other MCP-compatible client. Every call still runs against the same shared world model, the same ICP, brand voice, products, competitors, and knowledge base that the Orbitable app uses, and draws from the same credit pool.

What the MCP server actually exposes

The Model Context Protocol is an open standard for letting an AI client like Claude call external tools during a conversation. Orbitable's MCP server registers each of the 50 specialist agents, spread across 10 squads covering strategy, content, sales, and growth work, plus the Dispatcher, as individual tools inside that protocol. When you ask Claude to do something that matches an agent's job, Claude can call that tool directly. When the request is broader or ambiguous, it can call the Dispatcher, which decides which specialist or sequence of specialists should handle it, the same routing logic the Dispatcher uses inside the Orbitable app itself.

Nothing about the agents changes when they're called this way. A content agent drafting a landing page still writes against your brand voice guide and ICP. A sales agent building an outreach sequence still uses whatever HubSpot, Attio, or Apollo data is connected to your world. The interface changes, not the agent.

Why call agents from Claude instead of the app

The main reason to do this is to keep the work in whatever thread you're already using. If you're researching a competitor, drafting a positioning brief, or working through a plan inside Claude and you want an Orbitable agent to produce a deliverable partway through, you don't need to open a second tab and re-explain the context. Because the agents read from the same world model regardless of where the call comes from, you get the same grounded output without repeating yourself.

It also matters if you're chaining tasks. Because MCP tools are callable programmatically, you can ask Claude to run several agent calls in sequence as part of a longer task, for example, research a market segment, then hand the findings to a content agent, then hand that draft to a sales agent for an outreach angle, all inside one Claude session rather than three separate app visits.

What calling an agent through Claude actually does

Mechanically, a tool call from Claude reaches the same backend that runs the Orbitable app. The agent executes, the work consumes credits from your workspace's pool exactly as it would if you'd triggered it from inside the app, and the output is stored the same way. That matters for two reasons. First, there's no separate credit allowance for MCP calls, it's one pool, so a heavy Claude session can draw down the same credits you'd otherwise spend in the app. Second, because the output lands in the same place, it can still go through whatever review process your workspace uses, including the Dock, if you have it.

Reviewing work never costs credits, whichever interface triggered it. If your team runs out of credits mid-session, work pauses until a prepaid credit pack tops it up or the month resets, there's no overage billing either way.

Claude via MCP compared with the Orbitable app

DimensionCalling agents from Claude via MCPWorking in the Orbitable app
Best forAd hoc agent calls inside a broader Claude workflow or research threadRunning structured missions, schedules, and the full GTM plan
World modelSame shared context, same ICP, brand voice, competitors, knowledge baseSame shared context
Credit usageDrawn from the same workspace credit poolDrawn from the same workspace credit pool
Access to DockOutput lands in the same pipeline; Dock review works if enabledNative review surface, included on Agency and Enterprise
Access to AutopilotNot exposed as an MCP tool; Autopilot's weekly plan still lives in the appAutopilot proposes a weekly plan, approved in the Dock
Visibility of playbooks and templatesNot directly browsable; you're calling agents, not selecting from the libraryFull access to the 22 playbooks, 9 schedule templates, 6 document templates

The pattern is straightforward: Claude via MCP is a way to reach into the fleet from outside, the app is where the fleet's own planning and review tools live.

Setting up the connection

You add Orbitable's MCP server to your client's configuration and authenticate with your Orbitable workspace. Once connected, the 50 agents and the Dispatcher appear as tools Claude can see and call. You can address an agent by name if you know exactly which specialist you want, or describe the task in plain language and let the Dispatcher route it, which mirrors how requests get handled inside the app when you're not sure which squad owns a piece of work.

Because the connection authenticates to your workspace, everything runs inside your existing plan, seats, and world, there's no separate MCP-only tier or a different set of agents available through the protocol. What you can call from Claude is exactly what's in your fleet.

Where this doesn't help

The MCP server is not a way to run Autopilot or manage the Dock from Claude. Autopilot proposes a weekly plan, one focus, three to five missions, a carry-over list, and a NOT-doing list, but approval happens in the Dock, and the Dock's pin-and-markup review surface isn't part of what's exposed as MCP tools. If your workflow depends on a client reviewing and approving drafts, that review still has to happen in the Dock, whether the draft originated from an app-triggered mission or a Claude session. Treat MCP as the way to reach individual agents and the Dispatcher from outside the app, not as a replacement for the app's planning and review layer.

FAQ

Can I control Orbitable's agents from tools other than Claude?

Yes. The MCP server implements the open Model Context Protocol, so any MCP-compatible client can connect to it and see the same 50 agents and the Dispatcher as callable tools, not just Claude Desktop or Claude Code.

Does calling an agent through Claude use a separate credit allowance?

No. MCP calls draw from the same workspace credit pool as work triggered inside the Orbitable app. Reviewing work never costs credits regardless of which interface started it, and there's no overage billing if the pool runs out mid-month.

Can I approve an Autopilot plan or review Dock submissions from Claude?

No. The MCP server exposes the 50 specialist agents and the Dispatcher as tools, not the Dock or Autopilot interfaces. Autopilot's weekly plan still gets approved in the Dock inside the app, whether the underlying work was triggered from Claude or the app itself.

Do I call the Dispatcher directly, or does Claude pick agents for me?

Both are possible. You can address a specific specialist agent by name if you already know which squad owns the task, or describe the task in plain language and let the Dispatcher route it to the right agent, the same logic it uses inside the app.

If a client uses the Dock, do they see work that came from a Claude session?

Yes, if the Dock is enabled on your plan. Output from an MCP-triggered agent call lands in the same pipeline as app-triggered work, so it goes through the same review, markup, and approval flow a client would use for anything else.

Read More