Skip to main content

MCP Server Guide

This guide covers the Model Context Protocol (MCP) server in Simba Intelligence, which enables AI assistants and other MCP-compatible clients to securely query your data sources using standardized tooling and OAuth2 PKCE authentication.

Overview

The MCP server exposes Simba Intelligence capabilities as MCP tools that can be consumed by AI assistants (such as Claude Desktop, Cursor, or custom agents) through the Model Context Protocol standard. It runs as a separate deployment alongside the main application.

Key Capabilities

πŸ”§ MCP Tools
  • Query data sources using natural language
  • List available data sources and their metadata
  • Retrieve field-level statistics for data exploration
  • Get AI-generated follow-up question suggestions
πŸ” OAuth2 PKCE Authentication
  • Secure authorization code flow with Proof Key for Code Exchange (PKCE)
  • Scoped access tokens tied to user identity and tenant context
  • Automatic token refresh and rotation
  • Full multi-tenancy support

Architecture

The MCP server runs as a dedicated deployment with two containers:
  • Nginx sidecar (port 8000) β€” Handles path rewriting and exposes OAuth2 well-known endpoints. This is the externally accessible port.
  • MCP server (port 8001) β€” FastMCP application running on Gunicorn with Uvicorn workers. Only accessible internally within the pod.

Available MCP Tools

Once connected, MCP clients can use the following tools:

get_data

Query a data source using natural language.

get_data_sources

List available data sources accessible to the authenticated user.

get_suggested_questions

Get AI-generated follow-up questions based on available data.

get_field_statistics

Retrieve field-level statistics such as distinct values, min/max ranges, and data distributions.

OAuth2 PKCE Authentication Flow

The MCP server uses OAuth2 with PKCE (S256) for secure client authentication. This flow is designed for public clients that cannot securely store a client secret.

Flow Overview

OAuth2 Scopes

Token Lifetimes

Discovery Endpoints

MCP clients discover the OAuth2 configuration through well-known endpoints:
  • /.well-known/oauth-authorization-server β€” Returns the authorization server metadata (issuer, endpoints, supported grant types)
  • /.well-known/oauth-protected-resource β€” Returns protected resource metadata

Security Features

  • PKCE S256 β€” Code challenge verification prevents authorization code interception
  • Redirect URI validation β€” Blocks dangerous schemes (javascript:, data:, etc.)
  • Token rotation β€” Refresh tokens are rotated on each use; old tokens are invalidated
  • Session binding β€” User identity (user_id, tenant_id) is embedded in all tokens
  • Revocation β€” Both access and refresh tokens can be revoked, which cascades to related tokens

Deployment Configuration

Helm Values

The MCP server is configured through the Helm chart under the simba.intelligence.mcp section:

Environment Variables

⚠️ Important: MCP_BASE_URL must match the externally accessible URL where the MCP server is reachable. This URL is used in OAuth2 redirect URIs and discovery responses. Incorrect values will cause authentication failures.

Network Requirements

  • The MCP Kubernetes Service exposes port 8000 (Nginx proxy) within the cluster
  • Ingress or load balancer should route MCP traffic to the service on port 8000
  • The MCP server requires connectivity to:
    • PostgreSQL β€” For OAuth token storage
    • Redis β€” For caching
    • Composer/Discovery β€” For data source queries

Connecting MCP Clients

Client Configuration

MCP clients connect using the server’s base URL with the /mcp path. The exact configuration depends on the client application. Refer to your MCP client’s documentation for the correct configuration format.

Connection Flow

  1. The MCP client discovers the OAuth2 server via /.well-known/oauth-authorization-server
  2. The client registers itself at /mcp/register
  3. The user is redirected to the Simba Intelligence login page to authenticate
  4. After authentication, the user approves the requested scopes on the consent screen
  5. The client receives an authorization code and exchanges it for access/refresh tokens
  6. The client can now invoke MCP tools with the access token
πŸ’‘ Pro Tip: The user must have an active Simba Intelligence session (authenticated via the web interface) before the MCP OAuth2 flow can complete. Ensure the user has logged in at least once.

Multi-Tenancy

The MCP server fully supports multi-tenancy:
  • User identity and tenant context are embedded in all OAuth tokens
  • All MCP tool invocations are scoped to the authenticated user’s tenant
  • Data source access respects the same role-based permissions as the web interface
  • Users in multiple tenants are authenticated in the context of their current active tenant

Troubleshooting

Common Issues

OAuth2 redirect failures:
  • Verify MCP_BASE_URL matches the externally accessible URL
  • Ensure the Nginx sidecar is running and proxying correctly
  • Check that the ingress/load balancer is routing to port 8000
Authentication errors:
  • Confirm the user has an active Simba Intelligence session
  • Check that Composer/Discovery is accessible from the MCP pod
  • Review MCP server logs for token exchange errors
Tool execution failures:
  • Verify the user has appropriate role permissions for the requested operation
  • Check connectivity to Composer, PostgreSQL, and Redis
  • Review logs with UVICORN_LOG_LEVEL=debug for detailed request tracing

Viewing Logs