Skip to main content
An MCP connection points Bag of words at a Model Context Protocol server. The server’s tools become tools the agent can call during a conversation — creating a Monday item, searching Notion, opening a GitHub issue, querying an internal service.
This is the opposite direction from the Bag of words MCP server, which lets Claude or Cursor query your data. Here, BOW is the client and the external server provides the tools.
MCP connections are beta. Field names may change.

​
Presets vs custom servers

Bag of words ships one-click presets for common servers — Monday, Notion, Linear, Atlassian, GitHub, Sentry, HubSpot, Google Drive, and X. A preset fills in the server URL, transport, and OAuth settings; you just sign in. Presets create an ordinary MCP connection, so everything on this page applies to them too. For anything else, add a custom MCP server and supply the details yourself.

​
Connection fields

​
Authentication

An MCP connection authenticates in one of two ways: with one shared credential that an admin enters once, or with per-user sign-in, where each person connects their own account and the agent calls tools as them.
A bearer token or API key is shared by everyone who uses the connection. Every tool call runs as that one identity, so the MCP server cannot tell users apart. Use one of the sign-in options when the server should apply each person’s own permissions, or forward identity with User context forwarding.

​
Per-user sign-in

Both OAuth options make the connection per-user: after the admin saves it, each user selects Sign in the first time they use it and completes the provider’s authorization. BOW stores each user’s token encrypted, refreshes it automatically, and sends it on every tool call. Until a user signs in, their tool calls fail with a prompt to connect. Per-user auth on MCP connections does not require an Enterprise license. The two options differ only in where the OAuth client comes from:
  • Sign in (auto-register / DCR) — BOW reads the server’s OAuth metadata and registers itself with dynamic client registration, so the admin enters no client ID or secret. It works with any server URL an admin configures, as long as the server advertises a registration_endpoint. BOW registers once per connection and requests the scopes the server asks for at each sign-in. Presets use this mode when the provider supports it.
  • OAuth (admin-registered app) — for servers without DCR, or when your organization must own the client. The admin registers an OAuth app with the provider once, for the whole organization, and enters its client ID, secret, and endpoints. Users still sign in individually; the admin’s app is not a shared identity.
If DCR fails with does not advertise a registration_endpoint, the server does not support it — switch to OAuth (admin-registered app).
When testing an OAuth-based server before anyone has signed in, a 401 or 403 from the server counts as healthy — it proves the endpoint is reachable and challenging for credentials.

​
OAuth MCP integration

OAuth connects an MCP server without turning a shared secret into a shared identity. Each user authorizes the connection with their own account, and tool calls use that user’s token and the policies configured in Bag of words. The setup flow is:
  1. Add an MCP preset or enter a custom server URL and transport.
  2. Choose Sign in (auto-register / DCR) when the server supports dynamic registration, or OAuth (admin-registered app) and enter your app’s client ID, secret, and endpoints.
  3. Save and discover the server’s tools.
  4. Each user selects Sign in and completes the provider’s authorization flow.
  5. Review tool policies and attach the connection to the appropriate agent.
  6. The agent can call approved tools as the signed-in user; expired tokens are refreshed through the configured token endpoint.
Use dynamic registration whenever the server supports it, so you never create or maintain a client ID. Use an admin-registered OAuth app for a custom server where you control the authorization URL, token URL, client credentials, scopes, audience, and token-endpoint authentication method.
OAuth authenticates the caller; it does not bypass governance. Connection access, agent scope, tool policy, admin denies, and the MCP server’s own authorization rules still apply to every call.

​
Tool discovery

When you save the connection, Bag of words asks the server for its tools and stores each one with its name, description, and input schema. Re-run discovery any time from the connection’s tools view — after the server ships new tools, for example. Discovery never silently empties your tool list: if a refresh returns nothing (usually a transient outage), the existing tools and their policies are left untouched. Servers that expose MCP resources as well as tools get those surfaced too, so the agent can list and read them.

​
Tool policies

Every tool carries a policy that decides what happens when the agent wants to call it: Read-only tools generally default to allow. Anything that writes should be ask or deny. Policies are resolved in three layers, most specific first:
  1. The user’s own preference for that tool
  2. The agent-level override — the same tool can be allow on one data source and ask on another
  3. The connection default set by the admin
with one hard rule: an admin deny is absolute and cannot be relaxed by an agent override or a user preference. Users can only make their own experience stricter than the admin’s setting, never looser. Admins set connection defaults and agent overrides; any user with access can set their own preference for a tool they use.
MCP tools can be turned off organization-wide with a single setting under Settings → AI. When disabled, no MCP tool runs regardless of policies.

​
Per-user identity

Many internal MCP servers need to know who is asking — to apply their own permissions or to write audit records. Bag of words can inject the caller’s identity into every call, as headers or as tool arguments, without the model being able to influence it. See User context forwarding.

​
Adding a connection

  1. Open Agents, choose New → Connection (or Connect data), and pick an MCP preset or MCP Server.
  2. Enter the server_url and choose the transport.
  3. Choose an authentication mode and fill in its fields.
  4. Test, then save. Tools are discovered on save.
  5. Review the discovered tools and set each one’s policy before exposing the connection to users.
  6. Attach the connection to an agent so people can use it in chat.