MCP connectors for team context — not another personal tool pile
MCP connectors let agents use your apps. The difference is whether credentials and context stay with the person or with the team. How BitsWeave brokers turn MCP into shared team context.
Cursor has a GitHub MCP connector. Claude has a mail connector with a different token. ChatGPT has a Grafana connector, or a key pasted into the project settings. Each connector answers. Each one also belongs to one person, on one machine, in one product.
That is a personal tool pile. It is not shared team context.
An MCP connector lets an agent use an app. The Model Context Protocol is the language the agent speaks. The connector is the install: a credential, a list of actions, and a place the call is recorded. If the credential and the context stay with the person, the next teammate starts from zero. If they stay with the organization, Claude, Cursor, and ChatGPT can see the same connectors.
BitsWeave keeps the install on the org. Brokers are the connectors. The MCP surface is how each host reaches them. For the audited door those calls go through, see the tool gateway. This post is the other half. It is how MCP connectors become shared team context instead of another drawer of personal servers.
What people mean by MCP connectors
People look up MCP connectors, an MCP connector, and Model Context Protocol connectors because an agent needs to leave the chat. It needs to read a pull request, send mail as the company, or query a dashboard. MCP is the standard way to list tools and call them. A connector attaches one external app to that list.
A connector has three parts, whoever owns it:
- A credential for the external app. That is an OAuth grant, an API token, or a webhook secret.
- A catalog of actions the agent may take, and of events the app may send.
- A record of the call, so someone can say who asked and what came back.
None of those parts require the secret to live in the agent's config. That is a choice. A personal MCP connector puts all three on one machine. A team connector puts them on the organization and lets each host attach to that one install.
Agent connectors is the wider name for the same job. Any adapter that lets an agent reach an app is an agent connector. Many of those adapters now speak MCP. The protocol does not choose the owner. The install does. A local server is a fair prototype for one afternoon. It fails as a plan when every teammate grows another copy.
What a personal MCP connector buys
A personal install buys one person a working afternoon. You add a GitHub server to Cursor, put a token in the environment, and the agent reads the diff. The organization still cannot point at one install and say which credential ran.
The token sits with the person. It lives in a config file, a host secret store, or a vendor project only that person can open. Rotation means editing that file. A second laptop needs a second copy. When someone leaves, someone else has to find every copy.
The catalog sits with the person. A teammate who opens Claude does not inherit the Cursor servers. They install their own MCP connector, often with a second token for the same GitHub organization. One person can post a review. Another can only read. Nobody wrote that split. Each token allows whatever that token allows.
The result sits in the chat. The connector returns a diff, an alert, or a thread into that session. The next session does not have it unless someone pastes it. The call finished. The team still has no shared page. A private recall store has the same limit. What is agentic memory? separates that per-agent job from shared team context.
A personal connector is still right for a solo experiment. It becomes a pile when every new host grows another copy.
One Tuesday, two shapes
In the personal shape, one engineer has a GitHub MCP connector inside Cursor. The agent reads a diff and drafts a review. A teammate opens Claude and pastes the diff, because Claude has no GitHub connector. A third person pastes the thread into ChatGPT for the incident note. Three hosts hold fragments. None of them hold the install. Rotate the token that night, and Thursday's laptop starts from zero.
In the team shape, an admin has already connected GitHub, mail, and Grafana once, on the organization. Each person adds the BitsWeave MCP server to the host they use. They do not paste the GitHub token into Cursor, then into Claude, then into a ChatGPT project. The agent in Cursor reads the diff through the org install. The agent in Claude sees the same broker. The review can land as a record the next session cites.
The apps did not change between those two days. The owner of the connector did.
Team MCP keeps one install
Team MCP means the connectors belong to the organization. People and agents attach to that install.
BitsWeave models the connector as a broker. Events come in from the external system. Actions go out through the stored credential. GitHub can deliver a pull request. Grafana can deliver an alert. Email can send as the org. A webhook broker can take JSON from a system you already run. The external system talks to BitsWeave. The agent talks to BitsWeave.
An admin connects the external account. That step is an organization act, not a line in a prompt. BitsWeave stores the credential on the install. The product keeps one install per broker per organization. The agent holds a credential for BitsWeave. It does not receive the GitHub token, the Grafana key, or the mail secret.
Permissions follow the member. Reading a diff is not the same action as posting a review. The same rules apply when a person uses the product and when an agent calls a tool. You can disable an install and keep the history, or uninstall it, drop the credential, and keep the audit trail.
The tool gateway is the interface on the front of that install. The agent discovers tools there and acts through one call. This post stops at ownership. The MCP connector is an object the org holds. It is not a file that travels with a laptop.
The same connectors on every host
Each host still needs the BitsWeave MCP server added once.
After the server is connected, the advertised list stays short. The agent sees meta tools, seeds for the org's domains, and seeds for brokers that are actually installed. Install a broker and its actions show up on every connected host. Uninstall it and those seeds leave. Cursor does not keep a private GitHub server that Claude cannot see. ChatGPT does not keep a Grafana key the org cannot rotate in one place.
Search can still name a broker the org has not installed. Those rows are not a hidden credential. A person connects the app. The agent does not scrape a token out of a document and call the vendor on its own. The call still runs as the signed-in member, in the active organization.
A local MCP server can sit next to the agent for a one-off on that machine. Use the org install when a teammate must see the same app tomorrow. Open a second host. If you must paste a new secret, the connector is still personal. If the broker is already listed, it belongs to the team.
How connectors become team context
A connector that only returns text into one chat has finished a tool call. It has not created team context.
Shared team context is the model of the work that stays after the tab closes: sessions, records, decisions, and the links between them. Brokers are one way app events enter that model. A review, an alert, or a note can land as a record the next session cites. The next person does not need the first person's MCP config.
The context graph is the walk from a focal record out to the objects around it. A personal MCP connector never becomes that neighborhood. The payload dies with the session. A broker that writes into the org gives the next host a place to start.
The gap shows up when the work has more than one step. An agentic workflow plans, calls a tool, checks the result, and continues. The plan fails at the handoff when the tool result never left the first host. Team connectors keep the call on the org side, so the work can resume in Claude, in Cursor, or in ChatGPT. Agentic memory, for a team, is that continuity: decisions, records, and next steps any connected agent can read, because the connectors belong to the org.
Two limits belong in the open. BitsWeave does not scrape chat memory out of Claude, Cursor, or ChatGPT. Those products stay the hosts. The organization keeps what landed through sessions, tools, records, and the connectors you installed. A connector also does not invent a fact the app did not send. If GitHub did not deliver the pull request, the graph does not contain it.
Personal pile versus team connectors
Both designs can be competent. They answer different questions. Use the table as a filter.
| Personal MCP connector | Team MCP connector | |
|---|---|---|
| Who owns the install | One person, one host | The organization |
| Where the token lives | The agent's config | The org's broker install |
| Who sees the catalog | Whoever copied the config | Every host on the BitsWeave server |
| Where the result lands | That chat | The org's tools and records |
| How you uninstall | Edit files on each machine | Drop the credential, keep the trail |
| What the next teammate gets | A new setup | The same connectors |
Questions to ask before you buy
Ask these in a demo. The answers separate a personal tool pile from team MCP.
- Where does the token live after install? If it lives in the agent's config, you have a personal MCP connector. If it lives on an org install, you have a broker.
- Does a second host see the connector without a second token? If Claude, Cursor, and ChatGPT each need their own copy, the catalog will drift. If they share one BitsWeave server, they share the agent connectors.
- Can you revoke one install and keep the trail? A team connector can drop the credential and keep the audit record. A token in a dotenv file has no trail once you delete the file.
- Where does the result go when the chat ends? If it lives only in that transcript, you bought a tool call. If the next session can cite the record, you bought shared context. The context graph is the walk. The connector is how the app entered the graph.
- Whose permission runs a write? If the answer is "whatever the token can do," the org is outside the call. If the answer is the member's role, the write is that person's action.
- What happens when someone leaves? A personal pile means a hunt through config files. A team connector means you remove the member. The broker install stays with the org.
A personal connector for a side project can sit next to team connectors for the apps the company shares. Mix them by accident, and the GitHub token lives on one laptop.
Leave the connectors with the org
Add the BitsWeave server to the hosts people already use. Install the brokers for the apps the team actually shares. Leave those credentials on the organization.
The hosts can change. You should not have to rebuild the connector list each time someone opens a different one.
You can connect Claude, Cursor, or ChatGPT at bitsweave.com. The brokers stay with the org. The next session starts from those same connectors.