ClickHouse Agents and Remote MCP: Governing Agentic Analytics on ClickHouse Cloud

In 2026 ClickHouse moved agentic analytics into its managed service. ClickHouse Agents, announced at Open House 2026 and now in public beta, lets ClickHouse Cloud users build and run AI agents that query their data through conversation. Alongside it, a remote MCP server lets external agents and coding tools reach Cloud services through the Model Context Protocol.

This article explains what each capability does, how access is controlled, and what an engineering and governance team should decide before switching either on. It covers the ClickHouse Cloud offerings only. Self-managed open-source ClickHouse has a different, smaller set of options, described near the end.

What was announced, and its status

The Open House 2026 Day 1 post grouped several agent-related items under ClickHouse Cloud: ClickHouse Agents, MCP-as-a-Service, Query API Endpoints with MCP tooling support, and a ClickHouse CLI built for agent workflows. Status labels differ by item, and several items carry none in the post.

The ClickHouse Agents launch post, dated 9 June 2026, gives the clearest picture of the main product:

• It describes ClickHouse Agents as a fully managed agentic analytics service in ClickHouse Cloud, powered by Claude.
• It states the service is available to all ClickHouse Cloud customers in public beta, through the SQL console.
• It is built on LibreChat, which ClickHouse acquired in November 2025.
• Claude Sonnet and Haiku models are wired in as the default models for every Cloud customer.
• An Agent API, richer in-chat visualisation and an evaluation feedback loop using Langfuse are described as planned, not delivered.

The ClickHouse Agents documentation labels the feature as beta and states that behaviour and capabilities may change before general availability. Treat it accordingly: suitable for evaluation and bounded internal use, with production decisions revisited when the status changes. The launch post does not publish pricing or post-beta plan terms, so confirm those in your contract.

Two different surfaces: agents inside Cloud, and MCP into Cloud

The two capabilities point in opposite directions, and they need separate decisions.

	ClickHouse Agents	Remote MCP server
Where the agent runs	Inside ClickHouse Cloud, as a managed service	In your own tool or agent framework, outside ClickHouse Cloud
Who builds the agent	Users with the right role, in a no-code Agent Builder	Your engineers, in any MCP-compatible client
Model	Claude models as the default, per the launch post	Whatever model your client uses
Data operations	Depends on the tools and MCP servers attached to the agent	Read-only tools, per the documentation
Status on the research date	Public beta	The documentation page carries no beta label

A team can adopt one without the other. Many will start with the remote MCP server for engineers, because it fits existing tooling, and evaluate ClickHouse Agents separately for analysts and business users.

How ClickHouse Agents works

The documentation describes an agent that interprets intent, plans steps, calls the tools you have configured and returns results, so users do not write SQL or orchestration logic. The Agent Builder lists the building blocks:

• a sandboxed code interpreter, web search, image generation and vision inputs;
• third-party MCP servers attached to an agent;
• skills, described as reusable instruction packs;
• subagents for delegating work to child agents;
• model parameters per agent.

The quickstart shows the flow: open ClickHouse agents from a Cloud service, create an agent with a name, instructions and model, toggle the capabilities it needs, and start a conversation. If the Create agent option is missing, an organisation admin must grant agent creation in Admin Settings. Agents can then be shared with teammates or published to an internal marketplace.

The launch post states that agent access is governed by your Cloud role-based access control, and lists SSO, encrypted message storage and governed data access as part of the managed runtime. The pages we reviewed do not state, in detail, whose database credentials an agent’s queries run under. That is a question to answer in your own test environment before wider rollout.

Access control and sharing

The sharing and access page describes a layered model. Roles decide which features a user can use at all. The two default roles are User, who can run agents and chat, and Admin, who adds organisation-level controls. Building agents, creating skills and sharing depend on per-feature toggles in the role, and admins can create custom roles.

Each agent, prompt and skill then has its own access list with three levels:

• Viewer can use the resource but not change it.
• Editor can change instructions, tools or model.
• Owner can also delete the resource or change its sharing.

Anything not explicitly shared stays private to its creator. Organisation-wide sharing is controlled by a role toggle and is what makes an agent discoverable in the marketplace. Admins can switch organisation-wide features such as memory, web search, the code interpreter and the marketplace on or off.

