> ## Documentation Index
> Fetch the complete documentation index at: https://docs.braintrust.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# MCP returns empty logs for SaaS org from self-hosted endpoint

> [!NOTE]
>
> **Applies to:**
>
> * Plan - Any
> * Deployment - Self-hosted
> *
> * Use case - Users with both a self-hosted Braintrust org and a SaaS (Braintrust-hosted) org who find that MCP sql\_query returns 0 rows for SaaS org project\_logs when connected via their self-hosted MCP endpoint

## 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:

| Region | Endpoint |
| - | - |
| US | `https://api.braintrust.dev/mcp` |
| EU | `https://api-eu.braintrust.dev/mcp` |

Example using the Claude CLI:

```bash theme={"theme":{"light":"github-light","dark":"github-dark-dimmed"}}
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:

```json theme={"theme":{"light":"github-light","dark":"github-dark-dimmed"}}
{
  "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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.