Claude Interactive Connectors
How MCP-based connectors let Claude read and act on tools like Asana, Slack, and Figma from inside a conversation, and what that costs in context, money, and control.
Claude Interactive Connectors
A connector is a pre-built bridge between Claude and one specific tool, your email, your project tracker, your deploy pipeline. Once it's on, Claude can read from that tool, search it, and take actions in it on your behalf, so your project's actual state shows up in the conversation instead of you copying it over by hand.
What's underneath
Connectors run on MCP, the Model Context Protocol, an open standard for wiring an AI application to external tools and data. You never deal with MCP directly, what matters is that it's open: anyone can build against it, which is why the connector directory has entries from dozens of companies, not just Anthropic.
Standard vs. interactive
- Standard connectors run entirely in the background. Claude calls the tool, the result comes back as text in the chat.
- Interactive connectors (MCP apps) go further: the tool renders as a live interface inside the conversation, e.g. a project board or a diagram you can look at directly, not just a description of it.
Both kinds live in the same directory, filterable by surface (claude.ai, Claude Code, Skills), by use case (communication, data, design, etc.), and by capability: read, read/write, or interactive.
What it looks like in practice
Connect a tracker like Asana and ask Claude to pull up a board, it renders the same board you'd see in the app, then flags things a human would: tasks past due with no owner, gaps in the plan. Approve a fix and the change lands in the real tool, reassigned tasks, updated dates. From there Claude can carry the same context into other connected tools: posting a status update in Slack, sketching a flow diagram in Figma, all sourced from the one conversation. The work happens in the chat; the result lands in your real accounts, and that's exactly why cost and control are worth thinking through before wiring everything up.
Cost
Two separate cost surfaces:
- Claude's side. Connectors themselves don't cost extra, they're included on every plan (a few Anthropic-built ones are plan-gated, check the pricing page). The real cost is context: each active connector loads its tool manifest into Claude's working memory, so the more you have on, the less room is left for the actual conversation before older messages get summarized. Keep tool access set to load manifests on demand rather than upfront, and toggle off connectors you're not using in a given chat.
- The tool's side. For everything that isn't an Anthropic-built connector, Claude is acting as you on your account with that app, so it's billed under your existing plan with that tool, not by Anthropic. If your Slack or Asana plan caps something, that cap still applies when Claude is the one doing the work.
Control
Every connector has a permissions panel listing its tools by capability, read-only, interactive, write/delete, each set to one of three modes:
- Always allow: fine for read-only tools you're comfortable with.
- Needs approval: the right default for anything that changes your data.
- Blocked: the tool is off entirely.
Match the setting to the stakes, not the default. This matters specifically because of prompt injection: content coming in through a connector (a task description, a ticket, a doc) can try to steer Claude toward actions you never asked for. Approval prompts are one of the main defenses, so treat each one as a real decision rather than a rubber stamp, one bad approval can be worse than a slower workflow. Permission settings aren't necessarily durable either: a connector set to blocked has been observed asking for approval anyway, and approving it once silently downgraded the setting from blocked to needs-approval. Whether or not that's since been fixed, it's a reason to re-check a connector's permissions rather than assume they stay put.
Privacy sits inside the same control question. Connecting a tool means Claude, and Anthropic's infrastructure by extension, can see whatever that tool exposes: emails, ticket contents, internal docs, customer data. That read scope isn't always narrow, a connector often has visibility into more than the one record you asked about, so check what it can see as carefully as what it can change. This matters most for anything with a disclosure obligation: customer PII, health or financial data, material nonpublic information, or contractual confidentiality. Read your organization's data-handling policy and the tool's own terms before connecting it where that kind of data is in scope, and when you're unsure whether the access is allowed, default to not connecting the tool.
Disconnecting is always one click and reversible, there's no commitment to trying one.
Takeaway
Connecting a tool takes about a minute, so effort isn't the constraint. What deserves a moment of thought is cost (mostly context, not money) and control (matching each tool's permission level to what it's actually allowed to touch). The protocol and the directory both keep changing, so it's worth revisiting a connector's settings occasionally rather than setting them once and forgetting them.