The same page notes three operational points worth writing into your runbook:

• Editing a shared agent changes it for everyone who uses it; copy it before experimenting.
• Deleting an agent removes access for everyone it was shared with.
• Revoking a user’s role does not delete the resources they created, so transfer ownership during offboarding.

Attaching MCP servers to an agent

An agent becomes more capable, and more exposed, as tools are attached. The MCP servers page states that attaching a server gives the agent access to whatever capabilities that server exposes. You choose which of the server’s tools the agent may use, and each tool call is logged in the conversation.

Key constraints from that page:

• Agents use Streamable HTTP, and the server must be reachable over HTTP(S) from ClickHouse Cloud. Internal systems therefore need a deliberate network path, not an accidental one.
• Authentication can use static headers such as bearer tokens, OAuth 2.0, or per-user credentials filled from the calling user’s profile.
• User-provided credentials are stored encrypted and scoped to the user who entered them.
• A single agent run can reference at most 50 distinct MCP server targets and 100 expanded tool configurations; larger designs should be split with subagents.

Per-user credentials are usually the safer default for shared agents, because each person then acts with their own rights in the downstream system. A static token shared through a popular agent effectively grants every user that token’s permissions.

The remote MCP server for external agents

The remote MCP documentation describes a managed endpoint that external agents and tools can use to list databases and tables, inspect schemas and run scoped SELECT queries. Points that matter for governance:

• All exposed tools are read-only. The page states that no tool can modify data, alter service configuration or perform a destructive operation.
• It must be enabled per service, from the service’s Connect menu, and enabling it requires the control-plane:service:manage-mcp permission.
• Interactive clients authenticate with OAuth 2.0 using Cloud credentials. Headless use relies on a ClickHouse Cloud API key, and the page recommends a dedicated, least-privilege key held in a secret manager.
• Beyond query and schema tools, the 13 tools include organisation, service, backup, ClickPipes and billing information.

Read-only does not mean low-risk. An agent that can run SELECT can read anything its identity can read, including billing and backup metadata through the management tools. Scope the identity, not just the tool list.

Decisions to make before enabling either

• Which Cloud services, if any, may have the remote MCP server enabled, and who holds the permission to enable it?
• Which identities do agents use? Prefer per-user OAuth for people and dedicated, expiring, least-privilege API keys for automation.
• Which roles may build agents, create skills and share organisation-wide? Start narrow and widen with evidence.
• Which organisation-wide features stay off at first: code interpreter, web search, memory or the marketplace?
• Which external MCP servers may be attached, and what network path exposes them to ClickHouse Cloud?
• Have legal and security teams reviewed how conversations, memory and query results are handled by the managed service and its model provider? The pages we reviewed do not describe this in detail, so ask for it in writing.
• How will you evaluate answer quality? Generated SQL can be valid and still answer the wrong question. Keep a set of known questions with checked answers and rerun it after changes to agents, models or schemas.
• Who owns each shared agent, and what happens when that person leaves?

Capabilities, limits and commercial terms for these features depend on your ClickHouse Cloud service, plan and contract, and beta features can change. Confirm them for your account before relying on them.

Where self-managed ClickHouse fits

ClickHouse Agents and the remote MCP endpoint are ClickHouse Cloud features. The remote MCP page recommends the open-source mcp-clickhouse server for self-hosted instances. It runs locally over stdio, works with any ClickHouse instance, and exposes three tools: run_select_query, list_databases and list_tables. Teams on ClickHouse OSS can still build agent workflows, but they assemble and operate the agent runtime, model access, identity and logging themselves. That is a valid route when data residency or platform policy requires it, and it is a larger engineering commitment.

For agent tracing and evaluation, many teams pair either route with an observability layer such as Langfuse. Our enterprise AI AgentOps work covers that wider operating model.

How Bassirah can help

ClickHouse is a Bassirah strategic technology partner. We help teams design the identity, role and network model for ClickHouse Agents and the remote MCP server, run a bounded pilot with an evaluation set, and document the decisions above before wider rollout. See our ClickHouse partner page. Feature availability, support and commercial terms are confirmed with ClickHouse for each engagement.