MCP in Junie: plugging your stack into JetBrains' agent

A coding agent that can only see the repository is working with half the picture. The bug is described in a ticket it cannot read. The behavior depends on data it cannot query. The fix touches an internal API documented in a wiki it has never heard of. So you become the courier, pasting context between systems: precisely the job you wanted the agent to take off your plate.

MCP is the way out. Junie acts as an MCP client, meaning any Model Context Protocol server (an issue-tracker bridge, a read-only database gateway, a thin wrapper around your internal API) becomes a tool the agent can call mid-task. If the protocol itself is new to you, the explainer covers the mechanics; what I care about here is what it changes in practice, and what it costs.

The standard matters more than the feature

The quiet win is that MCP is not a JetBrains technology. The same server you wire into Junie works in Claude Code, Gemini CLI, Goose, and most of the open agents. Write one internal MCP server for your platform and every agent surface in the company can consume it. That makes it infrastructure, not vendor configuration. In a landscape where the fashionable agent changes quarterly, the MCP server is the part of your investment that survives switching tools.

A setup pattern that holds up

Junie takes MCP server definitions as JSON configuration: per project under the .junie folder, or globally through the IDE settings. That part is mechanical. The pattern that separates useful from chaotic:

• Start read-only. A ticket-fetching server and a read-only database gateway remove most of the copy-paste from your day with near-zero blast radius. Servers that can write (comment, mutate, deploy) come later, if ever.
• Scope the credentials. The server runs with exactly the access you hand it. A database server gets a read-only role on a replica, never your admin connection string.
• Fewer tools, described better. Every exposed tool costs context tokens and adds one more wrong option to pick. Five sharp, well-described tools beat forty generic ones, the same discipline as designing agent tools anywhere else.

Wired this way, the task fix PROJ-1482 becomes one line: Junie pulls the ticket, reads the acceptance criteria, checks the actual schema against the replica, and writes code against reality instead of against your summary of it.

Every MCP server you add is simultaneously a capability and an attack surface: the protocol makes no distinction between the two.

The part that never makes the demo

Every server you connect widens two surfaces at once. The context surface: tool definitions and tool results flow into the model's window, so a chatty server bloats every request and can drown the code you are editing in noise. And the attack surface: tool results are untrusted input. A ticket description or wiki page fetched over MCP can carry text crafted to steer the agent, and prompt injection does not care that it arrived through a sanctioned protocol. Junie's approval flow is your checkpoint. The moment an MCP-fed task proposes a command you did not expect, treat it as a red-team scenario happening live, not as a quirk.

The honest limitation: MCP support inside IDE agents is still young. Expect servers that fail to start silently, tool descriptions that overwhelm the context window, and debugging that amounts to reading logs. Budget an afternoon per server, not five minutes.

My advice is deliberately boring. Name the one external system you paste from most (for most teams it is the issue tracker), wire in a read-only server for it, and live with that for two weeks. If the agent's first drafts start landing closer to done because it read the ticket itself, expand. If you cannot name the copy-paste a server would eliminate, you do not need that server, however good the demo looks.