Connectors

Agents do their best work where your work already lives, so they need to reach the services you run every day — your CRM, your issue tracker, your analytics, your docs. A connector is how an agent gains one of those external capabilities. This chapter sits alongside the agent profile: the profile says how an agent behaves, and connectors say what outside tools it can touch.

A connector gives an agent an outside capability

A connector is an external service your agents can use — Stripe, Linear, Notion, a search provider — exposed to an agent as a set of tools it can call while it works. Under the hood a connector is a Model Context Protocol server, but you work with it as a connector: you add it, scope it to the agents that should have it, and from then on those agents can act in that service the same way they act on tasks and documents. The "MCP server" wording only shows up in advanced and developer detail; everywhere you operate the product, it is a connector.

Connectors are how an agent stops being limited to what lives inside Task Machine. An agent with a payments connector can read a charge; one with a project-management connector can open an issue; one with a search connector can pull live results into its work. What an agent can reach is decided per agent, the same way control over what it may do is set per agent in its profile.

Browse the connector catalog

Task Machine ships a curated catalog so you do not start from a blank box. Open Connectors in your workspace and switch to Browse to see the catalog: a searchable grid of recognizable services, each card showing the service, what it does, and a status badge for the server behind it. The catalog is grouped across function areas — research, dev, data and analytics, docs and knowledge, email and messaging, CRM and sales, support, finance, marketing, ads, SEO, and more — so you can scan for the kind of capability a job needs.

The grid is honest by construction. Every connector is backed by a server in the official Model Context Protocol registry, and its badge says which kind: an official badge means the service's own vendor publishes the server under their verified namespace, and a community badge means a reputable third party maintains it. Nothing is shown as supported that has no real server behind it. Search is not limited to the curated set — typing a service name queries the live official registry, so discovery covers the whole ecosystem even when a service is not in the shipped catalog.

Install a connector and scope it to agents

Browsing ends in installing. Install on a catalog card opens the add-connector form, prefilled from the entry — its connection details when the registry already knows them, otherwise its name for you to complete — and submitting adds the connector to your workspace. You can also add one by hand on the Connectors page: an installed server that runs as a local process, or a remote server reached over HTTP. Installing or managing connectors requires the mcp:manage permission; members without it browse the catalog read-only.

Adding a connector to the workspace does not hand it to every agent. You assign a connector to the specific agents that should have it, so a payments connector reaches your finance agent without widening what every other agent can touch. Scoping connectors per agent is the same principle as scoping permissions per agent — capability is granted where the work happens, not globally.

During the private beta, connectors collect non-secret connection details only; secret values such as API keys and auth headers wait for the credential vault rather than being stored on the connector. Plan connectors around what is configurable without a secret today, and treat anything needing a credential as not yet wired.

Templates bring their own connectors

You rarely have to wire connectors by hand. A template bundle can declare the connectors the job needs and the agents they attach to, so installing the bundle creates those connectors already scoped to the agents that use them — an SEO bundle arriving with a search connector on its research agent, a support bundle with its helpdesk connector in place. When you install a bundle by hand the connectors come ready; when an agent proposes a bundle, its connectors are part of the single approval rather than a separate step.

The same catalog is the public proof

The connectors your agents use are also what the public site shows as a "Works with your tools" wall on the homepage and the cohort pages — the same honest catalog rendered as a logo grid, never an implied integration. It is there as proof that agents act in the tools a buyer already runs, and it is backed by the very entries you browse and install inside the product, so the promise outside and the capability inside never drift apart.

From here, set which agents carry which connectors in the agent profile, and see Stay in Control for the mcp:manage permission that gates adding and assigning them.