How to
How to give Claude access to your internal tools
Claude is great at reasoning, but it cannot touch your internal systems until something connects them. A custom connector is that bridge, scoped to the tools and actions you choose.
To give Claude access to your internal tools, build a custom MCP connector that exposes each tool's actions as functions Claude can call. The connector authenticates as the user, inherits their permissions, and runs inside a Claude conversation. Create and update flow directly, while delete and send stay behind a confirmation.
Key takeaways
- An MCP connector is the bridge: it turns your internal tool's API or database into actions Claude can call.
- The connector runs inside a conversation the user starts, acting as that user with their permissions.
- Read and write tools are defined separately, so you choose exactly which actions Claude can take.
- Create and update flow inside the conversation, while delete and send are gated behind a human confirmation.
- It works for in-house apps, internal databases, and admin panels with no public connector listing.
What does it take to connect Claude to an internal tool?
Connecting Claude to an internal tool takes a custom MCP connector that wraps the tool's API or database and describes each action as a function Claude can call. The connector handles authentication, maps your real schema, and defines which actions are read, which are write, and which are gated.
Claude on its own cannot reach a system that lives on your network or behind your login. The Model Context Protocol (MCP) is the standard that lets a connector advertise a set of tools, and Claude decides when to call them inside a conversation.
For an internal tool, that means mapping the endpoints or tables your team actually uses: the records you query, the fields you update, the searches you run. The build comes together in a few steps:
- 1We build a custom MCP connector that wraps your internal tool's API or database.
- 2Each action is described as a function Claude can call, defined as read, write, or gated.
- 3The connector maps your real schema and handles authentication as the user.
- 4Claude calls those tools inside a conversation, with the connector acting as a thin, scoped layer rather than a copy of your data.
How do I give Claude access without giving it too much?
You give Claude scoped access by authenticating the connector as the individual user, so it inherits exactly that person's permissions and nothing more. Each tool is defined explicitly, read and write are separate, and the connector never grants more access than the user's own account already has.
Access is not all or nothing. You choose which objects and actions to expose, and you decide which run automatically and which pause for a confirmation. A teammate who cannot see a record in the tool itself cannot see it through Claude either.
Because the connector acts as the signed-in user, there is no shared super-account quietly handing Claude broad reach. The boundary is the same boundary your tool already enforces for that person.
Can Claude take actions in an internal tool, not just read it?
Yes, Claude can take actions in an internal tool when the connector includes write tools, not only read ones. Creating a record, updating a field, or moving an item forward happens inside the conversation. Deleting a record or sending something outbound stays behind a confirmation you approve first.
A read-only connection lets Claude answer questions about what is in the tool. Adding write tools lets Claude do the work:
- Open a ticket with
create_ticket. - Update a status or move an item forward with
update_record. - Log an entry or attach a note with
add_note. - Fill a field in your real schema.
Destructive and outbound actions are treated differently on purpose. Delete and send are defined as gated tools, so a human stays in the loop for anything that is hard to undo or leaves your walls.
Gate what you cannot undo
Tools like delete_record and send_message always wait for your confirmation. Nothing irreversible or outbound runs without a person approving it first.
Does this work for an in-house tool with no connector listing?
Yes, an in-house tool that appears in no connector directory is exactly what a custom connector is for. We build it specifically for your system, mapping its API or database directly, including internal apps and admin panels that run on-prem behind a firewall with scoped read and write access.
Off-the-shelf connectors only exist for popular products. Your internal scheduler, your custom admin panel, or the database a single team relies on will never show up in a directory, which is precisely where a purpose-built connector earns its keep.
If the tool has an API, Claude can call it. If it has a database, the connector can query and write to it. Either way the access stays scoped to the actions and records you approve.