MCP Servers

MCP Servers let you give Overcut agents access to tools provided by external Model Context Protocol servers. Whether you need to query a database, call a third-party API, or interact with internal services, MCP servers bridge the gap between your agents and the outside world.

Overview

External Tool Access

Connect any MCP-compatible server so agents can use its tools during workflow execution.

Two Transport Modes

Support for local stdio servers (command-based) and remote SSE/HTTP servers (URL-based).

Tool Allowlists

Restrict which tools an agent can use from a server to keep execution focused and secure.

Per-Agent Assignment

Assign specific MCP servers to individual agents so each agent gets exactly the tools it needs.

Creating an MCP Server

Open MCP Servers

Navigate to MCP Servers in the workspace sidebar.

Create a new server

Click New MCP Server and enter a name (minimum 2 characters). Server names must be unique within the workspace and cannot contain __ (double underscore), which is reserved for internal tool namespacing.

Add the server configuration

Provide a JSON configuration object. The config must contain either a command field (for a local stdio server) or a url field (for a remote SSE/HTTP server) — not both. See the Configuration Reference below for details.

Set allowed tools (optional)

Enter a comma-separated list of tool names to restrict which tools the agent can call. Leave empty to allow all tools exposed by the server.

Activate the server

Toggle the server to Active. Only active servers can be assigned to agents.

Configuration Reference

Stdio — Local Command

Use this mode to run an MCP server as a local process. Overcut starts the command and communicates with it over standard input/output.

{
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-filesystem", "/workspace"],
  "env": {
    "NODE_ENV": "production"
  }
}

command

string

required

The executable to run (e.g. npx, python, node).

args

string[]

Arguments passed to the command.

env

object

Environment variables set for the process. Use placeholders to reference secrets stored in the Vault — they are resolved at runtime and never exposed to the LLM.

SSE / HTTP — Remote Server

Use this mode to connect to a remote MCP server over HTTP with Server-Sent Events.

{
  "url": "https://mcp.example.com/sse",
  "headers": {
    "Authorization": "Bearer ${MY_API_KEY}"
  }
}

url

string

required

The full URL of the remote MCP server endpoint.

headers

object

HTTP headers sent with every request. Use placeholders to reference secrets stored in the Vault.

The configuration must contain exactly one of command or url. Including both or neither will fail validation.

Allowed Tools

By default, an MCP server exposes all of its tools to any agent it’s assigned to. You can limit this by specifying an allowed tools list — a comma-separated set of tool names. When an allowed tools list is set, agents can only call the tools in that list, even if the server advertises additional tools. This is useful for:

Reducing scope — give an agent access to only the tools it needs
Security — prevent agents from calling sensitive or destructive tools
Clarity — keep the agent’s tool set focused on the task at hand

Leave the allowed tools list empty to grant access to all tools the server provides.

Assigning MCP Servers to Agents

MCP servers are assigned on a per-agent basis. Each agent can have zero or more MCP servers, and each server can be shared across multiple agents.

Open the agent

Navigate to Agent Roles and select the agent you want to configure.

Open MCP Servers panel

Scroll to the MCP Servers section in the agent settings.

Add servers

Click Add MCP Server, search for available servers, and select one or more to assign. Only active servers appear in the list.

Remove servers (optional)

Click the remove icon next to any assigned server to unassign it from the agent.

How It Works at Runtime

When a workflow step runs an agent that has MCP servers assigned:

Bootstrap — Overcut connects to each assigned MCP server and discovers the tools it exposes. Each server has a 30-second timeout to complete its bootstrap.
Tool Registration — Discovered tools are registered with a namespaced format: mcp__<serverName>__<toolName>. This prevents name collisions when multiple servers expose tools with the same name.
Execution — The agent can call any registered MCP tool as part of its task. Tool calls are routed to the appropriate MCP server transparently.
Filtering — If an allowed tools list is configured, only matching tools are registered. All other tools from that server are excluded.

Examples

The examples below are provided as a starting point. Package names, environment variables, and endpoints may change over time — refer to each provider’s official MCP documentation for the most up-to-date configuration.

The examples use placeholders for credentials. Store the actual values in the Vault and make sure each secret is assigned to the relevant agent or marked as available for all executions.

Design — Figma

Connect a Figma MCP server so agents can read design files, inspect components, and extract design tokens during code generation or review workflows.

{
  "command": "npx",
  "args": ["-y", "figma-developer-mcp", "--stdio"],
  "env": {
    "FIGMA_API_KEY": "${FIGMA_API_KEY}"
  }
}

Logs — Datadog

Give agents access to your Datadog logs and metrics so they can investigate incidents, correlate errors with code changes, or summarize recent alerts.

{
  "command": "npx",
  "args": ["-y", "@winor30/mcp-server-datadog"],
  "env": {
    "DATADOG_API_KEY": "${DATADOG_API_KEY}",
    "DATADOG_APP_KEY": "${DATADOG_APP_KEY}",
    "DATADOG_SITE": "datadoghq.com"
  }
}

