Not the public
connector. Yours.
A case study in a decision. When a platform ships its own MCP connector, why would I build a different one from scratch for a client. This page is what I built, how it is deliberately not the public one, and the reasons that shape matters for an enterprise.
Where a brand keeps
its assets.
Bynder is a digital asset management platform, a DAM. It is the single place a company keeps its approved brand material: photos, videos, logos, artwork and brand guidelines, all tagged with metadata so the right people can find the right file and use the on-brand version instead of an old copy from someone's desktop.
It does that job well. The friction shows up in the last mile. To answer a small question like "what is the latest hero banner for this campaign, and what is its download link", a non-technical team member has to open the platform and click through the interface, every single time. When a whole team is doing that all day, the lookups add up, and the people doing them are usually operators who just want the file, not another app to learn.
A client already lived
in Bynder.
One of my clients, a large enterprise I have worked with for years, was already running Bynder. I had built their two-way sync between Bynder and Airtable, so I knew their asset setup from the inside. As their team came off the end of their Bynder onboarding, they started filing a steady stream of small tickets: find this asset, update that tag, grab this download link.
That was the moment the idea landed. Instead of having the team navigate the interface for every one of those requests, why not let them just chat with their Bynder data from inside Claude. So I built the first version of a Bynder MCP server for them. It worked, and it pointed at something bigger: a managed connector I could stand up for our own users, where I control the purpose and the guardrails of every tool the AI is allowed to touch.
Same platform.
A different shape.
A platform's own MCP connector is one shared service that every customer plugs into. It is the fastest way in, and for plenty of teams it is the right one. But it is built for everyone, it is managed by someone else, and every user reaches it through the same shared door.
What I built is the opposite by design. Each client gets a separate connector of their own, fully isolated, wired to their own login, carrying their own rules, owned by them. Same underlying Bynder, a very different shape. Here is the contrast in one picture:
The reason is not aesthetic, it is about access. The enterprise teams I work with, across Airtable, Make and now Bynder, keep making the same call: a team with its own engineers does not want to hand access to its systems to a service it does not manage. When AI security is the live worry in every room, owning the connector wins. So the whole build is shaped to give them the version they can own.
One isolated Worker,
per client.
The server is a remote MCP server running on Cloudflare Workers, with a Durable Object holding each chat session. It speaks the modern MCP transport (Streamable HTTP) plus legacy SSE, so it plugs straight into MCP-aware chat apps as a custom connector.
The code lives in one shared repository. Everything else is per client. Each client gets their own Worker, their own unique URL, their own storage (their grants, their tokens, their app credentials), and their own session object. Nothing is auto-distributed between them: a client only ever runs the code from its own last deploy, and no client can see another client's data. Shipping an update is a deliberate, per-client deploy, so I can roll out to one first and the rest when I choose.
flowchart TD SRC["One shared codebase: tools, the OAuth bridge, the upload engine"] --> C1["Client A, own Worker"] SRC --> C2["Client B, own Worker"] SRC --> C3["Client C, own Worker"] C1 --> A1["Own URL, own storage for tokens and credentials, own session"] C2 --> B1["Own URL, own storage, own session"] C3 --> D1["Own URL, own storage, own session"]
Standing a new client up is close to a one-command job. A provisioning script creates that client's storage, writes their config, deploys their Worker, and prints the exact links to hand over. The target from empty to connected is about five minutes.
I don't build auth.
Bynder does.
The most important decision in the whole build was to write no authentication of my own. The connector stands on Bynder's own login, OAuth 2.1 with PKCE, with Bynder as the identity provider. When a user connects, they log into their own Bynder in the browser and approve it there. That removes an entire class of risk I would otherwise have to own.
From then on, the connector only ever acts as that user, with exactly the permissions Bynder grants them. A tool a user is not allowed to use simply returns a clean refusal from Bynder itself. The access rules stay where they belong, inside Bynder, not in a policy I have to reinvent.
flowchart TD A["User adds the connector URL in Claude, ChatGPT or Copilot and clicks Connect"] --> B["The Worker redirects to the client's own Bynder login"] B --> C["User approves in the browser, OAuth 2.1 with PKCE"] C --> D["Bynder sends back a code, the Worker exchanges it for tokens"] D --> E["The user's token is stored in that client's own storage and auto-refreshed"] E --> F["Every tool call runs as that Bynder user, limited to what Bynder allows"]
The keys never touch
me, or the AI.
Each client creates the OAuth app inside their own Bynder portal, which gives them a client id and secret. Making a new client ridiculously easy to connect meant solving one thing carefully: how do those keys get into their Worker without ever passing through me.
The answer is a one-time setup link. The client opens it and pastes their id and secret into a simple form. The values write straight into their own Worker's storage. I never see them, they are never emailed to me, and they are never shared with any AI model. The link is single use: once the credentials are saved, it locks. After that the client adds the connector URL to their chat app, clicks Connect, and they are in. Credentials in one place, owned by them, invisible to everyone else.
flowchart TD P["Provisioning creates the client's Worker and a unique URL"] --> Q["Client makes an OAuth app in THEIR Bynder portal, gets a client id and secret"] Q --> R["Client opens a one-time setup link and pastes the id and secret"] R --> S["Values write straight into the client's own storage. I never see them. No AI ever sees them."] S --> T["The link locks after first save. Client adds the URL to Claude, ChatGPT or Copilot and connects."]
Every tool has a
purpose, and a boundary.
This is the piece I care about most, and the reason it is worth building rather than renting. A bare connector is little more than a wrapper around API docs. The real work is teaching the AI when to use each tool, and just as importantly, when not to.
Every tool is described in full
Each of the thirty-plus tools ships with its purpose, the cases where it should be used, and the cases where it should not. That last part is the underused one, and it stops the model reaching for the wrong action.
Skills speak the client's language
On top of the tools sit skill files that map a client's own vocabulary to the right action. When an operator uses an internal phrase, the model already knows what it means in their world, so they talk in their own words and still get the right result.
The tool surface is set per client
Each client's connector exposes exactly the tools they should have: read-only where needed, downloads on or off, destructive and admin tools hidden by default. Bynder's own permissions enforce the rest, so nothing is exposed that a user could not already do.
Because every client runs their own isolated instance, these guardrails are per client too. One client's vocabulary and rules sit happily alongside another's, with no collision, and I keep refining each set as the client's own setup matures.
Ask in plain words.
See the media in chat.
Once connected, a non-technical person just asks. Find an asset by a partial name, see it rendered inline in the chat rather than as a link to click, pull its download URL, read its full metadata, update a tag, or browse a collection. The media shows up in the conversation, so it feels like talking to the library, not querying a database.
It is not tied to one AI app either. The same connector works in Claude, in ChatGPT, and in Microsoft Copilot. Add the URL, connect once against Bynder, and the team chats with their own media from whichever assistant they already use.
A connector each client
owns, in minutes.
The team that started it can now chat with their Bynder assets instead of clicking through the interface for every lookup. And because the architecture is one isolated, owned connector per client, the same approach scales to the next one without touching the last: a new Worker, a new URL, their own keys, their own rules, live in about five minutes.
Got a tool your team
still clicks through by hand?
If your team lives inside a platform and wants to just talk to it instead, bring it to a Sprint. We'll build a connector you own, wired to your own login, with the guardrails set the way you want, and you'll leave running it yourself.