Authored by Ciaran McGauran
An earlier post, Bronto MCP Server, introduced Bronto's local MCP server and showed how AI clients can use log data to answer operational questions. That post focused on the developer-managed local setup: run the server yourself, connect it to Bronto with an API key, and let clients like Claude Code query logs through MCP tools.
We now support a hosted MCP experience. Instead of running the MCP server yourself, you enable MCP access in the Bronto UI, sign in with your existing Bronto login method (OAuth, SSO, or Google Social), and connect supported MCP clients directly to Bronto's hosted MCP endpoint.
The result is a much simpler setup for teams that want the benefits of MCP without managing a local server process or distributing API keys to individual developers.
Why a Hosted MCP Server?
The local MCP server is still a good fit for individual developers — it's flexible, easy to inspect, and quick to wire up locally. But a hosted model solves a different set of problems:
- No local server repos to clone, install, run, or keep up to date
- No user-managed API keys for routine MCP access
- Sign-in uses the same login methods already managed in Bronto
- Access can be governed centrally in the Bronto UI
- Teams can standardize on one managed MCP endpoint
- Enables Bronto in environments and platforms that only support remote MCP (e.g. AWS DevOps Agent)
In short: the local version is better for local experimentation. The hosted version is better when you want Bronto to manage authentication and access, and when administrators need clear control over who can connect.
What Changes Compared to the Local Version?
At a tool level, the experience is familiar. Clients still get access to Bronto datasets, keys, values, log search, and metrics. What changes is how access is granted:
- Administrators enable MCP login and control which sign-in methods are allowed
- Users sign in through Bronto's normal authentication flow
- MCP clients complete a browser-based OAuth flow
- Bronto issues and validates the MCP access tokens
This keeps the user experience close to a normal SaaS sign-in flow, while still exposing Bronto data through MCP.
Setting Up the Hosted MCP Server
To enable MCP for your Bronto account and connect an MCP client, follow the instructions at docs.bronto.io/ai-features/hosted-mcp.
What Can You Ask It? Five CDN Log Examples
CDN logs are a particularly good example for the hosted MCP workflow: high volume, operationally important, and often the first place teams look when users report latency, origin instability, or unusual traffic. The examples below use Claude Opus 4.6.
Example 1: Find the Right CDN Datasets
Prompt:
Which datasets contain production CDN logs for our edge or delivery layer?
Teams often have multiple CDN-related datasets with non-obvious names. Before asking for regressions or cache behavior, you first want to know which datasets are actually carrying the production traffic.
The hosted MCP flow surfaced two production CDN and edge-layer datasets immediately:
Example 2: Look for Elevated Error Responses
Prompt:
In the last 30 minutes, look through our CDN logs for elevated 5xx responses and group them by host, path, and status code.
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, and noisy but low-impact isolated errors.
Example 3: Investigate Latency Regressions
Prompt:
Compare CDN response-time metrics for the last hour against the previous hour and identify the hosts or paths with the largest regression.
Especially useful when users report "the site feels slower" but there's no obvious outage. 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
Prompt:
Search our CDN logs for cache-related fields and show whether cache miss rates increased in the last 24 hours.
This kind of question is often hard to answer quickly if you don't already know the exact field names in the dataset. MCP helps by discovering the relevant keys first, then narrowing the search. Identify where cache misses are increasing, see which paths are driving origin load, and determine whether the issue is broad or concentrated.
Example 5: Investigate Unusual Traffic
Prompt:
Use CDN logs from the last 15 minutes to find unusual request-volume spikes by client IP, user agent, host, and path.
Helps with bot traffic, scraper spikes, attack reconnaissance, and accidental client retry storms. Isolate sudden spikes, see which IPs or paths dominate, and decide quickly whether you're looking at bots, scrapers, or retry storms.
Closing Thoughts
The original Bronto MCP Server post showed that log data is a strong MCP use case. The hosted version makes that workflow much easier to operationalize.
Instead of asking users to install and run infrastructure locally, Bronto now provides the MCP endpoint directly — with sign-in and access managed through the product itself, just like the UI or direct API.
CDN logs are exactly the kind of data where this shines: large volumes, fast-moving operational questions, and investigations that benefit from moving fluidly from dataset discovery to raw search to concrete explanations.
If the first phase of MCP was proving that AI clients can be useful on top of log data, the hosted phase is about making that capability practical for more teams.
Top comments (0)