How to connect Claude to your client records with MCP

1. 01OAuth. In your assistant, add an MCP connector with the server address, https://unboundoperators.app/api/mcp. The server supports OAuth 2.0 with dynamic client registration, so the assistant registers itself and asks you to sign in and authorize. Claude is the client we test with. Any MCP client that supports OAuth should work, though we have no code specific to other assistants.
2. 02API key. Create a key in the workspace for clients that do not do OAuth. The key inherits the permissions of its owner and can be narrowed to fewer permission groups.
3. 03Service account. For an agent that runs on its own, create a service account. It cannot sign in, starts with no permissions, reaches the workspace only through keys, and does not take a seat on the bill.

Our advice for a first agent is the third option. Give it its own service account and grant only the permission groups its job needs, so the first mistake it makes is a small one.

An agent can do what the person or service account that connected it can do, never more, and only inside one workspace. That makes the person who connects it the real control, so choose who connects an agent as carefully as you choose who gets Finance access.

• Permissions are per person and per permission group. An agent connected by someone without Finance access sees no invoices.
• A key can be narrowed below its owner's permissions, and anything outside its scope goes to the review queue.
• Every query is scoped to the workspace that makes it, and the database has row level security on every table.
• The catalog an agent sees is filtered by the workspace's active modules. Of the 446 names in the catalog, 15 are retired and only point to their replacement.

The tools are grouped by module, and every module sold has them. In the catalog on 2026-10-23 the largest groups are Clients and portal with 82, Documents, proposals and library with 82, Core with tasks with 68, CRM with 55, Calendar with 51 and Finance with 40. Forms, Skills, KOL and Campaigns have between 8 and 17 each. Those counts include retired names.

By default, an action the person is allowed to take runs directly. That is fast, and it is also the risk: 315 of the 431 working tools write, and an agent with write access can write the wrong thing.

The workspace setting "approve my own MCP actions" decides this. Switch it off and every action an agent proposes waits for a person to approve or deny it from the workspace. If you are connecting an agent for the first time, or one that touches invoices or sends documents, we would switch it off for the first weeks and read what the agent proposes.

1. 01Create a service account for the agent and give it only the permission groups its job needs.
2. 02Send everything to review by switching "approve my own MCP actions" off, so every action waits for a person.
3. 03Read the review queue every day for a week and note what the agent got right and wrong.
4. 04Widen the permissions, or let it act directly, only for the actions it handled well.

MCP access comes with Core at no extra cost, service accounts and keys do not take a seat, and Unbound OS does not resell AI or add a markup. You pay your model provider directly, for the assistant you already use. Each module's tools appear when that module is on for the person, so the tool count grows as you add modules. The pricing page shows what each module costs.

Most of the larger platforms in this category now run official MCP servers too, so having one is no longer the difference. The difference is that one connector here reaches the whole client operation, from proposal to invoice, on the same record. The full tool list by module is on the AI agents and MCP page.

Hold off if nobody on your team has decided who owns the agent, because an agent is only as careful as the person whose permissions it borrows. Hold off if your permission groups are still wide open, because the agent inherits that too. Fix the permissions first, then connect.