Comparison

Custom connector vs a limited or read-only connector

If you tried a directory or third-party connector and found it could only read your data, or covered a shallow slice of your tool, this is the difference. A custom connector gives Claude scoped read-write access to the system you actually run.

Build my connector See how it works

What is the difference between a custom connector and a limited or read-only connector?

A custom connector gives Claude full scoped read-write access to your tool, so it can both read your data and act inside the system. A limited or read-only connector usually cannot write back and often covers only a shallow set of endpoints, so Claude can answer questions but not create or update records.

Key takeaways

Read-only and many directory connectors let Claude look at your data but not act on it.
A custom connector adds scoped write tools, so Claude can create and update records you ask it to.
Destructive or outbound actions stay gated behind a confirmation you control.
Custom connectors cover the endpoints your team actually uses, including in-house and on-prem tools.

How do the capabilities compare side by side?

The capabilities compare across read access, write-back, gated actions, endpoint coverage, custom-tool support, the permission model, and maintenance. A limited or read-only connector tends to stop at reading a fixed slice, while a custom connector adds scoped writes, deeper coverage, and ongoing upkeep matched to your account.

Capability comparison between a custom connector and a limited or read-only connector
Capability	Limited or read-only connector	Custom connector
Read your data	Often yes, but limited to a fixed set of objects and fields the directory listing chose to expose	Yes, scoped to the objects, fields, and records your account can already see
Write back (create and update)	Usually no, or limited to a narrow slice; many directory listings are read-only	Yes, Claude can create and update records inside a conversation you start
Destructive and outbound actions (delete, send)	Rarely supported, and when present, not gated behind a confirmation step	Supported but gated behind a human-in-the-loop confirmation you control
Coverage of your endpoints	Shallow: a handful of popular endpoints, with the long tail of your API left out	Deep: the objects and actions your team actually uses, mapped on a scoping call
Custom, in-house, or on-prem tools	Not covered if your tool is not in the connector directory	Built for your exact system, including in-house and firewalled tools
Permission model	Whatever the listing decided, with little control over scope	Inherits your account permissions, never more access than you already have
Maintenance as the API changes	Depends on whoever published the listing; can lag or go stale	Maintained for you, so it keeps working as schemas and APIs change

Why are so many directory connectors read-only?

Directory connectors are read-only or shallow because they are built once for everyone, so they expose a safe, narrow surface and avoid the scoping and confirmation steps that write actions need. A custom connector is built for your account, which is what makes scoped write-back and deeper coverage practical and safe.

That is why teams move to a connector built for them once they want Claude to act, not just answer. The reading is the easy part; the value shows up when Claude can update a record, log an activity, or draft an action for you to approve. See what full read-write access unlocks for a tool you already use.

Which should you choose?

Choose a limited or read-only connector if you only need Claude to read a small, fixed set of data and never act on it. Choose a custom connector if you need Claude to write back, cover the endpoints your team relies on, or work with a custom, in-house, or on-prem tool the directory does not list.

Read-only is enough when the task is purely lookups and summaries, and the listing already exposes the fields you need.
Go custom when you want Claude to create or update records, log activities, or take scoped actions inside your system.
Go custom when your tool is in-house, heavily modified, or behind a firewall, so there is no directory listing to use.
Go custom when the directory connector exists but only scratches the surface of the API your team actually depends on.

Custom connectors are scoped to your objects, write actions, and how your system is reachable, so the work fits what you run. See current custom connector pricing for how the one-time build fee and monthly maintenance fee work.

What full read-write unlocks See pricing Browse connectors

Frequently asked questions

What is a read-only connector?

A read-only connector lets Claude fetch and reason over data from a tool but cannot create, update, or change anything in it. Many directory and third-party listings are read-only or expose only a shallow slice of an API, so Claude can answer questions but cannot act inside the system on your behalf.

Why can't the directory connector write back to my tool?

Directory and third-party connectors are built once for everyone, so they tend to expose a safe, narrow, often read-only surface. Write actions need careful scoping and confirmation steps that a one-size listing avoids. A custom connector is built for your account, so it can expose scoped write tools with the right guardrails.

Is a custom connector safe if it can write?

Yes. A custom connector inherits your account permissions and never grants Claude more access than you already have. Create and update flow inside a conversation you start, while destructive or outbound actions like deleting a record or sending a message are gated behind a confirmation you approve.

Can I get a custom connector for a tool that is already in the directory?

Yes. Even when a tool has a directory listing, we build a custom connector when you need deeper coverage, write-back, or actions the listing leaves out. You get the endpoints your team actually uses and scoped write access, rather than the shallow read-only slice the listing exposed.

What happens to a limited connector when the tool's API changes?

A limited or third-party connector keeps working only as long as whoever published it keeps it current, so it can lag or break when the API changes. A custom connector is maintained for you, so when fields, schemas, or auth change, we update it and your team keeps working without interruption.

Outgrew a read-only connector? We'll build one that acts.

Book a 30-minute scoping call. We'll map your tool, what Claude should be able to do, and what scoped read-write would unlock.

Build my connector Talk to us