> ## Documentation Index > Fetch the complete documentation index at: https://docs.bronto.io/llms.txt > Use this file to discover all available pages before exploring further. # Hosted MCP Server > Connect Claude and other MCP clients to Bronto's hosted MCP endpoint to query log data, no local server required, using your existing Bronto login. 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 Navigate to **Settings → Authentication** in the Bronto UI. You will see the MCP login method listed as an available option on this page. Toggle the MCP login method to **Enabled**. Click **Configure** on the MCP card to open the configuration panel. Review the available SSO providers and any other supported login methods that should be permitted for MCP access. 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. Open a terminal and run the following command to register the Bronto MCP server and launch Claude CLI: ```bash theme={"dark"} claude mcp add --transport http bronto https://mcp.eu.bronto.io/mcp && claude ``` Once Claude CLI is open, enter the following command: ``` /mcp ``` Select **Bronto** from the list and press **Enter** to open the MCP authentication flow. ``` ────────────────────────────────────── Manage MCP servers 1 servers Local MCPs ❯ bronto · △ needs authentication ``` In Claude Desktop or Claude Web, go to **Settings → Connectors** and select **Add custom connector**. 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` | 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. 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. Review and approve the requested permission scopes. 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](https://www.npmjs.com/package/mcp-remote) is a bridge utility that translates stdio-based MCP clients to remote HTTP endpoints with support for custom auth headers. ```json theme={"dark"} { "mcpServers": { "bronto-eu": { "command": "npx", "args": [ "mcp-remote", "https://mcp.eu.bronto.io/mcp", "--header", "X-BRONTO-API-KEY:${AUTH_TOKEN}" ], "env": { "AUTH_TOKEN": "" } } } } ``` 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](https://kiro.dev/), you can attach the API key header directly without mcp-remote: ```json theme={"dark"} { "mcpServers": { "bronto-us": { "type": "streamable-http", "url": "https://mcp.us.bronto.io/mcp", "headers": { "Accept": "application/json, text/event-stream", "X-BRONTO-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 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. 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. 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. 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. Returns the available values for a specific field in a specific dataset. Use this to discover common field values and build more precise filters. Returns the available field names for a specific dataset. Use this to inspect a dataset's schema before querying it. 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. 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.