Custom Claude connector FAQ

A custom Claude connector is a small MCP server we build for your specific software. It exposes that tool's data and actions to Claude, so Claude can read records and, with the right setup, write back during a conversation you start. It is built for your exact system, including tools that appear in no public directory.

MCP (Model Context Protocol) is the open standard Claude uses to talk to outside software through structured tools. A connector is an MCP server that translates your application's data and actions into those tools. When you build on MCP, Claude can list the available actions and call them safely inside a conversation rather than guessing.

Custom Connectors builds full read and write MCP connectors for the software a business already runs with Claude. We handle the build, hosting, authentication, and ongoing maintenance, so a non-technical team can use Claude inside their tools without writing code or operating an MCP server of their own.

A Claude connector works inside a conversation you open: you ask Claude to do something, Claude calls the connector's tools, and the connector reads or updates records in your software using your own credentials. Nothing runs on its own in the background, so every action traces back to a request you made in chat.

You do not need to be technical to use a custom connector. We build, host, and maintain it for you, then your team simply talks to Claude in plain language. The connector handles the protocol details underneath, so the people using it work in everyday English while we keep the moving parts running.

The difference is fit: prebuilt connectors cover popular apps in a generic way, while a custom connector is shaped around your exact software, fields, and workflows. Custom connectors reach in-house tools, niche platforms, and configurations that no public catalog supports, and they expose only the actions your team actually needs.

If your tool already has a connector but it is too limited, a custom build replaces it with the full capability. Built-in and directory connectors usually ship a fixed, generic tool set that stops at the basics. We build a connector with the specific actions, custom fields, and workflows the built-in one leaves out, and we host and support it.

Yes, Claude can write back to your software, not just read from it. A custom connector exposes write tools, so Claude can create and update records, draft messages, and move work forward inside a conversation. Create and update flow normally, while destructive or outbound actions such as delete and send wait for a human confirmation.

Besides reading records, a Claude connector can create new entries, update existing ones, attach notes, change statuses, and assemble data across views. The specific actions depend on what your software's API allows and what your team approves during the build. We scope each tool to a real job rather than exposing everything at once.

Claude can update records and statuses through a connector, but only when you ask it to inside a conversation. Create and update actions run as part of your request, so a status change happens because you prompted it. The connector does not run on a schedule or change data on its own without you in the loop.

No, Claude will not delete or send things without your approval. Those higher-risk actions are gated behind a human-in-the-loop confirmation built into the connector. Claude can prepare a deletion or draft an outbound message, but the action only executes after you explicitly confirm it, so nothing irreversible happens by surprise.

A connector can pull data from several tools in one conversation when you have a connector for each system involved. Claude can then read across them inside a single chat, line up the records, and act on what it finds. Each connector still respects its own software's permissions and confirmation rules.

Yes, Claude can generate reports and summaries from your live data through a connector. It reads current records on request, then drafts the summary, rollup, or report you asked for inside the conversation. Because the read happens when you prompt it, the output reflects the state of your software at that moment, not a stale export.

No, the connector does not give Claude more access than you have. It authenticates as your account and inherits your existing permissions, so it can only reach what you can already reach. It never grants Claude more access to a system than the account holds, and it acts inside a Claude conversation you start.

Authentication for a custom connector uses your software's own login, typically OAuth where the platform supports it. You sign in through that system's standard flow, and the connector receives a scoped token rather than your raw password. Access stays tied to your account and can be revoked from your software's settings at any time.

Your data is not sent anywhere it should not go. A connector passes only the records involved in your request between your software and the Claude conversation. It does not copy your database, build a separate store of your information, or share data with outside parties. Each call moves the minimum needed to answer what you asked.

Yes, you can limit what a connector is allowed to do. During the build we scope each tool to specific actions and records, so you decide which parts of your software Claude can touch. We can keep a connector read-only, restrict it to certain fields, or require confirmation on more actions than the defaults.

Once a connector is built, the people you authorize can use it, and each person signs in with their own account. Because the connector inherits each user's permissions, two team members may see different records through the same connector. Access follows your software's existing roles rather than creating a new shared key.

If you revoke access to a connector, it immediately loses the ability to reach your software. Because the connector relies on a token tied to your account, removing that authorization from your platform's settings cuts off its access at the source. Claude can still chat, but it can no longer read or write through that connector.

