Show MCP and LSP connections in Braid #46

New issue

Open

opened 2026-09-26 09:47:10 -04:00 by cmoriarty · 1 comment

cmoriarty commented

2026-09-26 09:47:10 -04:00

Owner

First, are the braid agents properly connected to the MCP and LSP servers? If not, we should probably fix that. Then we should visually show on the braid GUI the MCP/LSP connections, so its more clear what is available.

image.png

73 KiB

cmoriarty commented

2026-09-29 02:28:39 -04:00

Author

Owner

Are the agents connected? A run's agents have one MCP server and no LSP. The screenshot above is opencode run by hand, which reads ~/.config/opencode: four MCP servers and three language servers. Runs never see that config, because each run gets its own HOME and its own opencode.json.

MCP. A run whose subagent roster includes browser (the default) gets Playwright: @playwright/mcp 0.0.80 with headless Chromium. Only the browser subagent can call it; build and the other subagents have playwright* switched off. The run live on production now (run 29) has its playwright-mcp process up, about 113 MB, although it hasn't used it.
Forgejo and ios-simulator are defined in osf/engine/shape.py, but nothing attaches them. No pipeline declares mcp:, and nothing turns a node's mcp: into the run's config. A node that declared mcp: [forgejo] would get the six Forgejo tool names switched on with no server behind them.
LSP and formatters. opencode 1.18.21 turns these on only when the config has an lsp or formatter entry, and the run config has neither. Every production run logs all LSPs are disabled and all formatters are disabled at startup.

Should runs use more? Mostly no. This is going by the tool calls in the 8 runs whose logs are still on production (runs 17 to 29): 1,474 bash calls, 893 reads and 565 edits or writes.

LSP: not yet. It would put each edit's type errors into the edit's result. Across the 8 runs it would have caught a handful of errors behind about 8 failed builds and test runs. Examples: run 26's TS1005 in game.test.ts, which failed three builds in a row, and run 25's queryAllByClassName, a testing-library query that doesn't exist.
- Agents make .venv and node_modules partway through a step, so until then every import would show as an error.
- The image has no language servers, so opencode would download them into each run's own home (#67).
- The repositories are small (scratch is 14 Python and 9 TS/TSX files), so navigation doesn't need it.
- A typecheck and lint in the scripted test steps (#104) would catch the same errors once per step. Worth revisiting once dependencies are installed before apply.
Playwright: keep it, then prove it. All 6 Playwright calls on production failed. They were all in run 22, the one that couldn't find Chrome, and no run has called the browser since the --browser chromium fix. What's needed next is a run with a UI change, not more servers.
Forgejo MCP: no. AGENTS.md keeps git and the forge away from agents, and osfd already writes the brief, opens the PR and merges in scripted steps. Attaching the MCP would put a token within an agent's reach and add about 1,600 tokens to every turn, even allowlisted.
searx or docs search: no sign of need yet. Implementation steps already have webfetch, and no run called it. The curls all went to the run's own app on 127.0.0.1.

Where the time goes instead.

About 11% of bash calls (156) went on agents starting their own app, polling it with sleep and curl, and killing it.
About 8% (116) went on hunting for dependencies. Run 22 even looked for fastapi in osfd's own virtualenv.
Two follow-ups:
- a scripted step that installs the repository's dependencies
- a Braid tool that serves the app on the run's port
The tool is better as an opencode custom tool (tool/*.js, beside the run's coerce-args plugin) than as another MCP server.

For the panel. Each run's opencode answers GET /mcp and GET /lsp, so the console can show exactly what a run has. Today that's playwright · connected and LSP · off, not the list in the screenshot above.

**Are the agents connected?** A run's agents have one MCP server and no LSP. The screenshot above is opencode run by hand, which reads `~/.config/opencode`: four MCP servers and three language servers. Runs never see that config, because each run gets its own `HOME` and its own `opencode.json`. - **MCP.** A run whose subagent roster includes `browser` (the default) gets Playwright: `@playwright/mcp` 0.0.80 with headless Chromium. Only the `browser` subagent can call it; `build` and the other subagents have `playwright*` switched off. The run live on production now (run 29) has its `playwright-mcp` process up, about 113 MB, although it hasn't used it. - **Forgejo and ios-simulator** are defined in `osf/engine/shape.py`, but nothing attaches them. No pipeline declares `mcp:`, and nothing turns a node's `mcp:` into the run's config. A node that declared `mcp: [forgejo]` would get the six Forgejo tool names switched on with no server behind them. - **LSP and formatters.** opencode 1.18.21 turns these on only when the config has an `lsp` or `formatter` entry, and the run config has neither. Every production run logs `all LSPs are disabled` and `all formatters are disabled` at startup. **Should runs use more?** Mostly no. This is going by the tool calls in the 8 runs whose logs are still on production (runs 17 to 29): 1,474 bash calls, 893 reads and 565 edits or writes. - **LSP: not yet.** It would put each edit's type errors into the edit's result. Across the 8 runs it would have caught a handful of errors behind about 8 failed builds and test runs. Examples: run 26's TS1005 in `game.test.ts`, which failed three builds in a row, and run 25's `queryAllByClassName`, a testing-library query that doesn't exist. - Agents make `.venv` and `node_modules` partway through a step, so until then every import would show as an error. - The image has no language servers, so opencode would download them into each run's own home (#67). - The repositories are small (scratch is 14 Python and 9 TS/TSX files), so navigation doesn't need it. - A typecheck and lint in the scripted test steps (#104) would catch the same errors once per step. Worth revisiting once dependencies are installed before `apply`. - **Playwright: keep it, then prove it.** All 6 Playwright calls on production failed. They were all in run 22, the one that couldn't find Chrome, and no run has called the browser since the `--browser chromium` fix. What's needed next is a run with a UI change, not more servers. - **Forgejo MCP: no.** `AGENTS.md` keeps git and the forge away from agents, and osfd already writes the brief, opens the PR and merges in scripted steps. Attaching the MCP would put a token within an agent's reach and add about 1,600 tokens to every turn, even allowlisted. - **searx or docs search: no sign of need yet.** Implementation steps already have `webfetch`, and no run called it. The `curl`s all went to the run's own app on 127.0.0.1. **Where the time goes instead.** - About 11% of bash calls (156) went on agents starting their own app, polling it with `sleep` and `curl`, and killing it. - About 8% (116) went on hunting for dependencies. Run 22 even looked for `fastapi` in osfd's own virtualenv. - Two follow-ups: - a scripted step that installs the repository's dependencies - a Braid tool that serves the app on the run's port The tool is better as an opencode custom tool (`tool/*.js`, beside the run's `coerce-args` plugin) than as another MCP server. **For the panel.** Each run's opencode answers `GET /mcp` and `GET /lsp`, so the console can show exactly what a run has. Today that's `playwright · connected` and `LSP · off`, not the list in the screenshot above.

cmoriarty referenced this issue

2026-09-29 02:36:06 -04:00

A run installs the repository's dependencies in a scripted step, so agents don't spend their steps hunting for them #109

cmoriarty referenced this issue

2026-09-29 02:36:21 -04:00

Agents serve the app through one Braid tool that starts it on the run's port, waits until it answers, shows its log and stops it #110