Repository navigation
mcp: load servers from <agentDir>/mcp.json and bind extensions - #60
Open
hello-pollux wants to merge 2 commits into
Open
hello-pollux wants to merge 2 commits into
hello-pollux wants to merge 2 commits into
Conversation
MCP was configured but dead: pi 1.x loads the MCP extension from the app
layer, and this harness did neither half of what that needs.
1. **Nothing read the config.** The extension context has no `agentDir`,
so pi's default loader resolves `mcp.json` against `~/.pi/agent` and
never saw this bot's file. `src/mcp/loadAgentMcpConfig.ts` reads
`<agentDir>/mcp.json` synchronously (pi's `loadConfig` is sync), builds
typed stdio/HTTP configs, keeps disabled entries listed, and collects
problems in `errors` so one bad entry can't drop the rest.
2. **No extension ever started.** pi's app layer calls
`session.bindExtensions()` after creating a session; that is what emits
`session_start`. Without it, extensions that register work at session
start (MCP connecting is one) silently do nothing. Called with
`mode: "print"` (headless — `hasUI: false`) and an error logger.
Wiring mirrors pi's own app: the factory is registered as a built-in and
activated through `additionalExtensionPaths: ["builtin:mcp"]`.
Verified end to end: with a spec MCP server declared, the session's active
tools include mcp__website_spec__{search,list_topics,get_topic,
get_checklist,get_categories,get_changes}. 7 new tests cover the loader;
full suite 113 pass, tsc clean.
…Access The test file indexed servers[0] and destructured a possibly-empty array, so `bun run typecheck` failed on six TS18048/TS2532 errors and CI has been red on this branch since it was opened. Narrow through an onlyServer() helper that throws instead of asserting.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
MCP was configured but dead. pi 1.x loads its MCP extension from the app layer, and this harness did neither half of what that requires.
1. Nothing read the config
The extension context has no
agentDir, so pi's default loader resolvesmcp.jsonagainst~/.pi/agentand never saw this bot's file (I confirmed it:ctx.agentDir === undefined).src/mcp/loadAgentMcpConfig.tsreads<agentDir>/mcp.jsonsynchronously (pi'sloadConfigis sync), builds typed stdio/HTTP configs without casts, keeps disabled entries listed (enabled: false), and collects problems inerrorsso one bad entry can't drop the rest.2. No extension ever started
pi's app layer calls
session.bindExtensions()after creating a session — that call is what emitssession_start. Without it, any extension that registers work at session start silently does nothing (MCP connecting is one). Called here withmode: "print"(headless:hasUI: false, so terminal-only paths are skipped) and an error logger.Wiring mirrors pi's own app: the factory is registered as a built-in (
{name, factory, replaceable, builtin}) and activated viaadditionalExtensionPaths: ["builtin:mcp"].Verification
With a real MCP server declared (
https://mcp.specification.website/mcp,exposure: direct), the session's active tool list came back as:bun test: 113 pass, 0 failtsc --noEmit: cleanNote for review
The
bindExtensionscall is a behavior change beyond MCP — it starts the extension lifecycle this harness had been skipping. Worth a look on its own merits; nothing in the existing tests regressed, and the memory extension'sremembertool still registers (it does so at load time, not session start).