Skip to main content
Hosted MCP is available to all Bronto accounts. MCP access is governed by the same login controls used across the rest of the product.

​
Overview

Bronto now supports a hosted MCP experience. Instead of running an MCP server yourself, you can enable MCP access directly in the Bronto UI, sign in with your existing Bronto login method (OAuth, SSO, or Google Social), and connect supported MCP clients to Bronto’s hosted MCP endpoint. This makes the setup feel much closer to connecting any other SaaS integration than bootstrapping local developer infrastructure. User and access management for MCP is identical to any other access to your Bronto account.

​
Enabling MCP in the UI

The first step is to enable MCP access inside Bronto. Hosted MCP access is intentionally tied to the same login controls used by the rest of the product — if a login method is not enabled for MCP, authorization requests using that method will be rejected. This gives admins a clear, centralised way to control:
  • Whether MCP access is allowed at all
  • Which login methods are valid for MCP
  • Which users can successfully complete the MCP OAuth flow
1

Open Authentication Settings

Navigate to Settings → Authentication in the Bronto UI. You will see the MCP login method listed as an available option on this page.
2

Enable the MCP Login Method

Toggle the MCP login method to Enabled.
3

Configure the MCP Card

Click Configure on the MCP card to open the configuration panel.
4

Review SSO Providers and Login Methods

Review the available SSO providers and any other supported login methods that should be permitted for MCP access.
5

Save the Configuration

Click Save to apply the configuration. MCP access is now enabled for the selected login methods.

​
Connecting an MCP Client

Once MCP is enabled in the UI, client setup is significantly simpler than the local-server approach. Instead of pointing the client at a locally running process, you configure it to use Bronto’s hosted MCP endpoint. The client then performs the standard OAuth flow.
1

Add the Bronto MCP server

Open a terminal and run the following command to register the Bronto MCP server and launch Claude CLI:
claude mcp add --transport http bronto https://mcp.eu.bronto.io/mcp && claude
2

Open the MCP menu

Once Claude CLI is open, enter the following command:
/mcp
3

Select Bronto and authenticate

Select Bronto from the list and press Enter to open the MCP authentication flow.
──────────────────────────────────────
  Manage MCP servers
  1 servers     Local MCPs

  ❯ bronto · △ needs authentication

​
Authentication Flow

After adding the connection, you must authenticate with Bronto. The flow is the same regardless of which client you use.
1

Browser opens automatically

Your MCP client opens the Bronto MCP authorization URL in a browser window.
2

Sign in with Bronto

Sign in using an allowed Bronto login method — OAuth, SSO, or Google Social, whichever has been enabled for MCP by your admin.
3

Approve requested scopes

Review and approve the requested permission scopes.
4

Token issued

Bronto redirects back to your MCP client and issues an access token. Your client is now connected.
The authentication flow mirrors the standard OAuth 2.0 pattern. Once connected, token refresh is handled automatically by the client.

​
API Key Access

The hosted MCP endpoint also supports API key-based access for clients that can send custom headers directly. This is useful when an MCP client only supports local stdio servers but you want to connect it to a remote hosted endpoint.

​
Using mcp-remote

mcp-remote is a bridge utility that translates stdio-based MCP clients to remote HTTP endpoints with support for custom auth headers. 
{
  "mcpServers": {
    "bronto-eu": {
      "command": "npx",
      "args": [
        "mcp-remote",
        "https://mcp.eu.bronto.io/mcp",
        "--header",
        "X-BRONTO-API-KEY:${AUTH_TOKEN}"
      ],
      "env": {
        "AUTH_TOKEN": "<your-api-key>"
      }
    }
  }
}
Never hardcode your API key directly in configuration files that may be committed to version control. Use environment variables as shown above.

​
Direct Header Attachment

For clients that support streamable-http transport and custom headers natively, such as Kiro, you can attach the API key header directly without mcp-remote: 
{
  "mcpServers": {
    "bronto-us": {
      "type": "streamable-http",
      "url": "https://mcp.us.bronto.io/mcp",
      "headers": {
        "Accept": "application/json, text/event-stream",
        "X-BRONTO-API-KEY": "<your-api-key>"
      },
      "autoApprove": [],
      "disabled": false
    }
  }
}

​
Endpoint Reference

RegionHosted MCP Endpoint URL
UShttps://mcp.us.bronto.io/mcp
EUhttps://mcp.eu.bronto.io/mcp
Use the endpoint that matches the data region where your Bronto account is hosted. Connecting to the wrong region will result in an authentication error.

​
Capabilities

The Bronto hosted MCP server exposes seven tools to connected clients, covering the full workflow from schema discovery through to raw log search and aggregated analytics. A typical workflow moves through these tools in sequence: use get_datasets to identify the right data source, get_keys to understand its schema, get_key_values to build precise filters, then search_logs for raw event investigation or timeseries for aggregated trend analysis.

get_all_datasets_keys

Returns the available field names for every dataset you can access. Use this to quickly understand the schema across all datasets before running searches or aggregations.

