Skip to content
Nx IDEDocs

Advanced Features5 min read

MCP Overview

What the Model Context Protocol adds to the agent

Out of the box, Nexgile Code works with what is on your machine: your files, your terminal, your git history. The Model Context Protocol (MCP) is how you extend it beyond that boundary. MCP is an open standard for connecting AI agents to external tools and data sources — issue trackers, chat platforms, databases, browsers, internal APIs — through small programs called MCP servers. Nexgile Code is a full MCP client: connect a server, and every tool that server offers becomes something the agent can call mid-task, subject to the same approval flow as any built-in tool.

What MCP adds in practice

Section titled “What MCP adds in practice”

A few examples of what connected servers make possible:

Server What the agent can then do
GitHub Fetch issues and PRs, read review comments, file new issues
Jira Pull ticket details into a task, update ticket status
Slack Post a summary to a channel when a job finishes
Database servers (Postgres, MySQL, …) Inspect schemas, run read queries to ground its answers in real data
Playwright (built in) Drive a real browser — navigate, click, fill forms, take screenshots of your running app
Internal services Anything your team wraps in an MCP server: deploy status, feature flags, docs search

The Playwright server ships inside Nexgile Code, so browser automation works without any setup — the first time the agent calls one of its tools, the server starts automatically. Everything else you connect yourself with a few lines of JSON; see Configuring MCP Servers.

Architecture in brief

Section titled “Architecture in brief”

MCP has two sides:

  • The client — Nexgile Code. It reads your server configuration, launches or connects to each server, asks each one what it offers, and advertises those capabilities to the model during tasks.
  • The servers — independent programs, each wrapping one system. A server exposes two kinds of capability:
    • Tools — actions the agent can invoke with arguments (“create an issue”, “run this query”, “take a screenshot”). Called via the agent’s use_mcp_tool tool.
    • Resources — readable data addressed by URI (“the contents of ticket PROJ-142”). Read via access_mcp_resource.

Servers are namespaced: two servers can both offer a search tool without colliding, because every call names the server it targets. When the same server name exists in both your global and project configuration, the project version wins.

The three transports

Section titled “The three transports”

How the client reaches a server depends on its transport. Nexgile Code supports all three defined by the standard:

  • stdio — Nexgile Code launches the server as a local child process and talks to it over stdin/stdout. This is the common case for community servers (npx …, uvx …, a local script). The server runs on your machine with your environment.
  • SSE (Server-Sent Events) — the server is already running somewhere (often remote) and the client connects to it over HTTP with a streaming event channel.
  • Streamable HTTP — the newer HTTP-based transport; also for servers reachable at a URL, using streamable HTTP request/response semantics.

You pick the transport per server in configuration: local tools use stdio (a command to run), remote services use sse or streamable-http (a url to connect to). The details and full config syntax are on Configuring MCP Servers.

The lifecycle of an MCP call

Section titled “The lifecycle of an MCP call”

Here’s what actually happens when MCP participates in a task:

  1. Startup — Nexgile Code reads your global and project configs and registers each server. Servers whose tool inventory is already cached don’t even spawn yet; they start lazily on first use.
  2. Advertising — at each step of a task, every enabled MCP tool is offered to the model alongside the built-in tools, with its description and input schema.
  3. The call — when the model picks one, the chat pauses for your approval, showing server, tool, and arguments. On approval, the call runs with a live status chip (Running → Completed or Error), bounded by that server’s timeout.
  4. The result — text (and images, e.g. screenshots) comes back into the conversation, and the agent reasons over it like any other tool result — often chaining into file edits or commands.

The result is that external systems stop being copy-paste islands: the ticket, the query result, the screenshot land directly in the loop where the agent can act on them.

MCP and token cost

Section titled “MCP and token cost”

Every advertised tool costs prompt tokens on every request, and some servers expose dozens of tools. Two levers keep this in check:

  • Toggle off individual tools you don’t need in the server’s Tools list — they vanish from the model’s view entirely.
  • If you don’t use MCP at all, switch off Enable MCP Servers so nothing is advertised.

Security and approval model

Section titled “Security and approval model”

MCP servers are code that runs with real credentials against real systems, so Nexgile Code keeps you in the loop:

  • Every MCP call prompts by default. When the agent wants to use a server, the chat pauses on “Nexgile wants to use a tool on the server MCP server”, showing the tool name and the exact arguments. Nothing runs until you approve.
  • Auto-approval is deliberately narrow. Even with auto-approve enabled, an MCP tool call is only skipped past the prompt when both the MCP auto-approve toggle is on and that specific tool’s Always allow checkbox is checked in the MCP Servers view. You allowlist tool by tool, not server by server. See Auto-Approving Actions.
  • Per-server controls. Each server can be disabled entirely, given a response timeout, or have individual tools switched off so the model never even sees them (Using MCP Tools covers these).
  • A master switch. The Enable MCP Servers toggle in Settings → MCP Servers turns the whole subsystem on or off. Off means no server definitions are sent to the model at all — which also saves tokens if you don’t use MCP.

Where to see your servers

Section titled “Where to see your servers”

Open Settings → MCP Servers to see every configured server with its live status. Expanding a server shows its Tools, Resources, and Logs tabs — the Logs tab is the first place to look when a server misbehaves. From the same view you can restart a server, adjust its timeout, and manage per-tool permissions.

Section titled “Related”