Complete guide
Custom Claude connectors: the complete guide to full read-write access for any software
Everything that decides whether Claude can actually work inside your tools: what MCP is, how read and write access differ, why directory connectors fall short, how a connector gets built, and how to keep it safe.
Key takeaways
- A custom Claude connector is an MCP server built for your exact software, including in-house and on-prem systems that have no off-the-shelf option.
- MCP is the open standard; a connector is a specific server that speaks it. See the MCP glossary entry for the distinction.
- Read access lets Claude answer; write access lets Claude do the work. A custom build gives you both, with risky actions gated.
- Directory and third-party connectors exist only for popular tools and are often read-only or partial. A custom connector covers the specific read-write actions you need.
- A connector never grants Claude more access than your account already has, and write actions can require a human-in-the-loop confirmation.
What is a custom Claude connector?
A custom Claude connector is a small Model Context Protocol (MCP) server, built for one specific tool, that lets Claude read that tool's data and take scoped actions in it. Unlike a directory connector, it is built for your exact system, including in-house or on-prem software with no off-the-shelf option, with read and gated write access.
Out of the box, Claude can reason about whatever you paste into a conversation, but it cannot reach into your systems on its own. A connector closes that gap. It exposes a defined set of tools (read a record, search, create, update) that Claude can call during a chat, so the work happens in your software instead of in a copy-paste shuffle. For a deeper definition, see the glossary entry for a custom connector.
What is MCP, and why does it matter for Claude?
MCP, the Model Context Protocol, is the open standard that lets Claude talk to outside tools in a consistent way. It defines how a model discovers available tools, calls them, and receives results. Because it is a shared protocol, any system with an MCP server can be connected to Claude, which is what makes custom connectors possible for any software.
Before MCP, every integration was bespoke and brittle. MCP gives Claude one consistent way to call tools, so the hard part is no longer the wiring, it is building a server that maps your system's data and actions cleanly. The glossary entries for MCP and the MCP connector cover the terminology in more depth.
What is the difference between a connector that reads and one that writes?
The difference between a connector that reads and one that writes is whether Claude can change anything. A read-only connector can search, summarize, and answer questions about your data. A read-write connector can also create and update records and push changes back, which is what turns Claude from a search box into something that does the task.
| Capability | Read-only connector | Full read-write connector |
|---|---|---|
| Search and summarize records | Yes | Yes |
| Answer questions about your data | Yes | Yes |
| Create new records | No | Yes |
| Update existing records | No | Yes |
| Destructive or outbound actions | No | Yes, gated behind a confirmation |
| Completes a task end to end | Rarely, you finish by hand | Yes, inside the conversation |
For the full picture of what write access changes, see full read-write access for Claude and the glossary term read and write access.
Why do directory and third-party connectors fall short?
Directory and third-party connectors fall short because they only exist for popular software, and many are read-only or cover a thin slice of the API. If your tool is in-house, niche, or heavily customized, there is nothing in the directory to install, and a generic connector cannot reach your specific objects, fields, and write actions.
This is the difference between the category of off-the-shelf connectors and a build for your exact system. Off-the-shelf options are convenient when they exist and fit, but they are scoped to the common case. A connector built for your software follows your schema, your custom fields, and the actions your team actually performs. See how this plays out for replacing a limited connector and for connecting internal tools.
What are the two walls that stop Claude from working in your tools?
The two walls are the no-connector wall and the bad-connector wall. The first is when your software has no connector at all, so Claude cannot reach it. The second is when a connector exists but is read-only or partial, so Claude can look but cannot act. A custom build removes both.
Most teams hit one of these two walls. If your system is in-house or on-prem, you are at the first wall: there is nothing to install. If you are using a popular tool but the available connector only reads, or only covers a fraction of what you do, you are at the second wall. Both walls have the same fix, a connector built and maintained for your exact system and the read-write actions you need.
How does a custom connector get built?
A custom connector gets built by mapping your system's data and actions, then implementing a hosted MCP server with separated read and write tools, OAuth where supported, and scoped permissions. We host and maintain it, so you do not run a server. You add it in Claude and it inherits your account's access.
The build has a few moving parts that matter for security and reliability:
- Authentication. The connector authenticates as your account, using OAuth where your software supports it or a scoped API key or token where it does not. We handle the OAuth lifecycle, including token refresh, so connections stay live.
- Scoped tools. Read and write actions are exposed as separate, named tools, so you can see exactly what Claude can do and gate the risky ones.
- Firewall and on-prem access. For systems not reachable from the public internet, we use IP allowlisting, a tunnel, or a small component inside your network, scoped only to the endpoints Claude needs.
- Maintenance. As your software's API and schema change, we update the connector so it keeps working in production.
How is a custom connector kept safe?
A custom connector is kept safe by inheriting your existing permissions, separating read and write tools, and gating risky actions behind a human-in-the-loop confirmation. Claude never gets more access than your account has, and destructive or outbound actions, like deletes or sending messages, require explicit approval before they run.
Safety is a design choice, not an afterthought. Create and update actions flow inside a conversation you start, because they are recoverable and scoped to your permissions. Actions that are hard to undo or reach outside your system are held behind a confirmation step you control. That keeps the experience fast for everyday work while keeping a human in the loop on anything consequential.
What does full read-write unlock in day-to-day work?
Full read-write unlocks tasks that read-only access cannot finish: creating and updating records, reconciling data across systems, drafting and saving changes, and pushing updates back, all inside a single conversation. It moves Claude from answering questions about your tools to completing work inside them.
In practice that looks like updating deal stages and logging activity in a custom CRM, creating and editing records in internal tools, and reconciling values across two systems without exporting a spreadsheet. Browse the connectors we build to see how this maps to specific software, and the glossary term for full read-write for the definition.
How does a custom connector compare to building it yourself or using no-code?
A custom connector differs from a DIY build, a no-code automation, or a managed MCP platform in who owns hosting, auth, safety gating, and ongoing maintenance. A done-for-you connector covers all four for your exact system, while the alternatives trade one of those away, usually maintenance or write coverage.
| Approach | Built for your exact system | Full read-write | Maintained over time |
|---|---|---|---|
| Done-for-you custom connector | Yes | Yes, with gating | Yes |
| DIY build | Yes, if you have the engineers | Possible, but you own the risk | Only if you keep staffing it |
| No-code automation | Partial, within preset blocks | Limited to supported actions | Breaks when triggers change |
| Limited directory connector | No, generic by design | Often read-only | On the vendor's roadmap, not yours |
| Managed MCP platform | Within the platform's catalog | Varies by integration | Tied to the platform's support |
How do you choose a custom connector provider?
You choose a custom connector provider by checking that the build is truly done-for-you: hosting, OAuth and token lifecycle, separated read and write tools, human-in-the-loop gating on risky actions, on-prem and firewall support, and ongoing maintenance as your software changes. A maintained connector is the difference from a script that breaks.
The honest scope to expect is this: the connector inherits your permissions and never gives Claude more access than you have; create and update flow inside a conversation, while delete and send are gated; and the provider owns the server so you do not. See current pricing for how a one-time build fee and monthly maintenance fee work, or book a scoping call to map your system.
Frequently asked questions
What is a custom Claude connector?
What is the difference between MCP and a connector?
Can a custom connector write data, not just read it?
Why not just use a directory or third-party connector?
Does a custom connector give Claude more access than I have?
Can a custom connector reach a system behind a firewall?
How do I choose a custom connector provider?
What does full read-write actually unlock?
Tell us about your software. We'll build the connector.
Book a 30-minute scoping call. We'll map your system's data, the actions Claude should take, and what full read-write would unlock for your team.