Introducing the QuantumLayers MCP Server: Bring Your Own Agent to Your Data

How QuantumLayers exposes the same tools that power QL-Agent over the Model Context Protocol, so any MCP-compatible client, from Claude Desktop and Claude Code to Cursor or an agent you built yourself, can list datasets, run analyses, build charts, and manage reports in your account, and how to decide when that is a better fit than reaching for QL-Agent directly.

The Analysis Is Ready. Until Now, Your Own Agent Could Not Reach It.

QL-Agent already lets you talk to your data in plain language from inside QuantumLayers. It lists your datasets, generates insights, builds charts, and sets up reports, all from a chat box in the dashboard. That works well as long as the work stays inside QuantumLayers. The trouble starts when the analysis is one step in a larger process that lives somewhere else: an agent your team built, a workflow in Cursor, an assistant in Claude Desktop that already touches your other systems.

Until now, getting QuantumLayers into one of those workflows meant writing code against the REST API: handling authentication, learning each endpoint, parsing responses, and updating your integration every time the platform added a capability. The QuantumLayers MCP Server removes that layer of glue. It presents the platform’s capabilities through a standard protocol that AI clients already know how to speak, so pointing your own agent at your QuantumLayers account becomes a matter of configuration rather than development.

What MCP Is, in One Paragraph

The Model Context Protocol is an open standard for connecting AI assistants to external tools and data. Before it existed, every tool that wanted to be usable by an AI client had to invent its own plugin format, and every client had to support each one separately. MCP replaces that with a single contract: a server publishes the tools it offers, and any client that speaks the protocol can discover and call them. It was introduced by Anthropic and has since been adopted across a range of AI clients and platforms. QuantumLayers now ships an MCP server of its own, which means QuantumLayers can act as a tool inside any client that supports the standard.

What the QuantumLayers MCP Server Exposes

The server offers the same tool set that QL-Agent uses internally. Anything QL-Agent can do on your behalf, a connected client can do too:

  • Datasets: list datasets, view details and settings, change visibility, delete, merge, and create datasets from a CSV URL, SQL database, REST API, SFTP server, Google Sheet, or Kaggle dataset
  • Charts: get recommended charts for a dataset, save a chart, list saved charts, and delete a saved chart
  • Analysis: generate AI insights, pull a statistical summary, a correlation matrix, or an ANOVA analysis, and generate a SQL query from a plain-language description
  • Scheduled Reports: list, create, view, update, delete, and manually run a report
  • Monitors: list, create, view, update, delete, and manually run a monitor

One property matters more than the length of that list: every tool call runs with your account’s own permissions and subscription limits, exactly as if you had performed the action from the dashboard or from QL-Agent. Connecting a client does not grant it any power you do not already have, and it does not bypass the plan limits that apply to your account.

One Endpoint, Standard JSON-RPC

The server speaks JSON-RPC 2.0 over a single HTTP endpoint:

POST https://quantumlayers.com/wp-json/ql/v1/mcp

Any MCP client that supports remote HTTP servers can be pointed at that URL. In practice you rarely touch the protocol directly: most clients handle the initialize and tools/list handshake automatically once you enter the endpoint, so you do not need to construct JSON-RPC requests by hand. From there, the two things you choose are how the client authenticates and what you ask it to do.

Connecting with OAuth (Recommended)

QuantumLayers runs a built-in OAuth 2.1 authorization server, with PKCE and open dynamic client registration, so clients that support remote MCP or connectors can authenticate without you ever copying a token. This is the easiest and most secure option, and it works with clients such as Claude.ai Connectors, Claude Desktop, and Claude Code:

  1. In your MCP client, choose “Add a connector” (or the equivalent) and paste in the endpoint URL above
  2. The client discovers the authorization and token endpoints automatically and redirects you to QuantumLayers to sign in, if you are not already signed in
  3. A consent screen lists what the client is requesting access to; review it and click Allow
  4. You are redirected back to your client, which now holds a short-lived access token, refreshed automatically, scoped to your account

You can click Deny on the consent screen to reject a connection request, and you can revoke access later the same way you would revoke any API token, since the OAuth server issues tokens tied to your account.

Connecting with an API Token

If your client does not support OAuth discovery, or you are configuring a server manually through a JSON file, you can authenticate with a regular API token instead. Create one from the API Tokens page, then send it as a bearer token on every request:

Authorization: Bearer <your-api-token>

For a client configured through a JSON file, such as Claude Desktop’s or Claude Code’s MCP server config, that typically looks like this:

