Summary
When an LSP (e.g. gopls) or MCP is not available at session start, the agent silently misses those capabilities for the entire session — even if the tool becomes available later (e.g. after the agent follows install instructions from AGENTS.md).
Current behaviour
LSPs and MCPs are resolved once at session startup. If gopls is not yet installed when the session begins, the agent never gains access to it — even after installing it mid-session by following instructions in AGENTS.md (or similar onboarding docs). There is no retry, re-probe, or re-initialisation mechanism.
Expected behaviour
The agent should re-attempt to connect to any configured-but-missing LSP or MCP:
- After each tool call (or at least after a shell/exec tool call that may have installed new software), or
- At the start of each new turn, so that tools installed during a session become available without requiring a full restart.
Motivation / example
AGENTS.md in a repo can include setup instructions for required tooling — for example:
# Install Go and gopls
curl -fsSL "https://go.dev/dl/go1.26.0.linux-amd64.tar.gz" | tar -C /usr/local -xz
go install golang.org/x/tools/gopls@latest
ln -sf /root/go/bin/gopls /usr/local/bin/gopls
An agent can read AGENTS.md and faithfully execute those commands — Go and gopls end up installed and on PATH — but the gopls MCP/LSP toolset remains unavailable for the rest of the session because the runtime never re-checked.
This creates a pattern that should work but doesn't: let the repo describe its own tooling requirements, let the agent install them, and then let the agent use them immediately.
Suggested fix
- After any tool call (especially shell/exec), re-probe configured LSP/MCP endpoints that previously failed to connect.
- Alternatively, retry on each new user turn with a short timeout.
- This would also naturally support cases where an MCP server takes a moment to start up after being launched in a background job.
Environment
Observed while working in the docker/agentic-platform repo: AGENTS.md contains Go + gopls install instructions, the agent successfully installed both, but gopls-based tools remained unavailable for the remainder of the session.
Summary
When an LSP (e.g.
gopls) or MCP is not available at session start, the agent silently misses those capabilities for the entire session — even if the tool becomes available later (e.g. after the agent follows install instructions fromAGENTS.md).Current behaviour
LSPs and MCPs are resolved once at session startup. If
goplsis not yet installed when the session begins, the agent never gains access to it — even after installing it mid-session by following instructions inAGENTS.md(or similar onboarding docs). There is no retry, re-probe, or re-initialisation mechanism.Expected behaviour
The agent should re-attempt to connect to any configured-but-missing LSP or MCP:
Motivation / example
AGENTS.mdin a repo can include setup instructions for required tooling — for example:An agent can read
AGENTS.mdand faithfully execute those commands — Go andgoplsend up installed and onPATH— but the gopls MCP/LSP toolset remains unavailable for the rest of the session because the runtime never re-checked.This creates a pattern that should work but doesn't: let the repo describe its own tooling requirements, let the agent install them, and then let the agent use them immediately.
Suggested fix
Environment
Observed while working in the
docker/agentic-platformrepo:AGENTS.mdcontains Go + gopls install instructions, the agent successfully installed both, but gopls-based tools remained unavailable for the remainder of the session.