openbox-mcp 1.0.1

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (3) hide show
  1. package/README.md +233 -0
  2. package/dist/bundle.js +35185 -0
  3. package/package.json +40 -0
package/README.md ADDED
@@ -0,0 +1,233 @@
1
+ # @openbox/mcp-adapter
2
+
3
+ Pure proxy MCP server that connects IDE runtimes to the OpenBox Bridge API.
4
+
5
+ ## Architecture
6
+
7
+ ```
8
+ IDE runtime / external MCP client
9
+ --> MCP transport (repo-local dev server OR remote server)
10
+ --> Bridge API
11
+ --> Supabase
12
+ --> Hatchet
13
+ --> Nango
14
+ --> native inbox / channel-ingress endpoints
15
+ --> Langfuse
16
+ ```
17
+
18
+ - Two supported shapes:
19
+ - repo-local stdio adapter, e.g. `npm --prefix packages/mcp-adapter run dev`
20
+ - remote always-on HTTP MCP server
21
+ - Transport depends on the runtime surface (`stdio` locally, HTTP remotely).
22
+ - Recommendation:
23
+ - repo work should use a project-local stdio config
24
+ - remote HTTP is secondary: use it for tenants, external runtimes, or explicit remote validation
25
+ - the local worker lane (`@openbox/terminal`) is adjacent to this package
26
+ and talks to Bridge API directly; it is not an MCP client
27
+ - The adapter is a transport layer only -- all business logic lives in Bridge API.
28
+ - Connection mode and inference mode are separate:
29
+ - a local runtime may execute models locally
30
+ - the same runtime may delegate inference remotely through `OpenRouter`
31
+ - MCP still carries identity, memory, tasks and traces through OpenBox
32
+ - Exfiltration Guard and PII masking are enforced at the adapter boundary:
33
+ - locally for repo-local runtimes
34
+ - on the remote MCP server for remote HTTP clients
35
+ - remote HTTP MCP clients authenticate to the adapter with `Authorization: Bearer`;
36
+ the local stdio lane reads the runtime key from env, then the project-local
37
+ `.openbox/config.json` when present, and finally `~/.openbox/config.json`;
38
+ in both cases the adapter authenticates to Bridge API with the configured runtime key
39
+
40
+ ## Setup
41
+
42
+ ```bash
43
+ npx @openbox/mcp-adapter setup --key=<agent-api-key> --project=/path/to/repo
44
+ ```
45
+
46
+ The setup CLI:
47
+ 1. Validates the API key against Bridge API
48
+ 2. Detects supported IDE runtimes
49
+ 3. Creates `~/OpenBox/` workspace with standard structure
50
+ 4. Writes local stdio IDE config plus, when `--project` is provided, a project `.mcp.json`
51
+ 5. Generates `guardrails.yaml` with sensible defaults
52
+
53
+ For repo-local work, the canonical path is the checked-in
54
+ [repo-level `.mcp.json`](../../.mcp.json).
55
+
56
+ When `setup --project` targets a repo that contains `packages/mcp-adapter`,
57
+ the generated `.mcp.json` uses that local adapter over `stdio`, preferring:
58
+
59
+ 1. `node packages/mcp-adapter/dist/terminal.js` when the built adapter is present
60
+ 2. `npm --prefix packages/mcp-adapter run --silent dev` when only source is present
61
+ 3. published `@openbox/mcp-adapter` as the last fallback
62
+
63
+ Use remote HTTP only when you explicitly want the always-on deployed MCP server.
64
+
65
+ ## Canonical Local Path
66
+
67
+ For this repo, the default project path is:
68
+
69
+ 1. Open the repo with a client that supports project MCP config
70
+ 2. Let the repo-level `.mcp.json` start the local adapter over `stdio`
71
+ 3. Keep HTTP MCP as an explicit opt-in, not the default repo transport
72
+
73
+ This keeps project work aligned with the checked-in adapter source and avoids
74
+ making the remote MCP endpoint the silent default inside the repo.
75
+
76
+ ## Remote HTTP Path
77
+
78
+ Remote HTTP MCP remains supported, but it is not the canonical repo path.
79
+
80
+ - Use it for tenant environments and external runtimes
81
+ - Use it for remote liveness checks and interoperability testing
82
+ - Configure it explicitly via IDE/global config or `--url=<remote-mcp-url>`
83
+
84
+ ## Source Of Truth
85
+
86
+ - Architecture: [`ADR-013`](../../agent-os/docs/decisions/ADR-013-bridge-api-adapters-conectividad.md)
87
+ - Runtime boot contract: [`runtime-adapters.md`](../../agent-os/docs/supporting/concepts/runtime-adapters.md)
88
+ - Onboarding spec: [`mcp-onboarding`](../../agent-os/docs/specs/mcp-onboarding/README.md)
89
+ - Repo-level adapter surface: [`agent-os/adapters/README.md`](../../agent-os/adapters/README.md)
90
+
91
+ ## Current Files
92
+
93
+ | Path | Purpose |
94
+ |---|---|
95
+ | `src/index.ts` | MCP server implementation (30 tools + 8 resources) |
96
+ | `src/terminal.ts` | CLI entrypoint (`setup` or server mode) |
97
+ | `src/setup.ts` | Onboarding flow: IDE detection, workspace creation, config install |
98
+ | `boot-hook.sh` | Local boot helper for a compatible IDE runtime |
99
+ | `scripts/stdio-smoke.mjs` | Reproducible stdio smoke against the live Bridge API |
100
+ | `scripts/http-smoke.mjs` | Reproducible Streamable HTTP smoke against the live Bridge API |
101
+ | `scripts/xai-remote-mcp-smoke.mjs` | Reproducible xAI Responses API smoke against the remote OpenBox MCP |
102
+ | `package.json` | Build and runtime metadata |
103
+ | `tsconfig.json` | TypeScript config |
104
+
105
+ ## Tools Summary (28 total + 8 dynamic resources)
106
+
107
+ | Category | Tools |
108
+ |----------|-------|
109
+ | **Boot & Identity** | `openbox_boot`, `openbox_list_agents`, `openbox_assume_role` |
110
+ | **Memory** | `openbox_get_memory`, `openbox_save_memory` (PII masked), `openbox_search_memory` — with scope and optional user/session narrowing |
111
+ | **Tasks** | `openbox_list_tasks`, `openbox_create_task`, `openbox_update_task`, `openbox_run_task`, `openbox_delegate_task` |
112
+ | **Goals** | `openbox_list_goals`, `openbox_get_goal`, `openbox_create_goal`, `openbox_update_goal`, `openbox_close_goal` |
113
+ | **Workflows** | `openbox_trigger_workflow`, `openbox_list_workflows`, `openbox_get_workflow`, `openbox_create_workflow`, `openbox_update_workflow`, `openbox_validate_workflow`, `openbox_get_workflow_runs` |
114
+ | **Tracing** | `openbox_trace` |
115
+ | **Files** | `openbox_read_file` (tracked), `openbox_list_files` |
116
+ | **Security** | `openbox_revoke_current_key`, `openbox_doctor` (self-test) |
117
+ | **Diagnostics** | `openbox_diagnostics` |
118
+ | **Host** | `openbox_host_docker_ps`, `openbox_host_docker_logs`, `openbox_host_system_status`, `openbox_host_exec` |
119
+
120
+ Reality check:
121
+ - the adapter exposes `openbox_assume_role`
122
+ - the Bridge contract for role switching is `X-Agent-Id` + `POST /auth/assume-role`
123
+ - the OpenBox repo implements that path locally; live availability depends on the deployed backend revision
124
+
125
+ ## Runtime Notes
126
+
127
+ - Config source precedence: `OPENBOX_API_KEY` / `API_KEY` env, then project-local `.openbox/config.json`, then `~/.openbox/config.json`
128
+ - API key env aliases: `OPENBOX_API_KEY` or `API_KEY`
129
+ - Supported URL order: `internalBaseUrl` / `OPENBOX_INTERNAL_BASE_URL` first when present, then `baseUrl`
130
+ - Project repo work should prefer `.mcp.json` + local stdio; `mcpUrl` is mainly for explicit remote HTTP installs
131
+ - Local policy source: `guardrails.yaml` in the project root
132
+ - A local subagent is a `child run`, not a sovereign OpenBox agent
133
+ - Loading another identity with `openbox_boot` is valid for context hydration
134
+ - Canonical parallel agent execution still goes through dispatch + real runtimes
135
+ - `openbox_diagnostics` verifies `/boot`, `/agents`, `/tasks`, `/memory`, version compatibility, host access and guardrails state
136
+ - `openbox_doctor` runs comprehensive self-tests including exfiltration guard and PII masking
137
+ - Dynamic MCP resource templates:
138
+ - `openbox://agent/{agent_id}/identity`
139
+ - `openbox://agent/{agent_id}/memory{?scope,user_id,session_id,limit,offset}`
140
+ - `openbox://agent/{agent_id}/tasks{?status,limit,offset}`
141
+ - `openbox://workflow/{workflow_id}`
142
+ - `openbox://workflow/{workflow_id}/runs{?status,limit,offset}`
143
+ - `stdio` mode uses newline-delimited JSON-RPC, not `Content-Length` framing
144
+ - Reproducible smoke: `npm run smoke:stdio` / `npm run smoke:stdio:taskflow` / `npm run smoke:http`
145
+
146
+ ## Security Features
147
+
148
+ ### Exfiltration Guard
149
+
150
+ Detects and blocks attempts to upload sensitive data:
151
+
152
+ | Sensitivity | Patterns | Action |
153
+ |-------------|----------|--------|
154
+ | Critical | Private keys, API tokens, cloud credentials | BLOCKED |
155
+ | Secret | Passwords, API secrets, access tokens, JWTs | BLOCKED |
156
+ | PII | DNI/NIE, email, phone, credit card | AUTO-MASKED |
157
+
158
+ ### PII Masking
159
+
160
+ | Pattern | Mask |
161
+ |---------|------|
162
+ | DNI espanol (`12345678A`) | `[DNI_MASKED]` |
163
+ | Email (`john@example.com`) | `[EMAIL_MASKED]` |
164
+ | Telefono ES (`+34 612 345 678`) | `[PHONE_MASKED]` |
165
+ | Tarjeta credito | `[CARD_MASKED]` |
166
+
167
+ ### Guardrails for Workflows
168
+
169
+ ```yaml
170
+ workflows:
171
+ require_human_approval:
172
+ - "sdr-pipeline"
173
+ - "dispatch"
174
+ local_execution_only:
175
+ - "feature-lifecycle"
176
+ deny:
177
+ - "deprecated-workflow"
178
+ ```
179
+
180
+ ### File System Security
181
+
182
+ - Project folder isolation: cannot read/list files outside project folder
183
+ - Guardrails integration: respects `ignore_patterns` and `readonly_patterns`
184
+ - Session tracking: file reads tracked for 5 minutes TTL
185
+
186
+ ## Commands
187
+
188
+ ```bash
189
+ npm install
190
+ npm run build
191
+ npm run dev
192
+ npx @openbox/mcp-adapter setup --project /path/to/project
193
+ npm run smoke:stdio
194
+ npm run smoke:stdio:taskflow
195
+ npm run smoke:http
196
+ XAI_PREFLIGHT_ONLY=1 npm run smoke:xai
197
+ XAI_API_KEY=... npm run smoke:xai
198
+ ```
199
+
200
+ ## xAI Remote MCP Smoke
201
+
202
+ Use this when you want to verify that Grok can consume the live OpenBox MCP via
203
+ xAI's Remote MCP support.
204
+
205
+ Environment variables:
206
+
207
+ - `XAI_API_KEY` - required for the full xAI call
208
+ - `XAI_MODEL` - optional, defaults to `grok-4.20-beta-latest-non-reasoning`
209
+ - `XAI_BASE_URL` - optional, defaults to `https://api.x.ai/v1`
210
+ - `OPENBOX_MCP_URL` - optional, defaults to `https://mcp.example.com/mcp`
211
+ - `OPENBOX_ALLOWED_TOOL_NAMES` - optional CSV, defaults to `openbox_diagnostics`
212
+ - `OPENBOX_MCP_AUTH` - optional full `Authorization` header value for the MCP server
213
+ - `OPENBOX_MCP_EXTRA_HEADERS` - optional JSON object with extra MCP headers
214
+ - `XAI_INPUT` - optional custom prompt sent to Grok
215
+
216
+ Examples:
217
+
218
+ ```bash
219
+ # Verify only that the remote MCP endpoint is alive and answers initialize
220
+ XAI_PREFLIGHT_ONLY=1 npm run smoke:xai
221
+
222
+ # Full xAI -> Remote MCP -> OpenBox check
223
+ XAI_API_KEY=... \
224
+ OPENBOX_ALLOWED_TOOL_NAMES=openbox_diagnostics \
225
+ npm run smoke:xai
226
+ ```
227
+
228
+ ## Rules
229
+
230
+ - Keep this package as a transport adapter only.
231
+ - No Supabase client, no service role key, no product state cache.
232
+ - If a capability belongs to OpenBox business logic, implement it in Bridge API, not here.
233
+ - Exfiltration Guard is enforced at the adapter level -- cannot be bypassed by Bridge API.