Model Context Protocol サーバーで、Debezium（Kafka Connect REST API 経由）を操作します。MCP 対応クライアント（Claude Desktop、Claude Code など）から、変更データキャプチャコネクタの監視と管理（ステータス、設定、再起動、ライフサイクル）を、すべてフラグで制御できるようにします。
デフォルトで安全: 読み取り専用で起動し、コネクタの許可リストにスコープを限定でき、重要なコネクタを変更から保護し、コネクタ設定内の認証情報をマスクし、削除は明示的なオプトインの背後にゲートします。
監視 — ワーカー/クラスタ情報、コネクタ一覧、プラグイン、コネクタごとの設定、ステータス（失敗したタスクのトレースを含む）、トピック。
管理 — 作成/更新、一時停止/再開、コネクタまたは単一タスクの再起動。
ライフサイクル — コネクタの削除（管理者）。
アクセスモード — read-only → read-write → admin の階層で、モードが上位のツールを公開することはありません。
認証情報のマスク — database.password などのシークレット形式の設定値は、結果を返す前に ***REDACTED*** に置き換えられます。
セキュリティフラグ — コネクタ許可リスト、保護コネクタ、削除ゲート、ドライラン、JSON 監査ログ（下記参照）。
Related MCP server: Kafka MCP Server
懸念事項 | フラグ | デフォルト | 効果 |
サーバーは何ができるか? |
|
|
|
どのコネクタが対象か? |
| (すべて) | 設定すると、他のコネクタへの操作は拒否されます。 |
どのコネクタが永久に読み取り専用か? |
| (なし) | 検査は可能ですが、一時停止/再設定/削除はできません。 |
削除できるか? |
|
|
|
Connect に触れずにプレビュー |
|
| 書き込み/管理ツールは検証と意図のログを出力してから返します。 |
監査証跡 |
|
| ガードされた操作ごとに JSON 行を stderr に出力します。 |
認証情報のマスク | (常時オン) | — | シークレット形式の設定値は返却前にマスクされます。 |
読み取り (read-only+): cluster_info、list_connectors、list_connector_plugins、get_connector、get_connector_config、get_connector_status、get_connector_topics
書き込み (read-write+): create_connector、update_connector_config、pause_connector、resume_connector、restart_connector、restart_task
管理者 (admin): delete_connector（DEBEZIUM_ALLOW_DELETE が必要）
npm に @dockndevai/mcp-debezium として公開されています。クローンやビルドは不要です。MCP クライアントが npx でオンデマンドに実行します。read-only モードで開始してください。すべての変数は .env.example を、クライアント別の完全ガイドは docs/CLIENTS.md を参照してください。
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 — 同じブロックを claude_desktop_config.json、.cursor/mcp.json、または ~/.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 — ~/.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) — .vscode/mcp.json 内:
{
"servers": {
"debezium": {
"type": "stdio",
"command": "npx",
"args": [
"-y",
"@dockndevai/mcp-debezium"
],
"env": {
"CONNECT_URL": "http://localhost:8083",
"DEBEZIUM_MODE": "read-only"
}
}
}
}「FAILED のコネクタはどれですか？ その理由は？」
「pg-orders の失敗したタスクを再起動して。」（read-write が必要）
「mysql-inventory の設定を表示して。」（認証情報はマスクされて返ります）
上記の公開パッケージを推奨します。クローンから実行する場合:
npm install
npm run build
node dist/index.js # with the environment variables setnpm run dev
npm test # security policy + config redaction
npm run typecheckこのサーバーは、公式 MCP レジストリ用の server.json と、npm 所有権検証用の mcpName を同梱しています。npm への公開と MCP レジストリ、Smithery、Glama、Cursor、PulseMCP への掲載については、PUBLISHING.md を参照してください。
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
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.
