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.

The fastest way to add an MCP server is through the MCP Catalog — browse common servers and install with guided setup. Use the manual flow below when you need a custom configuration.

Overview

MCP Catalog

Browse and install pre-configured servers from the open-source catalog with one click.

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 a Custom MCP Server

Use this flow when you need to configure a server that isn’t in the MCP Catalog, or when you need full control over the configuration.

Open MCP Servers

Navigate to MCP Servers in the workspace sidebar. Click Add MCP Server to open the catalog, then click Add Custom.

Configure the server

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.

Attach secrets (optional)

In the Secrets section, click Add Secret to attach one or more secrets from the Vault.

Set allowed tools (optional)

In the Allowed Tools section, add tool names to restrict which tools agents can call. Leave the list 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.

Managing MCP Server Secrets

Project secrets attached to an MCP server become available to the server whenever an agent uses it. This keeps credentials scoped to the MCP integration while letting you reuse secrets across servers.

Open the MCP server

Go to MCP Servers, then select the server you want to update.

Add secrets

In the Secrets section, click Add Secret to attach one or more secrets. Save your changes to apply the updates.

Remove secrets

Remove secrets you no longer want the server to use, then save the server. Removing a secret from the server does not delete it from the Vault.

Attach only the secrets the MCP server needs. This keeps access focused and easier to audit.

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 building an Allowed Tools list using the add/remove editor on the server’s detail page. When the allowed tools list has entries, 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

If the list is empty, the server is unrestricted — agents can use all tools the server provides.

When installing from the MCP Catalog, you choose tools during the install flow. The catalog pre-selects a recommended set that you can adjust before installation.

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 the allowed tools list has entries, only matching tools are registered. If the list is empty, all tools from that server are available.

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
MCP Catalog — Browse and install pre-configured servers from the open-source catalog
Core Building Blocks — Understand how agents, actions, and triggers connect

Get Started

Quick Starts

Use Cases and Actions

Reference

Integrations

Repositories

Overview

MCP Catalog

Two Transport Modes

Tool Allowlists

Per-Agent Assignment

Creating a Custom MCP Server

Managing MCP Server Secrets

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

MCP Catalog

Two Transport Modes

Tool Allowlists

Per-Agent Assignment

​Creating a Custom MCP Server

​Managing MCP Server Secrets

​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 a Custom MCP Server

Managing MCP Server Secrets

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