-MCP server exposing provider-neutral AgentDispatch tools.
+
Spawn cloud agents from your AI.
-Tools:
+
+ Claude Code, OpenClaw, and Hermes are great at planning. They choke when a job runs for hours.
+ @agent-dispatch/mcp-server hands them a managed cloud runtime — one MCP call, results when they land.
+
-```bash
-npm install @agent-dispatch/core @agent-dispatch/mcp-server @agent-dispatch/store-sqlite @agent-dispatch/adapter-aws-agentcore
-npx agentdispatch-mcp --config agentdispatch.config.json
+---
+
+## Why this exists
+
+Local AI assistants plan brilliantly. They get cramped the moment work gets long:
+
+- A **deep-research** sweep across fifty pages of docs.
+- An **account-wide audit** that has to touch every service.
+- A **multi-hour** job that has no business sitting in your IDE's context window.
+
+Doing it inline burns context, blocks the chat, and dies the second you close the laptop. That's not what local agents are for.
+
+**AgentDispatch is the missing tool.** One MCP server gives your assistant a single primitive: *spawn a cloud agent with this instruction, come back later for the result.* The work runs on managed cloud compute. Status, logs, and the final output stream back through the same MCP channel.
+
+- ☁️ **Real cloud, not your laptop.** AWS Bedrock AgentCore today; new clouds plug in through one small adapter contract.
+- ⏱️ **Built for marathons.** Sessions for stateful runs. Jobs for hours-long work. Sync for fast turn-around. Same API, three modes.
+- 🔭 **Full visibility.** Status, paginated logs, results, cancellation — over MCP, the SDK, or the CLI.
+- 🪶 **Boring defaults.** SQLite state. stdio transport. Zero hidden services. Runs on a laptop, in CI, on a server.
+
+## What it does
+
+A single MCP server exposes nine tools to your assistant:
+
+| Tool | What it does |
+| --- | --- |
+| `spawn_cloud_agent` | The shortcut. One `instruction`, defaults from a runtime profile, returns a `task_id`. |
+| `dispatch_task` | The escape hatch. Full control over provider, capability, backend, target, and input. |
+| `get_task_status` | Current status for a dispatched task. |
+| `get_task_logs` | Paginated logs, cursor-based. |
+| `get_task_result` | Final result payload when the task completes. |
+| `cancel_task` | Cancel an in-flight task. |
+| `list_providers` | Providers configured in this server. |
+| `list_capabilities` | Capabilities a provider exposes (filterable). |
+| `list_account_profiles` | Account profiles configured for dispatch. |
+
+The model side looks like this:
+
+```ts
+spawn_cloud_agent({ instruction: "Audit our S3 buckets for public read and report findings." })
+// → { task_id: "task_...", status: "running" }
+
+get_task_status({ task_id: "task_..." })
+get_task_logs({ task_id: "task_...", cursor: 0 })
+get_task_result({ task_id: "task_..." })
```
-The server loads account profiles, SQLite storage, and configured adapters from `agentdispatch.config.json`.
+All tool inputs are validated with [Zod](https://zod.dev). See [`src/schemas.ts`](src/schemas.ts) for the exact shapes.
-Before wiring it into an MCP client, validate that the stdio server can load config:
+## Supported clients
+
+Anything that speaks MCP. The common ones today:
+
+- 🤖 **Claude Code** — add it to `~/.claude/mcp_settings.json` (or your project's `.mcp.json`).
+- 🦅 **OpenClaw** — add it to your MCP server list and call `spawn_cloud_agent` from inside any task.
+- 🪽 **Hermes** — same wire-up; long-running reasoning and tool-rich runs move to the cloud.
+- Claude Desktop, Cursor, Continue, Goose, Zed — same JSON, different config file.
+
+## What the cloud agent runs
+
+`spawn_cloud_agent` and `dispatch_task` both accept an optional `framework` string, and runtime profiles carry a default. The value travels through to the worker — **AgentDispatch doesn't interpret it; the worker does.** That means you can wire any agent framework that your worker knows how to instantiate.
+
+Today the reference worker in [`worker-agentcore`](https://github.com/agent-dispatch/worker-agentcore) ships with **Strands** support. Other frameworks (your own agent loop, an OpenClaw-style runner, a Hermes-style long-context worker) become available the moment your worker handles their `framework` value. There's no allow-list in AgentDispatch itself.
+
+## Quick start
```bash
+npm install \
+ @agent-dispatch/core \
+ @agent-dispatch/mcp-server \
+ @agent-dispatch/store-sqlite \
+ @agent-dispatch/adapter-aws-agentcore
+
npx agentdispatch-mcp --config agentdispatch.config.json --check
```
-Configure `defaults.runtime` for the simple agent path. Agents can then call `spawn_cloud_agent` with only an `instruction`; AgentDispatch resolves provider, account, backend, target mode, framework, and runtime tool defaults from the named runtime profile.
+Wire it into your MCP client:
+
+```jsonc
+// Claude Code, Claude Desktop, OpenClaw, Hermes, Cursor — same shape
+{
+ "mcpServers": {
+ "agentdispatch": {
+ "command": "npx",
+ "args": ["agentdispatch-mcp", "--config", "/abs/path/agentdispatch.config.json"]
+ }
+ }
+}
+```
+
+The defaults come from your runtime profile — provider, account, backend, target mode, framework, and runtime tools are all resolved for you. From the model side, `spawn_cloud_agent({ instruction })` is the only call you need.
+
+## How it works
+
+```
+ Claude Code · OpenClaw · Hermes · any MCP client
+ │ stdio
+ ▼
+ ┌─────────────────────────────────────────────┐
+ │ @agent-dispatch/mcp-server │ ← this repo
+ └─────────────────────┬───────────────────────┘
+ │
+ ▼
+ ┌─────────────────────────────────────────────┐
+ │ @agent-dispatch/core │ ← contracts + dispatch
+ └──────┬──────────┬───────────────────────────┘
+ │ │
+ ▼ ▼
+ ┌──────────┐ ┌──────────────────────────────────┐
+ │ store │ │ adapter (AWS Bedrock AgentCore) │
+ │ (sqlite) │ │ ↓ │
+ └──────────┘ │ cloud worker — runs the task │
+ └──────────────────────────────────┘
+```
+
+1. **Local assistant** issues `spawn_cloud_agent` over MCP.
+2. **MCP server** validates input, hydrates defaults from a runtime profile, calls the core runtime.
+3. **Core** picks the right capability + adapter, persists the task, dispatches.
+4. **Adapter** invokes the worker in your cloud — synchronous, session, or job target mode.
+5. **Worker** runs an agent framework on managed cloud infrastructure. The reference worker in [`worker-agentcore`](https://github.com/agent-dispatch/worker-agentcore) ships with Strands; add support for any other framework by handling its `framework` string.
+6. Status, logs, and results flow back through the same path.
-Minimal AWS AgentCore session-mode config:
+## Configuration
+
+Minimal AWS Bedrock AgentCore (session mode):
```json
{
@@ -63,7 +183,7 @@ Minimal AWS AgentCore session-mode config:
"backend": "aws-agentcore",
"target": { "mode": "session" },
"framework": "strands",
- "runtimeTools": { "enabled": ["web-search"] }
+ "runtimeTools": { "enabled": ["web-search", "code-interpreter"] }
}
},
"defaults": {
@@ -71,3 +191,48 @@ Minimal AWS AgentCore session-mode config:
}
}
```
+
+Once `defaults.runtime` is set, `spawn_cloud_agent` only needs an `instruction`. The `framework` value is passed straight through to the worker — change it to any string your worker recognises.
+
+Validate the wiring before connecting an MCP client:
+
+```bash
+npx agentdispatch-mcp --config agentdispatch.config.json --check
+```
+
+## Real-world use cases
+
+- **Deep research from chat.** Claude Code spawns a cloud agent: "Read the last 90 days of CloudTrail anomalies and propose detection rules." The session keeps going. Twenty minutes later it pulls the result.
+- **Parallel codebase audits.** Claude Code fans out a dozen `spawn_cloud_agent` calls, one per service, and aggregates the reports.
+- **Long-running OpenClaw runs.** OpenClaw plans the work locally, dispatches the multi-hour execution to a managed AgentCore worker.
+- **Tool-rich Hermes jobs.** Hermes uses cloud-side tools (web, code interpreter, repo access) that aren't available to the local process.
+
+## The rest of AgentDispatch
+
+This MCP server is one face of a small, focused stack:
+
+| Repo | Role |
+| --- | --- |
+| [`core`](https://github.com/agent-dispatch/core) | Runtime contracts and dispatch orchestration |
+| [`mcp-server`](https://github.com/agent-dispatch/mcp-server) | **You are here.** MCP face for the runtime |
+| [`sdk-js`](https://github.com/agent-dispatch/sdk-js) | TypeScript SDK for application code |
+| [`cli`](https://github.com/agent-dispatch/cli) | Command-line interface |
+| [`store-sqlite`](https://github.com/agent-dispatch/store-sqlite) | SQLite + filesystem state store |
+| [`adapter-aws-agentcore`](https://github.com/agent-dispatch/adapter-aws-agentcore) | AWS Bedrock AgentCore adapter |
+| [`worker-agentcore`](https://github.com/agent-dispatch/worker-agentcore) | Standard AgentCore worker contract |
+| [`adapter-template`](https://github.com/agent-dispatch/adapter-template) | Starter for new cloud adapters |
+| [`docs`](https://github.com/agent-dispatch/docs) | Documentation |
+
+## Contributing
+
+PRs, issues, and adapter contributions are welcome. See [`CONTRIBUTING.md`](CONTRIBUTING.md) for the local workflow.
+
+If you ship a new framework worker (or a new cloud adapter), please open a discussion — we'd love to link it from the org README.
+
+## License
+
+Apache-2.0. See [`LICENSE`](LICENSE).
+
+
diff --git a/brand/README.md b/brand/README.md
new file mode 100644
index 0000000..e207af5
--- /dev/null
+++ b/brand/README.md
@@ -0,0 +1,119 @@
+# AgentDispatch brand kit
+
+This directory holds the visual identity, the org profile README, and the marketing site for the AgentDispatch organization. Because this branch lives inside `mcp-server` and my publishing access is scoped to a single repo, everything is staged here for you to copy into the right destination repos.
+
+## Contents
+
+```
+brand/
+├── logo-mark.svg # square mark for org avatar (dark bg, 200×200, scales)
+├── logo-mark-light.svg # square mark for light-bg contexts
+├── wordmark.svg # horizontal lockup for light themes (READMEs)
+├── wordmark-dark.svg # horizontal lockup for dark themes
+├── profile-readme/
+│ └── profile/
+│ ├── README.md # the org profile README
+│ └── assets/ # SVGs the README references
+└── website/ # static site, no build step
+ ├── index.html
+ ├── styles.css
+ ├── script.js
+ └── assets/
+ ├── favicon.svg
+ └── og.svg
+```
+
+The new `mcp-server` README (the viral entry point) is already in place at the repo root and references `brand/wordmark.svg` directly.
+
+## Design system
+
+| Token | Value |
+| --- | --- |
+| Background (dark) | `#0B1020` |
+| Surface (card) | `#131A2E` |
+| Border | `#1F2A44` |
+| Text | `#E2E8F0` |
+| Text muted | `#94A3B8` |
+| Accent (violet deep / on light) | `#7C3AED` |
+| Accent (cyan deep / on light) | `#06B6D4` |
+| Accent (violet light / on dark) | `#A78BFA` |
+| Accent (cyan light / on dark) | `#22D3EE` |
+| Gradient | `#7C3AED → #06B6D4` (or light variants on dark backgrounds) |
+| Typeface | Inter (UI / docs), system-ui fallback |
+| Code typeface | ui-monospace / JetBrains Mono |
+
+The logo mark is a **cloud spawning agents**: a soft cloud silhouette (the dispatcher) with three short spokes fanning to three small agent tiles. It reads literally as "cloud → spawn agents" — the system's job in one shape.
+
+## How to deploy each piece
+
+### 1. Org avatar
+
+Upload `brand/logo-mark.svg` (or the light variant) to the AgentDispatch GitHub org settings → *Profile picture*. GitHub will rasterize it for you; the SVG already has a 44px corner radius so it sits well in a rounded display.
+
+### 2. Org profile README
+
+GitHub renders `profile/README.md` from a special repo named `.github` at the org root.
+
+```bash
+# Create the .github repo (one-time, manual since this session is scoped to mcp-server)
+gh repo create agent-dispatch/.github --public --description "AgentDispatch org profile"
+
+git clone https://github.com/agent-dispatch/.github
+cd .github
+
+# Copy from this branch
+cp -r path/to/mcp-server/brand/profile-readme/profile ./profile
+
+git add profile
+git commit -m "Add org profile README and brand assets"
+git push
+```
+
+Within a minute of pushing, https://github.com/agent-dispatch will render the new profile.
+
+### 3. Website
+
+The site is intentionally zero-build — three files plus an assets folder.
+
+Three easy deployment options:
+
+**A. GitHub Pages from the docs repo**
+```bash
+git clone https://github.com/agent-dispatch/docs
+cp -r brand/website/* ../docs/
+# enable Pages: Settings → Pages → Source: deploy from a branch → main / root
+```
+
+**B. A dedicated `website` repo**
+```bash
+gh repo create agent-dispatch/website --public
+cd website
+cp -r ../mcp-server/brand/website/* .
+git add .; git commit -m "Initial site"; git push
+# enable Pages, optionally point a CNAME (agentdispatch.dev / .ai / .io)
+```
+
+**C. Netlify / Cloudflare Pages / Vercel**
+Drag-drop the `brand/website` directory. It's all static — no framework, no build step.
+
+Recommended: option B with a custom domain. Once live, update README hero links and the OG meta tags in `index.html` to point at the canonical URL.
+
+### 4. Once everything is live
+
+In order:
+
+1. Set the org avatar (step 1).
+2. Push the `.github` repo (step 2) — this publishes the wordmark SVGs.
+3. Publish the website (step 3) and add the canonical URL to:
+ - the org profile README ("Learn more →")
+ - the mcp-server README header
+ - each repo's `package.json` `homepage` field
+
+## Approving the look
+
+If you want to tweak the logo, the two knobs that matter most:
+
+- **Spoke angles.** Currently 0° middle, ±28° on the right. Tighter (±15°) reads more focused; wider (±45°) reads more "broadcast". Edit the `x2`/`y2` coordinates in `logo-mark.svg`.
+- **Palette.** Violet→cyan is on-trend for AI tooling but easy to change — swap the gradient stops in the `` block. The whole brand follows from these two colors.
+
+That's the entire kit. Ping me if you want a horizontal social-media banner (1500×500 GitHub-org sized), an animated SVG variant, or a dark-mode preview screenshot of the site.
diff --git a/brand/logo-mark-light.svg b/brand/logo-mark-light.svg
new file mode 100644
index 0000000..9316bf0
--- /dev/null
+++ b/brand/logo-mark-light.svg
@@ -0,0 +1,50 @@
+
diff --git a/brand/logo-mark.svg b/brand/logo-mark.svg
new file mode 100644
index 0000000..6f5801e
--- /dev/null
+++ b/brand/logo-mark.svg
@@ -0,0 +1,61 @@
+
diff --git a/brand/profile-readme/profile/README.md b/brand/profile-readme/profile/README.md
new file mode 100644
index 0000000..fe86818
--- /dev/null
+++ b/brand/profile-readme/profile/README.md
@@ -0,0 +1,111 @@
+
+
+
+
+
+
+
+
Spawn cloud agents from your AI.
+
+
+ Claude Code, OpenClaw, and Hermes plan brilliantly — and choke on multi-hour work.
+ AgentDispatch hands them a managed cloud runtime: one MCP call, results when they land.
+
+
+---
+
+## The problem
+
+Local AI assistants — Claude Code, OpenClaw, Hermes — plan brilliantly. They get cramped the moment work gets long. A deep-research sweep, an account-wide audit, a multi-hour reasoning job: none of it belongs in a laptop's context window.
+
+## The fix
+
+AgentDispatch is the one tool your local agent is missing: **spawn a cloud agent with this instruction, come back later for the result.** The run happens on managed cloud compute. Status, logs, and final output stream back over MCP.
+
+```
+spawn_cloud_agent({ instruction: "Audit every Lambda for public invoke." })
+// → task_id, then status / logs / result on demand
+```
+
+- ☁️ **Real cloud, not your laptop.** AWS Bedrock AgentCore today; bring your own cloud tomorrow.
+- ⏱️ **Built for marathons.** Sync, session, or job mode — same API.
+- 🔭 **Full visibility.** Status, logs, results, cancellation.
+- 🪶 **Boring defaults.** SQLite, stdio, no hidden services.
+
+## Made for the agents you already use
+
+| Local assistant | What it gets |
+| --- | --- |
+| 🤖 **Claude Code** | A cloud companion for parallel audits, long refactors, and deep-research sweeps. |
+| 🦅 **OpenClaw** | Offloads multi-step research and tool-rich runs to a managed cloud worker. |
+| 🪽 **Hermes** | Runs long-context reasoning and hours-long jobs without leaving the chat. |
+| Claude Desktop · Cursor · Continue · Goose · Zed | Same MCP config, same primitive. |
+
+## Three faces, one runtime
+
+- **MCP server** — for AI assistants ([`mcp-server`](https://github.com/agent-dispatch/mcp-server)).
+- **TypeScript SDK** — for your own application code ([`sdk-js`](https://github.com/agent-dispatch/sdk-js)).
+- **CLI** — for operators and scripts ([`cli`](https://github.com/agent-dispatch/cli)).
+
+All three call into the same dispatcher and share the same runtime profiles.
+
+## How it fits together
+
+```
+ Claude Code · OpenClaw · Hermes
+ │ MCP
+ ▼
+ ┌───────────────────┐
+ │ AgentDispatch │ ← spawn / status / logs / result / cancel
+ └─────────┬─────────┘
+ │
+ ▼
+ ┌───────────────────┐
+ │ cloud adapter │ (AWS Bedrock AgentCore today)
+ └─────────┬─────────┘
+ ▼
+ ┌───────────────────┐
+ │ cloud worker │ runs Strands today · your framework next
+ └───────────────────┘
+```
+
+The adapter contract is small and stable, so a new cloud (or a new framework) is a focused, well-scoped addition — not a rewrite.
+
+## Repositories
+
+| Repo | What it is |
+| --- | --- |
+| [`mcp-server`](https://github.com/agent-dispatch/mcp-server) | **Start here.** MCP face for the runtime — the viral entry point. |
+| [`core`](https://github.com/agent-dispatch/core) | Runtime contracts and dispatch orchestration. The heart. |
+| [`sdk-js`](https://github.com/agent-dispatch/sdk-js) | TypeScript SDK for application code. |
+| [`cli`](https://github.com/agent-dispatch/cli) | Command-line interface for operators. |
+| [`store-sqlite`](https://github.com/agent-dispatch/store-sqlite) | Default SQLite + filesystem state store. |
+| [`adapter-aws-agentcore`](https://github.com/agent-dispatch/adapter-aws-agentcore) | AWS Bedrock AgentCore adapter. |
+| [`worker-agentcore`](https://github.com/agent-dispatch/worker-agentcore) | Standard AgentCore worker contract. Reference Strands worker lives here; add your own framework by handling its `framework` string. |
+| [`adapter-template`](https://github.com/agent-dispatch/adapter-template) | Starter for new cloud adapters. |
+| [`docs`](https://github.com/agent-dispatch/docs) | Documentation and guides. |
+
+## Build a new worker or adapter
+
+A new **framework worker** is a function that maps `{ instruction, context, framework, runtime_tools }` to a result envelope — see [`worker-agentcore`](https://github.com/agent-dispatch/worker-agentcore).
+
+A new **cloud adapter** implements five methods (dispatch, status, logs, result, cancel) — fork [`adapter-template`](https://github.com/agent-dispatch/adapter-template).
+
+Open a discussion when you ship — we'd love to link it.
+
+## Community
+
+- Issues and PRs welcome on any repo.
+- Architecture questions, framework integrations, and ideas → open a discussion in `docs`.
+
+
+ Apache-2.0 · Built by the AgentDispatch contributors
+
☁️ CLOUD AGENTS · ONE MCP CALL · BRING YOUR OWN CLOUD
+
+ Spawn cloud agents
+ from your AI.
+
+
+ Claude Code, OpenClaw, and Hermes plan brilliantly — and choke on multi-hour work.
+ AgentDispatch hands them a managed cloud runtime: one MCP call, results when they land.
+
+ Plan locally. Run in the cloud. Get results back in chat. No new SDKs, no new auth, no new UI — just one more MCP server in the config you already have.
+
+
+
+
Claude Code
+
Fan out parallel cloud agents to audit services, refactor across packages, or grind through long codebase research while the local session stays snappy.
+
+
+
OpenClaw
+
Plan in OpenClaw, execute in the cloud. Deep-research runs and tool-heavy jobs come back as a single tool response — no token bloat in the local session.
+
+
+
Hermes
+
Hermes hands its multi-hour reasoning and tool-rich runs to managed compute — close the laptop, pick the result up later.
+
+
+
Any MCP-compatible client works — these three are the common ones today.
+
+
+
+
The one tool your assistant was missing
+
+ Local agents already have tools. AgentDispatch adds the one they didn't have: a way to start real work in the cloud and pick the result up later.
+
+
+
+
☁️
+
Real cloud, not your laptop
+
Managed AWS Bedrock AgentCore today. New clouds plug in through one small adapter contract — your code doesn't move.
+
+
+
⏱️
+
Built for marathons
+
Sessions for stateful runs. Jobs for hours-long work. Sync for fast turn-around. Same API, three modes.
+
+
+
🔭
+
Always observable
+
Status, paginated logs, results, cancellation — over MCP, the SDK, and the CLI. Your assistant always knows what the cloud is doing.
+
+
+
🪶
+
Boring defaults
+
SQLite for state. stdio for transport. Zero hidden services. Runs on a laptop, in CI, and on a server.
+
+
+
+
+
+
Three faces, one runtime
+
Pick the entry point that fits — they all talk to the same dispatcher.
import { createClient } from"@agent-dispatch/sdk";
+
+const client = createClient({ configPath: "agentdispatch.config.json" });
+
+const { taskId } = await client.spawnCloudAgent({
+ instruction: "Audit every Lambda in this account for public invoke.",
+ runtime: "security-agent"
+});
+
+for await (const event of client.streamTask(taskId)) console.log(event);
+
+
+
+
$ npm install -g @agent-dispatch/cli
+
+$ agentdispatch check --config agentdispatch.config.json
+$ agentdispatch spawn "Investigate this stack trace across all services."
+$ agentdispatch logs <task-id> --follow
+$ agentdispatch result <task-id>
+
+
+
+
+
How it fits together
+
+ Your local AI assistant calls a tool. AgentDispatch picks a capability, persists the task,
+ invokes a worker in the cloud, and streams status and logs back through the same path.
+