get_datasets

Lists all available datasets, including each dataset’s name, collection, unique dataset ID, and tags. Use this when you need to discover what data sources are available.

get_datasets_by_name

Finds datasets by exact dataset name and collection name. Use this when you know the dataset you want and need its metadata or dataset ID.

get_key_values

Returns the available values for a specific field in a specific dataset. Use this to discover common field values and build more precise filters.

get_keys

Returns the available field names for a specific dataset. Use this to inspect a dataset’s schema before querying it.

search_logs

Searches raw log events in one or more datasets over a time range. Supports dataset IDs or a dataset selection expression, optional filters, result limits, and sorting. Best for investigations and event-level troubleshooting.

timeseries

Computes aggregated metrics and time-series trends from log data. Supports COUNT, SUM, AVG, percentile calculations, grouping, time bucketing, and comparison windows. Best for summaries and trend analysis.

​
Example Prompts

The best hosted MCP workflows start with dataset discovery, narrow the search space, then ask focused operational questions. CDN logs are a strong example: high-volume, operationally important, and often the first place teams look when users report latency, origin instability, or unusual traffic. The following prompts demonstrate useful fault-finding and analysis workflows using Claude and Opus 4.6.

​
Example 1 — Find the right CDN datasets

Which datasets contain production CDN logs for our edge or delivery layer?
Teams often have multiple CDN-related datasets with non-obvious names, causing delays while users search for the right sources or query more than they need to. The hosted MCP server identifies likely datasets first, then surfaces log IDs, collections, and tags needed to scope all later queries correctly. The result should immediately surface the production CDN and edge-layer datasets in your account — confirming which datasets are actually carrying production CDN traffic before any deeper analysis begins.

​
Example 2 — Look for elevated error responses

In the last 30 minutes, look through our CDN logs for elevated 5xx responses
and group them by host, path, and status code.
What to look for in CDN logs:
  • Spikes in 5xx status codes
  • Concentration on a single hostname, service, or path
  • Whether failures are broad or isolated
  • Whether only a subset of POPs or edge nodes are affected
This is one of the fastest ways to distinguish between a widespread origin issue, a bad deploy affecting one route, a customer-specific path problem, or low-impact isolated errors.

​
Example 3 — Investigate latency regressions

Compare CDN response-time metrics for the last hour against the previous hour
and identify the hosts or paths with the largest regression.
What to look for in CDN logs:
  • Increases in origin time or total response time
  • Regressions concentrated on one host or endpoint
  • Whether the issue appears at the edge or upstream
  • Whether the timing aligns with a deploy or traffic change
This is especially useful when users report the site feeling slower but there is no obvious outage. The workflow makes it straightforward to compare time windows, identify the worst regressions, and narrow quickly to the hosts and paths driving the slowdown.

​
Example 4 — Look for cache effectiveness problems

Search our CDN logs for cache-related fields and show whether cache miss rates
increased in the last 24 hours.
What to look for in CDN logs:
  • Cache hit vs miss patterns
  • Sudden increases in origin fetches
  • Path prefixes with poor cache efficiency
  • Changes following a release or cache-key adjustment
This type of question is often hard to answer quickly without knowing the exact field names in the dataset. MCP discovers the relevant keys first, then narrows the search — making it easier to see which paths are driving origin load and whether the issue is broad or concentrated.

​
Example 5 — Investigate abusive or unusual traffic

Use CDN logs from the last 15 minutes to find unusual request-volume spikes
by client IP, user agent, host, and path.
What to look for in CDN logs:
  • Sudden traffic concentration from a small set of IPs
  • Repeated hits to a small set of endpoints
  • Suspicious user-agent patterns
  • Abnormal request mix compared with baseline traffic
This helps identify bot traffic, scraper spikes, attack reconnaissance, or accidental client retry storms. The workflow makes it easier to isolate sudden spikes, see which IPs or paths dominate the burst, and decide quickly whether you are looking at bots, scrapers, or retry storms.

​
Frequently Asked Questions

Which login methods are supported for MCP? Hosted MCP supports the same login methods available across the rest of Bronto: OAuth, SSO, and Google Social. Your admin controls which are enabled for MCP access via the Authentication settings page. Can I restrict which users can connect via MCP? Yes. Because MCP access is tied to the same login controls as the rest of the product, disabling a login method for MCP prevents users who rely on that method from completing the MCP OAuth flow, giving admins fine-grained control over who can access Bronto via MCP. Do I need to run anything locally? No. With the hosted MCP endpoint there is no local server to install or manage. The only exception is if you are using mcp-remote as a bridge for stdio-only clients — but even then, mcp-remote is a lightweight npx invocation rather than a persistent service you need to maintain. Which header carries the API key? Pass the API key in the X-BRONTO-API-KEY request header. What is the difference between the US and EU endpoints? The endpoints correspond to the data region where your Bronto account is hosted. Use mcp.us.bronto.io for US accounts and mcp.eu.bronto.io for EU accounts. Connecting to the wrong region will result in an authentication error.