All work

Case 02

Building MCP connections

What changed Each person’s agent reaches only what that person may see, with no shared keys.

MCP is the standard way an AI agent uses a real tool. I built connectors that speak it and hardened the gateway every call passes through, so agents could use company apps without ever holding a key.

  1. 01
    Agent asks for a tool

    An agent decides it needs outside data, so it calls a tool over MCP.

  2. 02
    Gateway checks the grant

    The gateway confirms this agent holds that tool’s permission, and that the tool isn’t switched off.

  3. 03
    Vault attaches the user’s token

    The vault adds the signed-in person’s own token. The agent never sees it.

  4. 04
    The MCP server calls the app

    The connector turns the tool call into a request to the real app.

  5. 05
    Only what this person may see

    The app answers with what this person is allowed to read, and the answer flows back.

My role
Built the per-user OAuth (PKCE) connector and its MCP server. Audited the tool gateway and shipped its reliability fixes.
Scope
Every tool call from every agent on the platform passes through this gateway.
Stack
Go · MCP · OAuth 2.0 with PKCE · token vault · structured logs and metrics
Shipped
Live in production: each person’s agent searches only what that person may see. Gateway: per-backend timeouts, isolated cancellations, metrics.

How we decided

The decisions that shaped every connector.

01

We refused a shared key

Each person signs in with their own account, using OAuth with PKCE. Apps check permissions against the token’s owner, so a shared company key would have shown everyone the same documents.

Per-user access
02

The vendor ignored our rules, so we moved them

The gateway enforces permissions before the vendor is ever contacted. Vendor-hosted servers run none of our code, so they ignored our permission headers.

Gateway
03

Then we built our own

Our own MCP server publishes its tools, checks permissions itself, and never keeps a token between requests. The vendor’s server couldn’t, and our copy of its tool list kept drifting.

Tested end to end

The tools

One name, one permission.

Every tool is named service_product_action and carries exactly one permission. Moving to our own server was the chance to fix vague names. An agent can only call what its owner granted, checked before the app is contacted.

How I tested it

First against a fake app, then with a real teammate.

01Against a fake app

The token rules, proven in tests.

Before any real app was involved, a fake one checked that each person’s token is used only for them, and that a request without one is refused.

~/connector-mcpzsh
% go test ./...
✓ the user’s token becomes the outbound credential
✓ back-to-back callers never share a token
✓ no credential → refused, the app is never called
✓ a tool without permission never reaches the app
✓ the tool catalogue is served without credentials
ok connector-mcp all green

02With a real teammate

Ask a question. Don’t name the tool.

  1. 01
    I didn’t test it myself

    A teammate who didn’t build it asked their own agent.

  2. 02
    We never named the connector

    Just a normal question, the way anyone at work would ask it.

  3. 03
    The agent chose the tool

    It picked the right connector by itself and found the answer in a ticket.

  4. 04
    It showed its working

    It named the tools it used, so the answer could be checked.

What’s the account code for our newest customer?
called knowledge_search_query · matched an onboarding ticket
It’s AC-1042. I found it in their onboarding ticket, using the company knowledge search.

Where it plugs in

Many apps, one gateway.

Connectors for many kinds of app, all reached through the same gateway. Some things broke along the way, and each one got a fix.

What broke along the way

Lessons

  1. 01

    Permissions belong to people, not keys

    A shared key would have shown everyone the same documents. Per-user sign-in cost more work and was the only honest answer.

  2. 02

    Don’t outsource your rules

    A vendor server ignored our permission headers, so enforcement moved to the gateway, before the vendor is ever called.

  3. 03

    Better logs find bugs nobody reported

    The structured logs I added exposed a connector that was failing silently in production. I fixed its routing.

  4. 04

    Let someone else prove it

    The real test was a teammate asking a normal question and the agent choosing the right tool on its own.