{
  "mcpServers": {
    "quantumlayers": {
      "url": "https://your-quantumlayers-site.com/wp-json/ql/v1/mcp",
      "headers": {
        "Authorization": "Bearer <your-api-token>"
      }
    }
  }
}

The exact config format varies by client, so check your client’s documentation for how it accepts a remote server URL and custom headers. If you ever need to cut off access, revoke the token from the API Tokens page and the connection stops working immediately.

Why Bring Your Own Agent

The reason to connect your own agent instead of using QL-Agent comes down to orchestration. QL-Agent is powerful within QuantumLayers, but it only sees QuantumLayers. Your own agent can treat QuantumLayers as one tool among many, and that opens up work that a single-product assistant cannot do:

  • Cross-system workflows: an agent can generate insights in QuantumLayers, then act on them elsewhere in the same run, opening a ticket, posting a summary to Slack, or writing a figure back into another system, without a human relaying the result between tools
  • Multiple MCP servers at once: because MCP is a shared standard, your agent can hold QuantumLayers alongside other MCP servers and combine them, using your analytics in the same conversation as your code, your documents, or your infrastructure
  • Your choice of model and client: you decide which model reasons over the tools and which interface your team works in, rather than using the model and surface built into QuantumLayers
  • Embedding in existing pipelines: the analysis can be triggered by your own events and schedules and folded into software you already run, instead of living in a separate dashboard

In short, you bring your own agent when QuantumLayers is a component of something larger, and you want that something to run without you in the loop passing results from one window to another.

What You Give Up, and When QL-Agent Is the Better Choice

Bringing your own agent moves responsibility onto you. With QL-Agent, QuantumLayers handles the model, the prompts that know how to drive its own tools, the error handling, and the hosting, and it stays current as the platform adds features. Run your own agent and those become your job: you choose and pay for the model, you write the instructions that decide when and how to call each tool, you handle failures and retries, and you secure the client that now holds access to your account. An agent is also only as good as the tools you wire into it and the judgment you give it, so a poorly instructed agent can call the wrong tool or misread a result in ways the in-product experience is tuned to avoid.

That points to a clean division. Use QL-Agent when the task begins and ends inside QuantumLayers: you want fast, reliable analysis with nothing to set up, and you are working in the product anyway. Bring your own agent through the MCP server when QuantumLayers is one stop in a workflow that spans several systems, when you need a specific model or client, or when the work has to run automatically as part of software you already operate. Many teams will use both, QL-Agent for hands-on exploration and a connected agent for the automated paths, and nothing about connecting one changes how the other behaves.

A Concrete Setup: Pointing Claude Desktop at QuantumLayers

To make this concrete, consider connecting Claude Desktop over OAuth. You add a connector, paste in the endpoint URL, sign in to QuantumLayers when the consent screen appears, and click Allow. The client completes the handshake and lists the available tools on its own. No token is copied and no JSON is edited.

From that point you can ask in plain language, for example: “List my QuantumLayers datasets, generate insights on the sales one, and save the three most useful charts.” The agent calls the dataset-listing tool, then the insight-generation tool on the dataset you named, then the chart tools to save what it selected, and reports back with the results. Each of those calls is the same action QL-Agent would take internally and runs under your account’s permissions and limits. The difference is that the request came from your client, where the next step could just as easily be handing the summary to another tool you have connected.

Security and Access

An MCP connection, whether through OAuth or an API token, has the same access to your data as you do, so the guidance is simple: only connect clients and tools you trust. Prefer OAuth over a manually pasted token when your client supports it, because access tokens are short-lived and refreshed automatically, which means there is no long-lived secret sitting in a config file waiting to leak. If you do use an API token, follow the same token best practices as any other integration: one token per client, an expiry that matches how long you expect to use it, and immediate revocation if it is ever exposed. Because every action is scoped to your account, revoking the token or the OAuth grant is enough to end a client’s access completely.

Conclusion

The MCP server turns QuantumLayers from a place you visit into a capability your agents can call. QL-Agent remains the fastest path for analysis inside the product, with nothing to configure and prompts already tuned to the platform. The MCP server is for when you want that same power, the same datasets, insights, charts, reports, and monitors, reachable from whatever AI client or custom agent your team already works in.

Point a client at the endpoint, authenticate with OAuth, and your account’s full tool set is available to your own agent in minutes, running under your permissions and your limits. The analysis no longer has to stay where it was generated. It can go wherever your work happens.

This post is part of the QuantumLayers blog series on building analytics workflows that stay current. For a programmatic alternative to MCP that predates it, see Connecting QuantumLayers to Any REST API, and for deeper integration patterns see the Developer Guide. To understand the tools your agent will be calling, start with QL-Agent. Connect your first client at www.quantumlayers.com.