A custom Claude connector is priced as a one-time custom build fee plus ongoing monthly maintenance. The build fee reflects the scope and complexity of your software and the actions you need, while maintenance keeps the connector working as your tools change. We quote both figures after scoping your specific systems together.

The build fee for a connector is determined by scope: how many tools and actions you need, how complex the underlying software is, and whether it offers a clean API or something more custom. A focused read connector for a well-documented platform sits at one end, and a deep multi-action build for an in-house system at the other.

There is a monthly maintenance cost because the software a connector talks to keeps changing. APIs get updated, authentication shifts, and fields are added or renamed over time. Maintenance covers monitoring, applying those updates, and fixing breakages, so the connector keeps working rather than quietly failing months after it ships.

Pricing can reflect volume alongside the build fee and monthly maintenance. A connector handling occasional lookups sits differently from one driving heavy daily activity across a large team. We account for expected usage when we scope the engagement, so the arrangement matches how much work the connector actually carries.

You generally need a Claude plan that supports connectors so your team can open conversations and call the tools we build. We focus on the connector itself: the build, the hosting, and the maintenance. We help you confirm the plan and setup that fit your team during scoping, then build against it.

A connector engagement includes scoping your software and use cases, building the MCP connector, setting up authentication, hosting it, and maintaining it over time. You receive a working connector your team can use inside Claude plus the ongoing care that keeps it healthy as your tools evolve, rather than code handed over for you to run.

The connector build process works in clear steps: we scope your software and the actions you need, design the tools, build and test the connector against your system, set up authentication, and host it. We then confirm it behaves correctly inside real Claude conversations before your team relies on it for daily work.

To build a connector we need access to the software involved, details on its API or integration options, and a clear picture of the actions your team wants Claude to perform. Where a platform uses OAuth, you authorize through its standard login. The clearer the workflows you describe, the more precisely we can scope each tool.

Connectors keep working for as long as you maintain them. Software APIs change over time, so a connector left untouched can eventually break. With ongoing maintenance we monitor for those changes and update the connector as they happen, which is why maintenance is part of the engagement rather than an afterthought.

When the software's API changes, maintenance is what keeps your connector running. We watch for breaking updates, adjust the connector's tools and authentication to match, and test that actions still behave correctly. The goal is for your team to keep using Claude through the connector without noticing the change underneath.

Yes, we can add new actions to a connector later. As your team finds more it wants Claude to do, we extend the connector with additional tools, scoped and confirmed the same careful way as the originals. A connector can grow with your needs rather than staying frozen at whatever it covered on day one.

A custom connector is hosted by us as a running MCP server, so your team does not stand up or operate any infrastructure. We handle deployment, uptime, and the updates that keep it healthy. You connect to it from Claude and use it, while the hosting and operations stay on our side of the engagement.

To get started, open the build tool, pick your software, and choose what you want Claude to do. You see what it unlocks beyond any built-in connector along with an instant scope and price, with no call required. From there we confirm the details and build it, and you can still book a time to talk if you prefer.

We can connect Claude to a wide range of software: CRMs, project trackers, support desks, billing systems, databases, internal dashboards, and more. If a tool offers an API or a workable integration path, it is a candidate for a custom connector. We focus on the systems your team uses daily rather than a fixed catalog.

Yes, we can connect Claude to an on-prem system behind a firewall, provided there is a safe path to reach it. On-prem and firewalled environments need extra planning around network access and authentication, so we scope those details up front. The connector still inherits your permissions and respects the same confirmation rules.

Yes, we can build a connector for an in-house or custom-built tool. Tools written for a single company rarely appear in any public connector directory, which is exactly where a custom build helps. As long as your tool exposes an API or another integration point, we can wrap it in a connector Claude understands.

We focus on connectors for Claude, built on the open MCP standard. Because MCP is an open protocol rather than a closed format, the work centers on giving Claude clean, well-scoped access to your software. If you have other AI tooling in play, we can discuss how an MCP-based connector fits during scoping.

If your software does not have a public API, a connector may still be possible through other integration paths, depending on what the platform exposes. We assess each system during scoping to confirm a safe, supported way in. Where no workable path exists, we tell you plainly rather than promising a connector we cannot maintain.

Yes, one team can use connectors across many different systems. We build a separate connector for each piece of software, and Claude can call several of them within a conversation. Each connector keeps its own permissions and confirmation rules, so broad coverage across your stack does not loosen the safeguards on any single system.