Case study: no connector existed
A Claude connector for a bespoke internal referral portal
An in-house referral application that no directory listed, so no connector existed. We built one so Claude can read and write referrals directly, with scoped access and human-in-the-loop on sensitive actions.
How do you build a Claude connector when no connector exists for the app?
Custom connector for an internal referral portal: when none exists, we write a custom MCP connector against the app's own API. For this client's referral portal, which no directory listed, we built one specifically for it so Claude can read and write referrals directly, scoped to the user's own permissions.
Key takeaways
- The portal was a bespoke in-house app with no directory listing and no off-the-shelf connector.
- We built a custom MCP connector against its API so Claude can read and write referrals in-conversation.
- Access is scoped to each user's own permissions, never broader.
- Sensitive actions are gated behind human-in-the-loop confirmation.
What was the situation?
The client (anonymized) ran referrals through a custom internal portal their own team had built. It was central to how work moved, but it lived nowhere in any connector directory, so there was nothing to install and no read-only stopgap to fall back on. Staff worked referrals by hand in the portal UI, then re-typed the same details into Claude to draft messages or summaries. The data and the assistant never met.
What did we build?
What we built is a custom MCP connector for the client's internal referral portal, written against its existing API. Read and write live in separate tools, the connector authenticates as the user's own account, and sensitive actions route through a confirmation step. We own the build, hosting, and OAuth lifecycle.
We built and host a custom MCP connector for the portal, written against its existing API. Read and write are separated into distinct tools, the connector authenticates as the user's own account, and sensitive actions are routed through a confirmation step. The client did not stand up or run an MCP server themselves: we own the build, hosting, OAuth lifecycle, and the schema changes that follow when the internal app updates.
What can the connector do?
- Read referrals: search, filter, and summarize referrals by status, owner, partner, or date without leaving the conversation.
- Create referrals: open a new referral from a chat description, with the required fields validated against the portal's schema.
- Update referrals: change status, reassign an owner, add notes, and move a referral through its stages.
- Sensitive actions gated: closing out, withdrawing, or notifying an external partner triggers a human-in-the-loop confirmation before anything is committed.
What was the outcome?
Referrals are now read and updated from inside the same Claude conversation where the team drafts and reasons, so the manual re-typing between the portal and the assistant is gone. Status changes still pass through a confirmation step, so nothing advances without a person approving it.
Frequently asked questions
Can Claude connect to an internal app that is not in any connector directory?
Does the connector let Claude see more than the user can?
How are risky or outbound actions handled?
Have an internal tool with no connector?
This is the kind of build we do for proprietary and in-house systems. See how we approach connectors for internal tools.
Tell us what you run. We'll build the connector.
Pick your tool, choose what Claude should do, and get an instant scope and price. No call required.