Staffbase MCP Server

Understand how the Staffbase MCP Server lets AI agents read Staffbase content through the Model Context Protocol.

Employee App
Staffbase Intranet

The Staffbase MCP Server allows to read content from the Staffbase platform on behalf of a signed-in user. It implements the Model Context Protocol, an open standard that defines how an AI agent discovers and calls tools on a remote server.

An MCP-compatible agent connects to a single endpoint on your Staffbase platform domain, authenticates through OAuth, and receives a defined set of tools it can call.

The MCP Server complements the Staffbase API. The API remains the primary interface for integrations that programmatically read and manage Staffbase data. The MCP Server exposes a narrower, task-oriented subset of that data in a format designed for AI agents. This allows you to connect supported to Staffbase without building a separate integration for each agent.

The MCP Server is served from your platform domain at: https://{{yourapp}}.{{host}}/mcp.

The server consists of two main layers:

  • Protocol layer: Interfaces with AI agents. It handles tool discovery and tool calls over HTTPS. Each request must include an access token.
  • OAuth compatibility layer: Handles user authentication. It runs the browser-based login flow and validates the agent against the managed OAuth client named MCP, which defines the redirect URIs and browser origins allowed to connect.

Behind the protocol layer, each MCP tool uses the Staffbase APIs required to retrieve the requested information. The tools are the only way an agent can access Staffbase content; agents do not select or call Staffbase API endpoints directly.

Permissions are evaluated for every tool call. A tool returns only content that the authenticated user is already authorized to access in the Staffbase platform. As a result, the same query can return different results for different users based on their permissions.

The agent drives authorization in four phases. The agent needs to know only the MCP endpoint URL in advance. It discovers the authorization server and obtains the credentials it needs during the flow.

  • Discovery: The agent initially calls the MCP endpoint without an access token. The server responds with 401 Unauthorized and a WWW-Authenticate header pointing to the server’s metadata. The agent uses this metadata to discover the authorization server and continue the authorization flow.
  • Registration: The agent uses Dynamic Client Registration to register and obtain the credentials required for the connection. The redirect URIs and browser origins configured for the MCP OAuth client determine which agents are allowed to complete this step.
  • Login and consent: The agent does not authenticate as a service account. Instead, the user provides their identity through the browser-based login flow. After the user signs in and grants the required consent, the agent exchanges the authorization code for an access token.
  • Tool calls: The agent uses the access token to request the available tools and call them. Each tool call is authorized in the context of the signed-in user.

The token represents the user who signed in, not the agent, and not a service account. That is what makes results permission-scoped. Because the flow runs in a browser and the agent stores no client secret, the MCP client is registered as an SPA client.