Advanced Features5 min read

Using MCP Tools

Calling external tools and resources inside tasks

Once a server is configured, its tools become part of the agent’s working vocabulary: they show up alongside built-in tools, the model picks them when they fit the task, and every call flows through the same chat-based approval you already know. This page explains how discovery and calling work, how to control approval per tool, and how to write requests that reliably steer the agent to the right server.

How the agent discovers and calls MCP capabilities

When a task starts, Nexgile Code advertises every enabled tool from every connected server to the model, each with its name, description, and input schema — the same metadata you can inspect yourself under Settings → MCP Servers → server → Tools. Servers registered from cache are advertised too; the underlying process starts on the first actual call.

Calls surface in the chat as two agent tools:

use_mcp_tool — invokes an action. Carries server_name, tool_name, and an arguments object matching the tool’s schema.
access_mcp_resource — reads data. Carries server_name and a resource uri.

Results return to the model as text — and, when a server sends images (a browser screenshot, a rendered chart), those render directly in the chat and are passed to the model too, provided your model supports image input. While a call runs you’ll see a live status chip (Running → Completed or Error).

If the model asks for a tool that doesn’t exist or is disabled, the call fails fast with a message listing the tools that are available — the agent normally corrects itself on the next step.

The approval flow

By default every MCP call pauses the task:

Nexgile wants to use a tool on the github MCP server

with the tool name and full arguments shown for inspection, and Approve/Deny buttons. To let specific calls through without prompting, three switches have to line up:

Auto-approve master toggle on (Auto-Approving Actions).
The MCP auto-approve toggle on.
For tool calls: that tool’s Always allow checkbox, in the server’s Tools list. The checkbox only appears once the MCP auto-approve toggle is enabled, and it’s per tool — approving get_issue says nothing about create_issue.

Resource reads (access_mcp_resource) are gentler — they auto-approve with just steps 1 and 2, since reading a resource doesn’t act on the external system.

Disabling individual tools

Every tool row in the MCP Servers view has a toggle switch. Switching a tool off removes it from what the model sees — it can’t be called at all, and it stops costing prompt tokens. Use this to trim big servers down to the handful of tools you actually want, or to hard-block risky operations regardless of approval settings. The setting persists in the server’s disabledTools list in your MCP config.

Walkthrough: browser automation with the built-in Playwright server

The built-in Playwright server needs zero setup. With your app running locally, try:

Using the playwright MCP server, open http://localhost:3000, wait for the
dashboard to load, and take a screenshot. Then tell me if the nav bar
renders correctly.

What happens:

The agent calls the server’s navigation tool with your URL. First call on a cold start spawns the server (this one may take a while — its timeout is 240s for exactly this reason).
You approve the call (or it sails through if always-allowed).
The agent calls the screenshot tool; the image appears in the chat, and the agent describes what it sees.

This combines well with a code-fix loop: “open the page, screenshot it, fix the CSS bug you see, then screenshot again to confirm.”

Walkthrough: fetching an issue from a GitHub server

With a GitHub MCP server configured with your token:

Fetch issue #142 from acme/webapp using the github MCP server and
implement the fix it describes. Reference the issue number in your summary.

The agent calls the server’s issue-fetch tool, gets the issue title/body/comments back as text, and proceeds with normal code work — reading files, editing, running tests — grounded in the real ticket instead of your paraphrase of it.

Mode gating: the `mcp` tool group

MCP tools belong to the mcp tool group, and only modes that include the group can use them (How Tools Work):

Have MCP: Architect, Code, Ask, Debug, Spec Bootstrap, Spec Sync.
Don’t: Orchestrator (delegates everything), Tester, Reviewer, Shipper.

So an Ask-mode session can happily pull Jira tickets and query databases even though it can’t edit a single file. If you build a custom mode, add mcp to its groups list to grant access.

Writing requests that steer to MCP tools

The model chooses tools by matching your request against tool descriptions, so nudge it explicitly when it matters:

Name the server: “using the playwright MCP server…” beats “check the page in a browser”.
Name the operation when a server has many tools: “use the get_issue tool” removes all ambiguity.
Provide the identifiers the tool needs — repo, issue number, URL, channel name — so the agent doesn’t have to guess arguments.
If the agent keeps reaching for a built-in tool instead (e.g., trying to curl an API you have a server for), say so: “don’t use the terminal for this; use the MCP server.”

Timeouts and long-running calls

Each server has a response timeout — default 60 seconds, configurable per server from 1 second to 1 hour (the Network Timeout dropdown in its panel, or timeout in config). A call that exceeds it fails and the error is fed back to the model. For genuinely slow operations — cold Playwright starts, big query results, slow internal APIs — raise that server’s timeout rather than the global approach you’d use for terminal commands. Remember the first call to any lazily-started server includes its startup cost.

MCP Overview — what MCP is and the security model
Configuring MCP Servers — config files, per-server options, built-in Playwright
Auto-Approving Actions — the full auto-approve matrix
How Tools Work — tool groups and approvals in general