Role-Aware Claude MCP + Company Second Brain

The problem with giving Claude access to your database

The default Supabase MCP connector hands its caller a single key that reads and writes every table — there is no per-user role enforcement.

Somebody on the ops team has Claude Team, plugs in the database, and the whole thing feels magical. They show it to their admin. They show it to the rest of the team. Everyone wants it. And then the wall hits.

The admin can't say "this team member can see their own consultants, not the whole company" or "this person can approve expenses but not delete users." The connector treats every caller as a superuser. So the magical setup quietly stays on one laptop, and the rest of the team is back to asking the admin for screenshots and CSV exports.

What we built — two pillars

At GrowXLabs we shipped two layers that work together: a role-aware MCP server that mirrors the app's access model, and a structured second brain that holds the knowledge a database can't.

• Pillar 1 · Role-aware MCP. A Claude.ai connector deployed as a single serverless function. Each team member gets a personal token. Queries run as them — what they see in Claude is exactly what they'd see in the app. Same admin / project-admin / consultant / volunteer scoping, enforced by the database, not by trust. This is one of the patterns we ship from our AI & automation practice.
• Pillar 2 · Company second brain. A curated Project Knowledge layer in Claude.ai that holds the things the database can't — how the company operates, who the people are, the SOPs, the decisions and why, the playbooks the team runs again and again. Claude answers in the company's voice, not from generic priors.

How the role-aware MCP actually works

Five properties make this safe enough to roll out to an entire ops team.

1. Per-user tokens. A one-line CLI mints a personal JWT per team member. Tokens carry the user's id and role; nothing is shared. Onboarding a new team member is a single command and a token paste.
2. Hardened SELECT-only read tool. The read tool accepts a single SELECT statement only. Multiple statements, writes, DDL, and admin verbs — INSERT, UPDATE, DELETE, DROP, ALTER, GRANT, COPY, VACUUM — are rejected before the query ever reaches the database. The SELECT executes through a SECURITY INVOKER Postgres function, so the caller's RLS policies apply automatically.
3. Writes via the company's existing API. When the assistant needs to do something — approve, assign, schedule — it calls the same endpoints the admin UI calls, with the same JWT. Every validation hook, audit log, and role check that already exists in the app fires identically. There is no parallel write path.
4. Append-only audit by default. Every tool call — who, when, which tool, what input — is logged to an audit table the admin can query directly. Nothing happens in the dark.
5. One CLI command per onboarded team member. No infrastructure for the admin to operate. The MCP server lives on Vercel as a serverless function and deploys on GitHub push.

What the company second brain actually holds

The second brain has seven layers, each kept short and current.

• App — how the product is shaped: data model, roles, key flows.
• People — one short file per team member, with how they like to be talked to, what they own, and prior learnings worth carrying forward.
• Processes — the SOPs the team follows.
• Decisions — architecture decision records in two paragraphs each: what changed, why, what we'd revisit.
• Learnings — the we got bitten by this once file that saves the next person from repeating it.
• Playbooks — reusable workflows the assistant runs on natural-language triggers.
• Projects — one hub per live engagement so context doesn't bleed between them.

The rule we kept: anything that lives in the database stays there and is read live; the brain only holds what the database can't.

What changed for the team

The shift is from "one person holds the keys" to "every person can ask the system about their own work — in plain English — with no access broader than they already had."

The admin stops being the human API. Custom reports stop being a request queue and become a sentence. The team's own institutional knowledge is now something the assistant uses by default, instead of something each new joiner has to absorb on their own.

Where this fits

This pattern works for any operations team running on Postgres with row-level security and an existing API.

We've deployed it for field operations, and the same shape applies to healthcare staffing, logistics, multi-tenant SaaS, and any other context where different people on the team should see different slices of the same data. The precondition is simple: the company already runs on a database that enforces who-can-see-what. We extend that boundary into Claude rather than weakening it.

How we built it

Stack we'd reach for again on the next deployment.

• Vercel serverless for the MCP server — minimal infra to operate.
• Supabase for data, RLS for role enforcement, and a hardened safe_select RPC for read-only natural-language queries.
• The company's existing API surface as the write path — no parallel writes, so audit and validation never drift.
• Per-user JWTs minted via a small CLI — one command per onboarded team member.
• Project Knowledge in Claude.ai as the home for the second brain — kept in version control so it doesn't rot.

Repeatable across customers. The MCP server template, the safe_select pattern, the brain structure, and the per-user token mint flow port directly to the next ops team that needs this.