Claude connectors give Claude an authorized path to supported information or actions in another service. What Claude can search, read, create, update, or delete depends on the connector’s exposed capabilities and the account used to connect. For example, a project lead could ask Claude to retrieve issues and notes for a reporting period, then review a source-backed status draft before sharing it.
A connector provides access; it does not define a dependable business process. You still need rules for checking results, confirming target records, preventing duplicate writes, and assigning exceptions. This guide explains how to choose a connection model, configure it, and put practical controls around the work.
The examples below are illustrative designs unless a vendor source explicitly documents the relevant operation. Check the live connector or Zapier action before presenting an integration as ready to run.
What Claude connectors do, and what they do not do
A Claude connector is a user-facing integration or configuration that makes selected capabilities of a service available to Claude. MCP, or Model Context Protocol, is an open protocol created by Anthropic to connect AI applications with tools and data. MCP is a protocol layer; a connector is not simply another name for an MCP server.
Connector capabilities generally fall into two groups: retrieving or searching information, and performing supported actions. A connected service is not necessarily read-only. Some connectors expose actions that can create or change records, and custom MCP tools can potentially delete data. Check the individual connector’s listed capabilities and tool approvals before relying on a particular operation. Anthropic’s connector guide describes the current connection model and notes that capabilities vary.
Connection alone does not validate business rules, guarantee approval, prevent duplicate writes, or make concurrent runs safe. Those controls belong in the workflow where they are needed.
Choose the connection model that fits the job
Start with the service Claude needs and the exact operation required. Use a native connector for a supported service and the capabilities shown in its directory entry. Choose a packaged plugin if its combination of skills, connectors, and possibly sub-agents fits the job. Use a custom remote MCP connector when a suitable remote server exists for a service that is not available natively or is privately controlled.
| Option | Best fit | Key constraint |
|---|---|---|
| Native connector | One supported service and listed operations | Tools and permissions vary by connector |
| Plugin | A packaged set of workflow capabilities | Currently documented for Pro, Max, Ultra, Team, and Enterprise |
| Custom remote MCP | A missing or privately controlled service with a remote MCP server | Requires a supported endpoint, authentication, and network access |
| Desktop extension | Local files, databases, desktop apps, or OS access | Not available on Claude web or mobile |
| Zapier MCP | Claude-initiated calls to selected Zapier actions | Only exposed actions are available |
| Zapier workflow | Repeatable processing started by a configured trigger | Trigger, routing, validation, and actions must be configured |
Decision rule: one supported service and a small set of operations usually points to a native connector. Choose a plugin for a packaged workflow, custom remote MCP for a suitable non-native service, and a desktop extension when the resource is local. Choose Zapier MCP when Claude should call selected app actions on request; choose a triggered Zap when processing should start and run in a repeatable sequence. See Anthropic’s comparison of desktop and web connectors and its current plugin documentation.
Set up and manage connectors with the current Claude interface
Claude’s management interface is moving from separate Customize and Connectors areas to a unified Plugins experience, so menu names can differ by account. Follow the function of each step rather than assuming every user sees the same path:
- Open connector or plugin management and browse or search the available directory.
- Inspect the connector’s description and listed tools. Confirm that it supports the operation you need, including any write action.
- Choose Connect or install, authenticate with the relevant service account, and review the requested access.
- Enable the connector for the conversation using the available connector controls.
To pause access, disable the connector using its management controls. To remove the connection, disconnect it there. A disconnected connector can generally be connected again. For the current transition, see Anthropic’s notice about managing plugins, skills, and connectors from one page.
On Team and Enterprise, an Owner or Primary Owner may need to enable a connector for the organization before members can use it. That setting is distinct from each member authenticating with the underlying service. Organization-managed authentication may be available in beta for Team and Enterprise, subject to current availability. Free users can use connectors; current custom-connector documentation limits Free users to one custom remote MCP connector, not one connector of every kind.
If a connector is missing, check the interface rollout, plan, organization policy, supported Claude surface, third-party account, and authentication status before treating it as a product fault.
Build a useful workflow: source, bounded task, check, action
A dependable connector workflow separates retrieval, AI interpretation, validation, execution, and exception handling. The AI can summarize, classify, or extract candidate information. Fixed rules should check identifiers, dates, required fields, destination permissions, and duplicate keys.
Illustrative project-status design: A project lead requests open issues for project P-104 during a specified week. Claude retrieves issue and note records through connectors that support the needed searches, then drafts a report with source references. A deterministic check confirms the project and date range. The project owner reviews conflicts before sharing the draft.
A compact output contract could be:
{
"project_id": "P-104",
"reporting_period_start": "2026-11-09",
"reporting_period_end": "2026-11-13",
"summary": "Illustrative draft based on retrieved records.",
"source_records": [
{
"source_record_id": "issue-219",
"source_url": "https://example.invalid/issues/219",
"status": "open"
}
],
"needs_review": true,
"review_reason": "One source record has a conflicting date."
}The identifiers and URL are illustrative. Confirm the project and period for every record, retain source IDs or URLs, and route missing or conflicting records to the named project owner. Save the report as a draft or send it only if the selected destination connector exposes the required action.
Use AI for interpretation, rules for control
| Workflow | AI’s bounded role | Validation | Destination or fallback |
|---|---|---|---|
| Project status request | Summarize retrieved issues and notes | Check project, dates, and source IDs | Reviewed report draft; project owner resolves conflicts |
| CRM update requested in Claude | Prepare proposed field changes | Verify record ID, required fields, and freshness | Write after approval; CRM owner handles ambiguity |
| Incoming support request in a triggered workflow | Extract intent, urgency, and reference | Reject invalid values; match the record in the system of record | Fixed routing after validation; support owner reviews ambiguous matches |
For an individual support request, preserve the source event ID and define one processed item as one incoming request. A suitable duplicate key could be source_system + source_event_id + action_type. When simultaneous runs are possible, enforce uniqueness with a database constraint or use an atomic upsert. A lookup followed by a create can race.
A report covering a period has a different grain. Use a key such as project ID, period start, period end, report type, and destination, rather than reusing an individual issue’s identity. If the report stores citations, retain one row per source citation when later updates must be tracked independently.
For customer-facing messages, CRM changes, or other consequential writes, keep the sequence draft, validate target and fields, approve, execute, and record the result. A Zapier workflow can use AI for extraction while fixed filters or paths control eligibility and routing. For implementation support, see Zapier automation consulting.
When custom remote MCP is the right choice
Use a custom remote MCP connector only when a suitable server exists and its owner can explain the authentication, exposed tools, and authorization rules. Anthropic requires the server to be reachable from its cloud infrastructure over public HTTPS on port 443. A server available only on localhost or behind a VPN will not work unless it is made reachable under Anthropic’s documented network requirements. A nonstandard port is not supported by the current setup guidance.
- Obtain the remote MCP server URL and confirm reachability from outside your own network.
- Add the custom connector in Claude’s connector or plugin management area.
- Configure the authentication method required by the server. Depending on the server, this may involve OAuth, an API key, a bearer token, or fixed request credentials.
- Complete authentication, review permissions and exposed tools, and enable the connector for the conversation.
Review tools individually. An MCP server may expose read, create, update, or delete operations. Disable irrelevant or destructive tools where possible. For Team or Enterprise shared credentials, grant only the scope the connector needs and maintain authorization checks on the server. See Anthropic’s custom remote MCP setup guide for current network, authentication, and administration requirements.
Zapier MCP or an AI-assisted Zapier workflow?
Zapier MCP exposes selected Zapier actions to supported MCP clients, including Claude. Zapier currently advertises access to 9,000+ apps and 40,000+ actions. These are vendor-reported counts and can change. With MCP, a user asks Claude to call an exposed tool. With a Zapier workflow, a configured trigger starts a repeatable sequence whose routing and actions can be fixed.
- Claude-initiated action: A user asks Claude to retrieve a CRM record and prepare an update. Validate the exact record and proposed fields, get approval if required, then invoke a confirmed action. Record the destination ID or error.
- Triggered processing: A new support request starts a Zap. An AI step extracts intent and an invoice reference into configured fields. Rules reject missing identifiers or invalid categories, then route the request. An ambiguous invoice match goes to a human support owner rather than triggering a refund.
For either design, retain the source event ID and verify the exact app action, required fields, permissions, and target-app limits. AI by Zapier supports configured structured output, but the workflow must still reject invalid enums or missing identifiers. Check current Zapier MCP usage details: successful tool calls can consume Zapier tasks, and billing depends on product, model tier, tool calls, and plan. For a triggered workflow that needs repeatable routing, explore AI agent implementation where bounded AI tasks and operational review gates are part of the design.
Permissions, provenance, and exception handling
Claude generally inherits the permissions of the account authenticated to the connected service. If a user cannot access a record directly, they generally cannot access it through that user’s connector. Organization enablement makes a connector available under organizational policy; it does not automatically authorize each member in the third-party service. A shared credential is different because it can expose the scope of the shared account to users of that connection.
Availability and authorization are separate controls. Before rollout, identify both the organization policy that enables the connector and the individual or shared identity that reaches the underlying service. Review the effective record scope under that identity.
Treat the connector’s tools and credential as an access contract. For a consequential write, verify the exact target and all mandatory fields before execution. Preserve relevant provenance, including source system, source record or event ID, retrieval time, connector or action used, validation result, approval status, destination record ID, and execution status.
If the target is ambiguous, permission is missing, or source data conflicts, stop and assign the exception to the responsible system or business owner. Add retries, approvals, duplicate prevention, and race-safe writes explicitly where the workflow requires them. They are not automatic properties of every connector or MCP workflow.
Final checks before enabling a connector
Do not put a write-capable workflow into production until a low-risk test confirms the intended operation and its failure path. Use the checks below as a release gate.
- Confirm the connector or exposed action supports the exact search, read, create, update, or delete operation required.
- Verify the authenticated identity, credential scope, and target service permissions.
- Test the target record, required fields, and expected output with a low-risk case.
- Test missing data, permission failure, and ambiguous matches, and name the owner for each exception.
- Repeat the same event and test concurrent processing. Verify duplicate control at the correct data grain through a unique constraint or transactional upsert where needed.
- For custom MCP, check endpoint reachability and credential scope. For Zapier MCP, confirm selected actions and monitor task use.
- Name the human reviewer for consequential actions and record where approval and execution results are stored.
After launch, measure outcomes tied to the workflow, such as completion rate, exception rate, duplicate-write rate, or time to resolve a request. Review those measures against a defined baseline before changing access or expanding the workflow.