Connect
Add this remote MCP server to your client:
https://api.brigg.app/mcpThe client starts Brigg's OAuth authorization flow. Sign in, choose the workspace and identity mode, review permissions, and approve the connection. Personal access follows your live permissions. Workspace access uses an administrator-approved grant, with optional member delegation.
Manage and revoke connections in Brigg Settings. Tokens belong in the client credential store, never in an agent prompt.
Let the client discover its tools
After connecting, the MCP server supplies the tools, descriptions and argument schemas the client needs. Your agent can discover and inspect available operations before using them. The catalog follows the connection's approved permissions.
The HTTP reference documents operations available to workspace API keys. Operations that require a member’s identity are marked as requiring delegation in the HTTP reference. MCP discovers the same operation contracts through the protocol.
Personal or workspace access
Use personal access to work with your own permitted meeting content and personal records. Use workspace access for shared reporting, CRM synchronization, and an agent that serves an ongoing business process independently of one employee.
Workspace access does not imply access to a colleague's private records. Sensitive operations may require a person to approve a proposed action.
Existing MCP clients
The launched MCP tools, their schemas, and existing personal OAuth grants remain supported. Existing clients do not need to rename tools or reconnect to retain their current access. To use the new operation tools, explicitly request the brigg.operations OAuth scope and approve the concrete operation permissions. Existing grants do not automatically gain this access.
Use the HTTP quickstart when you are building a server integration with an API key.
Delegating member access
An administrator may approve selected members or all current and future members for a shared connection. Use list_delegation_members to obtain authorized member IDs. Pass act_as alongside name, arguments and request_id on invoke_operation, or alongside the filters on list_operations and read_operation. It belongs outside the operation arguments.
The selected member's live permissions and the connection's approved grant both apply, including access to private records. Without act_as, shared connections continue to use workspace access. Personal connections cannot select another member. The existing personal tools keep their current contracts.