Hosted MCP Server - Bronto Docs

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

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.

Enable the MCP Login Method

Toggle the MCP login method to Enabled.

Configure the MCP Card

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

Review SSO Providers and Login Methods

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

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.

Claude CLI
Claude Desktop

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

Open the MCP menu

Once Claude CLI is open, enter the following command:

/mcp

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

Add a custom connector

In Claude Desktop or Claude Web, go to Settings → Connectors and select Add custom connector.

Enter the name and MCP URL

Enter a name for the connector, then provide the hosted MCP endpoint URL for the region where your Bronto account is located:

Region	MCP Endpoint URL
US	`https://mcp.us.bronto.io/mcp`
EU	`https://mcp.eu.bronto.io/mcp`

Connect and authenticate

Select the Connect button beside the Bronto MCP entry in the connectors list to open the authentication flow.

Authentication Flow

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

Browser opens automatically

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

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

Approve requested scopes

Review and approve the requested permission scopes.

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

Region	Hosted MCP Endpoint URL
US	`https://mcp.us.bronto.io/mcp`
EU	`https://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 a set of tools to connected clients, covering the full workflow: discover schema, search and aggregate log data, save and re-run queries, manage alerting monitors, and audit coverage and usage. A typical investigation moves through these 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. From there you can preserve a query as a saved search, turn a finding into a monitor, and check where you have coverage or blind spots.

Discovery & search

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.

Saved searches

get_saved_searches

Lists and reads saved searches, with optional filtering by text, tag, or field. Use this to discover existing saved views before creating a new one.

create_saved_search

Creates one or more saved searches. As well as the query, it can set how the saved view renders — list, timeseries, table, top-list, pie, treemap, or a geomap of values by country. Supports batch creation.

run_saved_search

Executes a saved search by id and returns its results, identical to running the query directly. Optionally run it over a different time window.

Monitors & coverage

search_monitors

Finds existing monitors and, for a given monitor, its recent trigger and recovery history. Useful for retrospectives and avoiding duplicate alerts.

create_monitor

Creates monitors (always muted for review before they can alert). Supports threshold and no-data alerting (fire when a log goes quiet) and an investigation prompt that Bronto runs automatically when the monitor fires.

validate_monitors

Health-checks your existing monitors by re-running each backing query, so you can spot alarms that have silently broken or stopped receiving data.

get_coverage

Reports, per dataset, whether it is monitored, searched, and still ingesting — surfacing blind spots such as a live dataset with no alert watching it.

Usage & health

get_error_summary

Returns org-wide error and warning totals with a per-dataset breakdown. Precomputed, so it costs no search quota to run.

get_usage

Reports per-dataset ingestion and search usage against your monthly limits, and whether each dataset is actively ingesting or dormant.

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.

​Overview

​Enabling MCP in the UI

​Connecting an MCP Client

​Authentication Flow

​API Key Access

​Using mcp-remote

​Direct Header Attachment

​Endpoint Reference

​Capabilities

​Discovery & search

get_all_datasets_keys

get_datasets

get_datasets_by_name

get_key_values

get_keys

search_logs

timeseries

​Saved searches

get_saved_searches

create_saved_search

run_saved_search

​Monitors & coverage

search_monitors

create_monitor

validate_monitors

get_coverage

​Usage & health

get_error_summary

get_usage

​Example Prompts

​Example 1 — Find the right CDN datasets

​Example 2 — Look for elevated error responses

​Example 3 — Investigate latency regressions

​Example 4 — Look for cache effectiveness problems

​Example 5 — Investigate abusive or unusual traffic

​Frequently Asked Questions

Overview

Enabling MCP in the UI

Connecting an MCP Client

Authentication Flow

API Key Access

Using mcp-remote

Direct Header Attachment

Endpoint Reference

Capabilities

Discovery & search

Saved searches

Monitors & coverage

Usage & health

Example Prompts

Example 1 — Find the right CDN datasets

Example 2 — Look for elevated error responses

Example 3 — Investigate latency regressions

Example 4 — Look for cache effectiveness problems

Example 5 — Investigate abusive or unusual traffic

Frequently Asked Questions