Gluesync Core Hub MCP server: pipelines, SQL, and ops from your AI client

Gluesync Core Hub includes an embedded Model Context Protocol (MCP) server. It runs inside the Core Hub JVM (corehub-mcp), mounts next to the existing REST and WebSocket routes, and exposes pipeline management, debugging, observability, connections, and SQL work as tools an AI agent can call — with the caller’s own token and the same RBAC, license, and audit path as the Web UI.

No sidecar. No hosted proxy. No elevated service account inside the module. If a user cannot delete a pipeline in the UI, the matching MCP tool will not let them either.

MCP transports are available in Core Hub builds from 2.2.10.x (present from at least v2.2.10.1; tip through v2.2.10.16). 2.2.11 is the public docs and feature highlight, with hardening that includes the Connections tools (built-in catalog 55). This article is the how-it-works walkthrough of the embedded server documented at docs.molo17.com — Core Hub MCP server.

What it is (and what it is not)

The server is an in-process MCP endpoint on Core Hub. MCP clients such as Claude Code, Claude Desktop, MCP Inspector, or any other MCP-compatible agent talk to Core Hub and present a Bearer token. Core Hub validates the token, then each tool call is forwarded over loopback REST into the same API the Control Plane uses.

That is different from:

• Bootstrapper / Automator MCP — a separate local client path (stdio or Automator SSE, historically ~48 tools) for configuration workflows. Useful for local stdio clients; not the embedded Hub server.
• Ask CoreHub — a portal-side client experience. This article is about the embedded MCP server inside Core Hub, not the Ask UI.

Transports

Two standard MCP transports are mounted on Core Hub:

• Server-Sent Events at /mcp — inside Core Hub’s authenticated routing block, so JWT or API token is checked before the stream opens.
• Streamable HTTP at /mcp/http — the single-endpoint transport preferred by newer clients, protected by Core Hub’s global JWT filter.

A typical streamable-HTTP base URL looks like:

https://<corehub-host>/mcp/http

Send:

Authorization: Bearer <corehub-jwt-or-api-token>

Any Core Hub session token or Personal API Token (gsp_…) works. Once connected, every tool the caller’s role permits becomes available.

Security model

The module holds no service account and no elevated privileges of its own. It extracts the bearer token from the incoming MCP request and forwards it on loopback REST. RBAC, license limits, and audit logging therefore stay exactly where they already are — inside Core Hub.

Operational controls:

• GLUESYNC_MCP_READ_ONLY=true hides every tool marked WRITE (start/stop sync, delete pipeline, upsert entities, enter maintenance mode, and similar).
• An allow-list can further restrict which tool names are exposed.
• Put Core Hub behind TLS in production; MCP traffic shares the same origin and port as the rest of the Core Hub API.

Configuration

Environment variables read by Core Hub at startup — no separate config file:

Variable	Default	Effect
GLUESYNC_MCP_ENABLED	true	Master switch. false skips mounting /mcp* entirely.
GLUESYNC_MCP_BASE_PATH	/mcp	SSE at this path; streamable HTTP at ${basePath}/http.
GLUESYNC_MCP_READ_ONLY	false	When true, hide WRITE tools from the catalog.
GLUESYNC_MCP_DYNAMIC_DB_TOOLS	true	Per-session discovery of Query Studio tools as namespaced db_… MCP tools.

55 built-in tools

Coverage spans the Control Plane surface operators already use. Built-in catalog is 55, including Connections:

• Pipelines (7) — list, get, status, snapshot status, delete, reset checkpoint, entities status
• Agents (9) — list/get, node info, schema/table/column discovery, assign/unassign
• Entities (4) — get, upsert, delete
• Sync commands (8) — start/stop/redo, one-time snapshot, group sync, maintenance mode
• Notifications (4) — list, get, count, mark read
• Metrics (6) — pipeline/agent/entity/global plus Prometheus text
• Mapping functions (2) — list and read UDF source
• Query Studio (4) — list SQL-capable agents, execute SQL, explain, table DDL
• Groups & global config (5) — groups, config keys, release channel, log level
• License / version / export (3) — license info, Core Hub version, pipeline YAML export
• Connections (3) — list_connections, get_connection, get_connection_usages

Total: 55. Mutating tools are classified WRITE and drop out first under read-only mode. Architecture and security detail: Core Hub MCP server.

Dynamic database tools via Query Studio

When GLUESYNC_MCP_DYNAMIC_DB_TOOLS is on, opening a session triggers discovery against Query Studio:

1. List SQL-capable agents visible to the caller’s token.
2. Fetch each agent’s registered Query Studio MCP tools.
3. Register them as namespaced tools (db_…), descriptions prefixed with the agent display name.
4. Invoke through the same bearer token into the Query Studio invoke path.

That is how an external MCP client reaches the databases behind Core Hub in the same session — still scoped by Query Studio permissions. Query Forge remains the federated JDBC path for BI clients; MCP is the agent tool path.

Example agent loop

User: which pipelines are running?
Agent → list_pipelines()
Agent → get_pipeline_status(pipeline_id="abc-123")

User: reset the checkpoint on pipeline abc-123 and start a full snapshot
Agent → reset_pipeline_checkpoint(pipeline_id="abc-123")
Agent → start_sync(pipeline_id="abc-123", with_snapshot=true)

Who this is for

Data and integration engineers who already live in pipelines and checkpoints, and platform teams wiring AI agents into ops without inventing a second control plane. Pair it with Gluesync’s broader AI / RAG surface when you are building agent workflows around governed data paths — see AI & RAG solutions.

Get started

Point an MCP client at https://<corehub-host>/mcp/http with a Bearer session token or gsp_… Personal API Token. Read the full module page for architecture, env vars, and the tool catalog: Core Hub MCP server. Module index: Gluesync Modules.

Questions on a concrete Hub build — I am around.