Logs — Coralogix

Connect to Coralogix so agents can query logs, search for error patterns, and pull observability data into their analysis. Replace {region} with your Coralogix region (e.g. us2, eu1, ap1).

{
  "command": "npx",
  "args": [
    "mcp-remote",
    "https://api.{region}.coralogix.com/mgmt/api/v1/mcp",
    "--header",
    "Authorization: Bearer ${CORALOGIX_API_KEY}"
  ]
}

Documentation — Notion

Let agents read and search your team’s Notion workspace to pull in product specs, runbooks, or architecture docs when working on tasks.

{
  "command": "npx",
  "args": ["-y", "@notionhq/notion-mcp-server"],
  "env": {
    "OPENAPI_MCP_HEADERS": "{\"Authorization\":\"Bearer ${NOTION_API_KEY}\",\"Notion-Version\":\"2022-06-28\"}"
  }
}

Documentation — Confluence

Connect to Confluence so agents can look up internal documentation, ADRs, or team knowledge bases during code review or implementation.

{
  "command": "npx",
  "args": ["-y", "@aashari/mcp-server-atlassian-confluence"],
  "env": {
    "ATLASSIAN_SITE_NAME": "your-team",
    "ATLASSIAN_USER_EMAIL": "${CONFLUENCE_USER_EMAIL}",
    "ATLASSIAN_API_TOKEN": "${CONFLUENCE_API_TOKEN}"
  }
}

Splitting a Server Across Agents

A single MCP server often exposes both read and write tools. Rather than giving every agent full access, you can create multiple server entries pointing to the same underlying service, each with a different allowed tools list, and assign each one to the appropriate agent. This pattern gives you fine-grained control over what each agent can do, reducing the risk of unintended actions and keeping agents focused. Example — Figma with read-only vs. full access:

Server Name	Allowed Tools	Assigned To
`figma-read`	`get_file, get_comments, get_components`	Code Reviewer, Tech Writer
`figma-full`	(empty — all tools)	Senior Developer

Both servers use the same Figma MCP configuration, but the Code Reviewer and Tech Writer can only read designs, while the Senior Developer has full access.

This is especially important for servers that expose destructive operations (delete, update, post). Limit write access to the agents that actually need it.

Best Practices

Naming

Use clear, descriptive server names that indicate the service or capability (e.g. figma-read, datadog-logs, notion-docs). When splitting a server across agents, include the access level in the name (e.g. figma-read vs. figma-full).

Security

Store credentials in the Vault and reference them with ${VAR_NAME} placeholders. Never hardcode secrets in MCP server configs.
Use allowed tools lists to limit the blast radius of agent actions, especially on servers with write or delete capabilities.
Split servers across agents to enforce least-privilege access — give each agent only the tools it needs.

Scope

Assign only the MCP servers an agent actually needs. Fewer tools means faster bootstrap and more focused agent behavior.
Too many tools can defocus the agent and lead to slower, less accurate results. When in doubt, use an allowed tools list to narrow the set.

Next Steps

Vault — Store and manage the secrets referenced in MCP server configurations
Agent Run Action — Execute a single agent with MCP tools
Agent Session Action — Coordinate multiple agents, each with their own MCP servers
Core Building Blocks — Understand how agents, actions, and triggers connect

Get Started

Quick Starts

Use Cases and Actions

Reference

Integrations

Repositories

Overview

External Tool Access

Two Transport Modes

Tool Allowlists

Per-Agent Assignment

Creating an MCP Server

Configuration Reference

Stdio — Local Command

SSE / HTTP — Remote Server

Allowed Tools

Assigning MCP Servers to Agents

How It Works at Runtime

Examples

Design — Figma

Logs — Datadog

Logs — Coralogix

Documentation — Notion

Documentation — Confluence

Splitting a Server Across Agents

Best Practices

Naming

Security

Scope

Next Steps

Get Started

Quick Starts

Use Cases and Actions

Reference

Integrations

Repositories

​Overview

External Tool Access

Two Transport Modes

Tool Allowlists

Per-Agent Assignment

​Creating an MCP Server

​Configuration Reference

​Stdio — Local Command

​SSE / HTTP — Remote Server

​Allowed Tools

​Assigning MCP Servers to Agents

​How It Works at Runtime

​Examples

​Design — Figma

​Logs — Datadog

​Logs — Coralogix

​Documentation — Notion

​Documentation — Confluence

​Splitting a Server Across Agents

​Best Practices

​Naming

​Security

​Scope

​Next Steps

Overview

Creating an MCP Server

Configuration Reference

Stdio — Local Command

SSE / HTTP — Remote Server

Allowed Tools

Assigning MCP Servers to Agents

How It Works at Runtime

Examples

Design — Figma

Logs — Datadog

Logs — Coralogix

Documentation — Notion

Documentation — Confluence

Splitting a Server Across Agents

Best Practices

Naming

Security

Scope

Next Steps