feat(mcp): add resources and prompts support

[addyCooks]

Closes #1162.

Description

Adds MCP resources and prompts support to MCPClient, and wires both into the interactive UI: resources join the existing @-mention/file-completion system, prompts dispatch as /mcp:<server>:<prompt> slash commands that feed the model the same way a custom command does. Phases 1 and 2 of #1162; sampling/elicitation/roots (phase 3) are explicitly out of scope for this PR.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update

Changeset

• Added a changeset (pnpm changeset) describing this change for the changelog

Testing

Automated Tests

• New features include passing tests in .spec.ts/tsx files
• All existing tests pass (pnpm test:all completes successfully)
• Tests cover both success and error scenarios

Manual Testing

• Tested with Ollama
• Tested with OpenRouter
• Tested with OpenAI-compatible API
• Tested MCP integration (if applicable)

Checklist

• If this was for an open issue, I was assigned to it
• Code follows project style guidelines
• Self-review completed
• Documentation updated (if needed)
• No breaking changes (or clearly documented)
• Appropriate logging added using structured logging (see CONTRIBUTING.md)

[will-lamerton]

Nice work, and thanks for keeping sampling/elicitation out of scope. Verified locally: tsc clean, biome clean, knip clean, all 88 tests in the touched specs pass. A few things to fix before this can go in.

Blocking

1. The branch doesn't merge. Conflicts against current main in source/mcp/mcp-client.ts, source/mcp/mcp-client.spec.ts, and docs/configuration/mcp-configuration.md. Please rebase.

2. Resource mentions bypass the file-mention size guard. The new RESOURCE case in source/utils/prompt-processor.ts inlines the whole body unconditionally. The FILE case right above it deliberately doesn't - over FILE_MENTION_INLINE_MAX_LINES it emits a head preview plus a read_file(...) hint, with the comment "so a single @-mention can't flood the conversation". One @-mention of a large MCP resource dumps everything into context. Same cap should apply.

3. The server name gets stamped twice. source/components/user-input.tsx passes fileCompletions[selectedFileIndex]?.displayPath as the resourceName argument, but displayPath is `${resource.name} (${resource.serverName})`. So the chip reads [@api-docs (docs-server)] and the assembled header becomes === MCP Resource: api-docs (docs-server) (from docs-server) ===. The unit test passes a bare 'resource.txt' there, so it doesn't catch this. Pass resource.name through instead of the display string.

4. Multi-message prompts collapse into one user turn. getPrompt preserves role on each message, then mcp-prompt-handler.ts joins every message's text with \n\n and sends it as a single onHandleChatMessage. A few-shot prompt with assistant turns - a normal MCP prompt shape - loses its structure.

5. Capability gating is claimed but not implemented. The commit message and changeset both say discovery is "gated on the server's declared capabilities", but connectToServer calls listResources() / listPrompts() unconditionally and swallows the failure. That's two extra round trips per server that supports neither, and the "MCP server does not support resources" log line is a guess. client.getServerCapabilities() is available post-connect - either use it or fix the claim.

Non-blocking

• handleResourceMention returns null on any read failure, so a server error, a timeout, and a missing resource all look identical: the mention silently does nothing. Mirrors handleFileMention, but a remote read failing silently is a worse trade than a local file not existing.
• Positional args beyond the prompt's declared arguments are dropped with no warning, as are all args when the prompt declares none.
• Issue #1162's phase 2 called for prompts to go through source/commands/lazy-registry.ts; this intercepts in handleSlashCommand instead. Fine functionally (custom commands are correctly checked first), but worth a note on why.
• No tests cover the user-input.tsx wiring. encodeMCPResourcePath / decodeMCPResourcePath and the merged completion list are the riskiest new code here and are only exercised manually.
• getServerInfo now returns resourceCount / promptCount, but neither /mcp nor /doctor shows them.
• docs/battlemap.md is the parity claim this closes, and it isn't updated.

Solid

Server-scoped readResource / getPrompt rather than cross-server URI search, with a test proving two same-named prompts route correctly. Text vs blob discrimination by key presence rather than a nonexistent type field - correct per the MCP schema and directly tested. Binary blocks become a note instead of raw base64. Discovery failures can't break tool discovery. disconnect() clears the new maps. Changeset names the right package.

[addyCooks]

Thanks @will-lamerton,
for the thorough review,

here's everything addressed:

Blocking

1. Rebased onto main; conflicts resolved.
2. Resource mentions now share the same FILE_MENTION_INLINE_MAX_LINES guard as files,
   large resources get a head preview instead of being dumped in full.
3. Fixed passes resource.name instead of the display string, so the chip and header no longer double-stamp the server name.
4. getPrompt's per-message roles are now preserved: earlier turns splice into history as-is, and only the final user turn triggers the chat round-trip.
5. Discovery is now actually gated on client.getServerCapabilities() listResources/listPrompts only fire when the server declares that capability.

Non-blocking

• A failed resource read now surfaces via logError instead of failing silently.
• Extra/unexpected positional args now warn instead of vanishing.
• Added a comment explaining why prompts intercept in handleSlashCommand instead of lazy-registry.ts.
• Added test coverage for the user-input.tsx wiring (encode/decode + selection flow).
• /mcp and /doctor now show resource/prompt counts and names.
• Updated docs/battlemap.md's parity claim to call out resources/prompts specifically.

[will-lamerton]

Rebase done — I merged current main in and resolved the user-input.tsx conflict myself (2e4991a). main had rewritten that component's render layer, so I took main's version wholesale and re-applied the seven MCP-resource additions on top; the branch now differs from main by exactly the 25 files and 2265/52 lines this PR intended, with main a clean ancestor.

Re-verified all five blocking items in the code rather than taking the reply at face value — the size guard, the bare resource.name, the capability gating via getServerCapabilities(), and the historyMessages splice are all genuinely there, and the non-user-terminal prompt case you handled on top of #4 is a nice catch I hadn't asked for. All seven non-blocking items addressed too.

Local on the merged head: tsc clean, biome clean, knip clean, 292 tests pass across the touched specs plus the user-input and app-util suites. Thanks for the thorough turnaround.

[addyCooks]

Thanks @will-lamerton,
and thanks for handling the user-input.tsx conflict yourself after the render-layer rewrite,
and for sorting the write-file.tsx imports.
Glad the non-user-terminal prompt case was useful.

Since this covered phases 1 and 2 of #1162,
I'm happy to pick up phase 3 (sampling / elicitation / roots) as a separate PR if that's wanted.
Otherwise I'll open a tracking issue for it.