The remote connector directory

Not every integration needs a program running on your machine — many services host their own MCP server, and you mount those straight from a built-in directory.

What you’ll learn

• How a remote connector differs from a local MCP server.
• How to mount one from the verified directory.
• How its tools reach your workers.

Local subprocess vs hosted URL

A local MCP server is a program askTheodor launches and keeps running in the background. A remote connector is a server the vendor already runs — you just point askTheodor at its URL. Nothing spawns on your machine; there’s no command, no args, no subprocess to babysit.

Mount one from the directory

1. Open the remote connector directory — about 45 verified hosted servers, including Slack, Google Workspace, DocuSign, GitHub, Notion, and Stripe.
2. Pick a service. The directory already knows its URL, so there’s no command line to fill in.
3. Connect it. Once linked, its tools appear in any worker’s Skills tab, just like local MCP tools.

Grant the tools

As always, mounting a connector doesn’t give any worker access by itself. Open a worker’s Skills tab and add only the tools that worker needs — least-privilege still applies.

Verified hosts

The ~45 servers in the directory are verified — a curated list of known-good hosted integrations, so you’re not pasting in an unknown endpoint.

When to prefer remote

Reach for a remote connector when the vendor offers one — there’s nothing to install, update, or keep alive. Fall back to a local MCP server when you need something self-hosted or custom.

Recap

Remote connectors mount hosted MCP servers by URL from a directory of ~45 verified services, with no local subprocess to run. Next: how you actually sign in to those services — once — without ever pasting a key.

➡️ Next: OAuth sign-in