Custom MCP servers

When the app you need is not in the catalog, add your own connector: a packaged MCP server run in Harriet's sandbox, a remote HTTP MCP server, or tools generated from an existing REST API's OpenAPI spec.

Three ways to bring your own

Create custom MCP (npx / uvx). The link at the bottom of the Add connector dialog is for sandboxed servers not in the catalog. You provide the sandbox command and arguments — often the same npx or uvx command the package's README shows — and Harriet runs the package in an isolated environment. This is the path for published MCP packages from npm-style registries; it expects a runnable package command, not a Git clone of an arbitrary repository.

If the package lives on GitHub rather than PyPI, you can keep the usual uvx --from git+https://github.com/… command: Harriet fetches a snapshot instead of cloning with git. Tick Keep git+https sources only when the package needs a real git checkout. Use a GitHub token in the environment only when the repository is private.

Native MCP server. If you already run an MCP server over HTTPS JSON-RPC, register it with its MCP server URL. This fits vendor-hosted remote servers and internal MCP services you deploy yourself.

OpenAPI / Swagger. You do not always need to build an MCP server. When a vendor or internal system exposes a REST API with an OpenAPI or Swagger document, give Harriet the API base URL and the OpenAPI spec URL and it generates one MCP tool per operation. This is often the fastest way to make an existing internal API usable by skills.

Where servers are configured

Custom connectors are set up in Integration settings — the Connectors screen's own description points there: "Configure OAuth, server URLs, and tool permissions in Integration settings." The Add MCP in Integrations button on the Connectors screen opens the full setup flow.

The wizard steps through:

  1. Basics. Display name and how the connector appears to admins.
  2. Connection. Pick the type: OpenAPI / Swagger, native MCP server, or sandboxed (uvx / npx).
  3. Authentication. No auth, basic auth, organization secrets, or per-user OAuth, depending on what the server supports. Organization secrets are configured once by IT and stored server-side; employees never receive them.
  4. Access. Which teams may use the connector.

After saving, run Sync tools so Harriet discovers what the server offers, then decide which tools to enable — see Tool permissions. Once the connector exists, attach it to a skill and assign that skill like any other.

Requirements to know up front

Calls that go through Harriet only allow public HTTPS. Harriet revalidates native MCP server URLs before each proxied call, which keeps the gateway from being used as a hop into internal networks. A server that only your computers can reach, such as a host on the office network, needs a direct connection from Harriet Desktop instead.

Sandboxed (npx / uvx) servers can tick Static outbound IP on the connector's Options tab so that server's outbound traffic leaves from Harriet's static outbound IP for sandboxed MCP servers, 52.208.246.51. Allowlist that address with the service the server calls. The address is shared by all Harriet customers who use it, so treat it as an extra check alongside credentials. Native MCP servers and OpenAPI connectors do not use it. Other connectors, such as HiBob and Workday, use a different address for their static IP option.

⚠️

Every custom MCP server is a new security and data boundary. Review what data it can reach and which credentials it uses before enabling tools broadly, and keep write tools behind confirmation. Governance options are covered in connector access control.

If your organization routes new connectors through review, a custom connector may start as a draft and need approval in the review queue before it can be deployed to devices.