This server provides read-only monitoring and inspection of a Debezium/Kafka Connect cluster via MCP tools.
Get cluster info: worker version, commit, Kafka cluster id
List connector names (filtered by allowlist)
List connector plugin classes installed on the worker
Get full connector info (config + tasks) with credentials redacted
Get a connector's configuration map with secrets redacted
Get connector and task states (RUNNING/PAUSED/FAILED), worker assignment, failure traces
Get the set of topics a connector has read from or written to
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-debezium Which connectors are FAILED, and why?"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol server for Debezium (via the Kafka Connect REST API). It lets an MCP-capable client (Claude Desktop, Claude Code, etc.) monitor and manage change-data-capture connectors — status, config, restarts, lifecycle — with behaviour controlled entirely by flags.
Safe by default: it starts read-only, can be scoped to an allowlist of connectors, protects critical connectors from mutation, redacts credentials in connector configs, and gates deletion behind an explicit opt-in.
Monitoring — worker/cluster info, connector list, plugins, per-connector config, status (with failed-task traces), and topics.
Management — create/update, pause/resume, restart connector or a single task.
Lifecycle — delete connectors (admin).
Access modes — read-only → read-write → admin, layered so a mode never exposes tools above its level.
Credential redaction — database.password and other secret-shaped config values are replaced with ***REDACTED*** before results are returned.
Security flags — connector allowlist, protected connectors, delete gating, dry-run, and JSON audit logging (see below).
Related MCP server: Kafka MCP Server
Concern | Flag | Default | Effect |
What can the server do? |
|
|
|
Which connectors are in scope? |
| (all) | When set, operations on other connectors are refused. |
Which connectors are read-only forever? |
| (none) | Inspectable but never paused/reconfigured/deleted. |
Can it delete? |
|
|
|
Preview without touching Connect |
|
| Write/admin tools validate + log intent, then return. |
Audit trail |
|
| Emits a JSON line to stderr per guarded operation. |
Interactive confirmation | (automatic) | — | Destructive & high-impact actions prompt the human to approve via MCP elicitation before running; clients without elicitation fall back to the |
Credential redaction | (always on) | — | Secret-shaped config values are redacted before return. |
Read (read-only+): cluster_info, list_connectors, list_connector_plugins, get_connector, get_connector_config, get_connector_status, get_connector_topics
Write (read-write+): create_connector, update_connector_config, pause_connector, resume_connector, restart_connector, restart_task
Admin (admin): delete_connector (needs DEBEZIUM_ALLOW_DELETE)
Published on npm as @dockndevai/mcp-debezium. No clone or build needed — your MCP client runs it on demand with npx. Start in read-only mode; see .env.example for every variable and docs/CLIENTS.md for the full per-client guide.
Claude Code (CLI)
claude mcp add debezium -e CONNECT_URL="http://localhost:8083" -e DEBEZIUM_MODE="read-only" -- npx -y @dockndevai/mcp-debeziumClaude Desktop · Cursor · Windsurf — same block in claude_desktop_config.json, .cursor/mcp.json, or ~/.codeium/windsurf/mcp_config.json:
{
"mcpServers": {
"debezium": {
"command": "npx",
"args": [
"-y",
"@dockndevai/mcp-debezium"
],
"env": {
"CONNECT_URL": "http://localhost:8083",
"DEBEZIUM_MODE": "read-only"
}
}
}
}OpenAI Codex CLI — in ~/.codex/config.toml:
[mcp_servers.debezium]
command = "npx"
args = ["-y", "@dockndevai/mcp-debezium"]
env = { CONNECT_URL = "http://localhost:8083", DEBEZIUM_MODE = "read-only" }VS Code (GitHub Copilot, Agent mode) — in .vscode/mcp.json:
{
"servers": {
"debezium": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@dockndevai/mcp-debezium"
],
"env": {
"CONNECT_URL": "http://localhost:8083",
"DEBEZIUM_MODE": "read-only"
}
}
}
}"Which connectors are FAILED, and why?"
"Restart the failed task on pg-orders." (needs read-write)
"Show the config for mysql-inventory." (credentials come back redacted)
Prefer the published package above. To run from a clone:
npm install
npm run build
node dist/index.js # with the environment variables setnpm run dev
npm test # security policy + config redaction
npm run typecheckThis server ships a server.json for the official MCP registry and an mcpName for npm ownership validation. See PUBLISHING.md for publishing to npm and listing on the MCP registry, Smithery, Glama, Cursor, and PulseMCP.
MIT
Kafka Connect worker version, commit, and Kafka cluster id.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already indicate a safe, read-only, idempotent operation, so the description's extra value is disclosing the exact return fields: worker version, commit, and Kafka cluster id. This gives the agent concrete expectations about what data will be available without an output schema. It adds useful context without contradicting the annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that lists the three key pieces of information returned. Every word is relevant, and there is no repetition of the title or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, read-only tool with strong annotations, the description is complete: it states the resource, the exact fields returned, and is clearly differentiated from sibling tools that focus on connectors. No additional information is needed for an agent to invoke it correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description has no parameter semantics to explain. With no parameters required and schema coverage at 100%, the baseline of 4 applies because there is nothing additional the description could meaningfully clarify.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly identifies the resource (Kafka Connect cluster) and the specific fields returned (worker version, commit, Kafka cluster id), which distinguishes it from the connector-specific sibling tools even without an explicit verb like 'get' or 'list'. The title reinforces the resource but the description itself makes the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not state when to use this tool versus the sibling tools. It implies usage by stating what information it returns, but it never names alternatives, exclusions, or conditions under which a different tool should be chosen. For a cluster-level info tool this is a minor gap, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Full connector info (config + tasks). Secret config values are redacted.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Connector name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint/idempotentHint/destructiveHint=false/openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context beyond the annotations by disclosing that secret config values are redacted in the response, which prevents an agent from assuming secrets are retrievable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short, front-loaded sentences with no filler; the payload scope comes first and the redaction caveat second, both of which earn their place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description takes on some responsibility for describing returns, and it does name the two returned sections (config + tasks) plus the redaction caveat. It could say more about what a connector name resolves to or failure behavior, but it is adequate for a simple read tool whose annotations cover the rest.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is a single parameter (name) with 100% schema description coverage, so the schema already carries its meaning. The description adds nothing about name format, resolution, or lookup behavior, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description gives a specific verb+resource (get a connector) and clarifies the scope of the payload (config + tasks), which meaningfully differentiates it from the narrower get_connector_config and get_connector_status siblings. It stops short of naming those siblings explicitly, so an agent must infer the distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is only implied: the phrase 'Full connector info (config + tasks)' suggests this is the broad fetch to use when you want everything in one call, versus the partial getters among the siblings. There is no explicit when-to-use, when-not-to-use, or named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The connector's configuration map. Secret values are redacted.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Connector name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld, and non-destructive. The description adds a genuinely new behavioral fact not present in the structured data: secret values in the returned map are redacted. It does not mention behavior for unknown connector names, but the redaction disclosure is meaningful added context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler, and the core return value is front-loaded before the redaction caveat. Nothing needs trimming.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with full schema coverage and rich annotations, the description covers what is returned (a config map) and the important caveat (redacted secrets). Absent an output schema, more detail on the map's shape could help, but the essentials are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and there is a single 'name' parameter, so the schema already carries the semantics. The description adds nothing about the parameter beyond what the schema provides, which is the baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the specific resource returned (the connector's configuration map) and implicitly a get operation, which separates it from get_connector_status, get_connector_topics, and list_connectors. It does not explicitly distinguish itself from the sibling get_connector, but the resource is clear enough for selection.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use guidance, no prerequisites, and no named alternative. The agent must infer that this is called to inspect a named connector's settings rather than get_connector (metadata) or get_connector_status (health).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Connector and task states (RUNNING / PAUSED / FAILED), worker assignment, and failure traces.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Connector name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful content beyond that: the enumerable state values (RUNNING / PAUSED / FAILED) and the fact that worker assignment and failure traces are included. It does not, however, say what happens for an unknown connector name or whether the status is point-in-time.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single dense sentence fragment with no filler; the returned-state enumeration is front-loaded. It is terse and readable, though the fragment form means it never states the action, so it is not maximally effective structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, so the description is doing double duty as a return-value summary, and it covers the main fields an agent would want. Combined with rich annotations, this is nearly sufficient for a single-parameter read tool; only the error case for an unknown connector is unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with a single 'name' parameter documented as 'Connector name'. The description adds nothing about the parameter (e.g. exact-match semantics, case sensitivity). Baseline 3 is appropriate when the schema fully carries the parameter burden.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description is a noun-phrase inventory of returned data (connector/task states, worker assignment, failure traces) rather than a verb+resource statement of what the tool does. The name and title carry the action ('Get connector status'), and the description does distinguish the content from siblings like get_connector_config or get_connector_topics, but it never explicitly says this retrieves the current status of a named connector.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no statement of when to call this versus get_connector, get_connector_config, or list_connectors -- all of which smell like overlapping entry points. Usage is only implied by the tool name. No prerequisites or exclusions are given.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The set of topics a connector has read from or written to.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Connector name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so the safety profile is covered. The description adds a scoping detail—that the topics are those the connector has read from or written to—which gives some context beyond the schema and annotations. However, it does not disclose auth requirements, pagination, or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. Every part earns its place by defining the returned data set.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, one-parameter tool with rich annotations and a fully documented schema, the description adequately explains the return value since no output schema exists. It stops short of describing the exact format or edge cases, but those are minor given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the single 'name' parameter fully documented in the schema. The description adds no additional meaning about the parameter, so the baseline of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description specifies the resource (topics) and scope (a connector's read/written topics), making it clear what data is returned. It lacks an explicit action verb like 'Retrieve' and does not distinguish itself from siblings such as get_connector_config or get_connector_status, but the noun phrase is specific enough for an agent to identify the tool's purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, nor does it state any prerequisites or exclusions. It only implies usage from the return value, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the connector plugin classes installed on the worker (incl. Debezium connectors).
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds the valuable behavioral detail that Debezium connectors are included, which is not captured by annotations. This is a meaningful addition without redundancy, so the description complements the structured metadata well.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly-phrased sentence that front-loads the core action and scope. There is zero fluff or unnecessary detail, making it highly efficient for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only tool with no output schema, the description provides all essential context: what it lists (plugin classes) and its scope (including Debezium). There are no complex inputs, side effects, or return-value expectations that need elaboration, so the description is complete for an agent to invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters and the schema is empty, so the description need not explain any input semantics. Per the baseline for 0 parameters, a score of 4 is appropriate since there is nothing for the description to clarify or compensate for in this dimension.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('connector plugin classes installed on the worker'), and explicitly notes Debezium connectors are included. This clearly distinguishes it from sibling like 'list_connectors' which likely lists actual connectors rather than plugin classes. The purpose is unambiguous and self-contained.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explicitly state when to use this tool versus alternatives, nor does it mention exclusions or conditions. Usage is implied by the tool name and description, but there is no guidance such as 'use list_connectors for active connectors instead'. Given the simple nature and clear name, this is adequate but not exemplary.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List connector names. Connectors outside the allowlist are filtered out.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnlyHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds one useful behavioral detail: connectors outside the allowlist are filtered out. However, it does not explain return envelopes, ordering, pagination, or how the allowlist is determined, so the added value beyond annotations is modest.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The primary action is stated first, and the key filtering behavior is added as a second concise sentence. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter read-only list operation, the description is complete: it states what is returned (connector names) and the main behavior (allowlist filtering). Sibling tools cover the detailed per-connector operations, so the agent has enough context to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the schema requires no elaboration. The description correctly focuses on behavior rather than inputs, and there is nothing missing for an agent to call the tool correctly.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'List connector names.' It also distinguishes itself from sibling tools like list_connector_plugins and get_connector by emphasizing that it returns names only and applies allowlist filtering. This makes the tool's purpose unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as get_connector, get_connector_status, or list_connector_plugins. It implies selection by virtue of the name and short description, but no exclusions or alternative routing are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.2.2get_connector1 field changedInput schema / additionalPropertiesRemoved value: -falseget_connector_config1 field changedInput schema / additionalPropertiesRemoved value: -falseget_connector_status1 field changedInput schema / additionalPropertiesRemoved value: -falseget_connector_topics1 field changedInput schema / additionalPropertiesRemoved value: -falsev0.1.0cluster_infoget_connectorget_connector_configget_connector_statusget_connector_topicslist_connector_pluginslist_connectorsScored across 7 tools
Most tools target distinct aspects of Kafka Connect/Debezium introspection. get_connector overlaps somewhat with get_connector_config and get_connector_status because it returns full connector info including config and tasks, but the descriptions clarify the specialized scopes.
The naming is mostly consistent snake_case with clear verb_noun patterns such as get_connector_config and list_connectors. cluster_info is a minor deviation because it lacks a verb, but it remains readable and predictable.
Seven tools is well-scoped for a connector introspection server. Each tool covers a distinct read-only concern, from connector lists and configs to status, topics, plugins, and cluster info.
The read-only introspection surface is largely complete: connectors, config, status, topics, plugins, and cluster details are covered. Mutation or lifecycle operations like create, update, restart, pause, and delete are absent, but they may be outside this server's apparent monitoring scope.
Streamkap CLI & MCP server - manage CDC pipelines, sources, destinations, and transforms
GibsonAI MCP server: manage your databases with natural language
One MCP URL for all your connectors — scoped writes, enforced constraints, and a full audit trail.
Interact with your Google Cloud Datastream resources using natural language commands.
