MCP Servers

MCP servers are the richest way to extend what Synti’s agent can do. The Model Context Protocol (MCP) is an open standard for exposing tools to an AI agent, so connecting an MCP server hands the agent a ready-made set of capabilities—no custom integration code required. Link a GitHub server and the agent can review pull requests, triage issues, and update documents; link a database server and it can query your data directly. Because an MCP server publishes a fixed, well-described set of tools, this source kind gives the most reliable, purpose-built integrations. For a comparison with REST APIs and local filesystems, see Sources.

What you get

Each connected server exposes its own tools, and the agent uses them naturally in conversation—you describe the outcome you want, and it picks the right tools. Because several servers can coexist in one workspace, the agent can also chain them: pull data from one service, transform it, and push it to another, all within a single task.

Two kinds of MCP server

MCP servers reach the agent over one of two transports.

Remote (HTTP/SSE)
Local (stdio)

Remote servers run somewhere on the network and are reached by URL. Synti speaks both Streamable HTTP and Server-Sent Events (SSE). You provide the endpoint URL and, if the server requires it, an authentication method—OAuth, a bearer token, or none.

config.json

{
  "type": "mcp",
  "name": "Exa Search",
  "slug": "exa",
  "enabled": true,
  "mcp": {
    "transport": "http",
    "url": "https://mcp.exa.ai/mcp",
    "authType": "bearer"
  }
}

Local servers run as a process on your own machine, launched by a command. Synti communicates with them over standard input/output (stdio). This is the pattern for npm-published servers, Node or Python scripts, and compiled binaries.

config.json

{
  "type": "mcp",
  "name": "Local Filesystem MCP",
  "slug": "fs-mcp",
  "enabled": true,
  "mcp": {
    "transport": "stdio",
    "command": "npx",
    "args": ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/Documents"]
  }
}

Common local launch patterns:

Server type	`command`	`args`
npm package	`npx`	`["-y", "package-name"]`
Node script	`node`	`["/path/to/server.js"]`
Python script	`python`	`["/path/to/server.py"]`
Binary	`/path/to/binary`	any flags the binary expects

Configuration at a glance

An MCP source uses type: "mcp" plus an mcp block describing transport and authentication. Required fields are type, name, the transport details, and the auth method. Optional fields include a tagline, an icon (emoji, path, or URL), and—for local servers—arguments and environment variables. Synti can auto-discover an icon file placed alongside config.json. For the full setup walkthrough, see Connecting servers. For credentials and OAuth, see Authentication.

Security

Synti is local-first, and MCP sources follow the same rule as every other source: secrets never live in config.json. Credentials are encrypted at ~/.synti/credentials.enc, and each workspace keeps its own sources and credentials isolated from the others, so connecting a server in one workspace never exposes it to another. Tool actions that change state still route through Permissions before they run.

Getting Started

Core Concepts

Sources

Skills

Browser Automation

Messaging

Labels

Statuses

Customization

Go Further

What you get

Two kinds of MCP server

Configuration at a glance

Security

​What you get

​Two kinds of MCP server

​Configuration at a glance

​Security

What you get

Two kinds of MCP server

Configuration at a glance

Security