Skip to main content
Applies to:
  • Plan -
  • Deployment -

​
Summary

Issue: sql_query against project_logs returns 0 rows for a SaaS org, and resolve_object returns Missing read access for the same projects, even though logs are visible in the UI and the MCP OAuth token works for other orgs. Cause: The Braintrust MCP endpoint is data-plane-scoped — a self-hosted MCP endpoint can resolve control-plane metadata (projects, experiments) across orgs, but can only read log data from its own Brainstore instance; SaaS org log data lives in Braintrust’s public Brainstore. Resolution: Add a second MCP server connection pointing at the SaaS data plane endpoint and complete a fresh OAuth flow against it.

​
Resolution steps

​
Step 1: Identify which MCP endpoint you are connected to

If your current MCP connection points at a self-hosted data plane URL (e.g., https://d8k4dyx7j51un.cloudfront.net/mcp) rather than https://api.braintrust.dev/mcp, log queries for SaaS org projects will always return empty — this is a routing issue, not a permissions issue. Symptoms that confirm this:
  • sql_query on project_logs returns { "data": [] } with no time filter and a direct object_ids value
  • resolve_object returns Missing read access for a SaaS org project
  • The same token returns rows for projects in your self-hosted org

​
Step 2: Add a second MCP server connection for the SaaS data plane

Add a new MCP server entry in your client pointing at the Braintrust SaaS endpoint:
RegionEndpoint
UShttps://api.braintrust.dev/mcp
EUhttps://api-eu.braintrust.dev/mcp
Example using the Claude CLI: 
claude mcp add --transport http braintrust-saas \
  https://api.braintrust.dev/mcp
Your client will run a fresh OAuth flow against this endpoint. Do not remove your existing self-hosted MCP connection — keep both running side by side.

​
Step 3: Use the correct connection per org

After adding the second connection, tools from each MCP server are namespaced separately in your client (e.g., braintrust-saas:sql_query vs your self-hosted connection’s tools). Use the SaaS connection when querying projects in Braintrust-hosted orgs, and the self-hosted connection for projects in your self-hosted org.

​
Step 4: Verify access

Run the following query against the SaaS connection to confirm rows are returned: 
{
  "object_type": "project_logs",
  "object_ids": ["<your-saas-project-id>"],
  "select": "id, created",
  "order_by": "created DESC",
  "limit": 5
}
The response should now contain data with rows matching what is visible in the UI.

​
Notes

  • This issue is not caused by user permissions. Being an org admin does not grant cross-data-plane read access through the wrong MCP endpoint.
  • Control-plane metadata (project names, experiment lists) is shared, which is why list operations succeed even on the wrong endpoint — only log data reads are affected.
  • No changes to your self-hosted deployment are required.