[General][Java SDK (Component)] Dubbo-MCP: Model Context Protocol (MCP) server for Apache Dubbo (Connecting Cursor, Claude Code & AI Coding Agents)

[b1n9bna]

Pre-check

• I am sure that all the content I provide is in English.

Apache Dubbo Component

Java SDK (apache/dubbo)

Details

Note: 中文说明附在下方 / Chinese description follows below.

Background & Motivation

Hi Dubbo community,

When debugging business logic or developing microservices in modern AI coding environments (such as Cursor, Claude Code, Codex, or Windsurf), developers frequently need to inspect and verify the actual runtime responses of internal Dubbo RPC services.

Traditionally, this requires either:

1. Adding client API JAR dependencies to a local test project and writing manual unit tests; or
2. Switching back and forth between the IDE and the web-based Dubbo Admin console, manually searching for services and nesting complex DTO JSON parameters.

Both approaches disrupt developer flow. To address this, we developed Dubbo-MCP, a standard Model Context Protocol (MCP) server based on Dubbo's native Generic Invocation (GenericService).

Key Features & Implementation

1. Zero-Dependency Generic Invocation: Implemented in pure Java 8 using Dubbo 2.7.x / 3.x GenericService. No need to import or compile target interface API JARs locally.
2. Dual-Channel Discovery:
   • Dev / Test: Directly connects to ZooKeeper / registry, inspecting /dubbo/metadata for parameter DTO structures and method signatures, with sub-millisecond ReferenceConfig caching.
   • Staging / Prod: Safely routes through Dubbo Admin HTTP gateways with SSO session support and strict read-only regex safety guards.
3. Lightweight Footprint: Shipped as a standalone Fat-JAR (~22MB), with ~25MB resident memory (RSS) and <100ms cold start.
4. Token-Efficient: Optimized two-stage discovery saves up to 98.6% tokens compared to browser-automation agents (~570 tokens per inspection session).

Open Source & Discussion

The project is fully open source under the Apache 2.0 license:
👉 GitHub: https://github.com/b1n9bna/dubbo-mcp

We hope this provides a helpful reference for tooling integration in the AI coding era. We welcome any feedback, suggestions, or contributions from the Dubbo community!

---

项目背景与初衷（中文说明）

各位社区老师与开发者好：

在日常使用 Cursor、Claude Code、Codex 等 AI 编程助手排查业务逻辑或编写微服务业务代码时，我们经常需要在上下文中验证内网 Dubbo RPC 接口的实际返回。

过去常见的调试方式通常是：

1. 在测试工程中引入目标接口的 API 依赖 JAR 包，手动写单元测试类调试；
2. 或者切换到浏览器打开 Dubbo Admin，手动搜索接口、逐层组装复杂的嵌套 DTO JSON 并提交测试。

两种方式都比较繁琐且容易打断编码心流。因此，我们基于 Dubbo 原生的**泛化调用（GenericService）**开发了 Dubbo-MCP，作为一个标准的 Model Context Protocol (MCP) 服务端。

核心特性与技术实现：

1. 免依赖泛化调用：纯 Java 8 原生实现，基于 Dubbo 2.7.x / 3.x 的 GenericService，本地无需预先安装或引入任何业务接口 API 的依赖 JAR 包；
2. 双通道服务发现：
   • 开发/测试环境：直连 ZooKeeper / 注册中心，从 /dubbo/metadata 反查复杂 DTO 字段结构与方法签名，支持 sub-millisecond 级别的 ReferenceConfig 缓存；
   • 生产/预发环境：安全路由至 Dubbo Admin 统一网关，支持 SSO 会话凭据与只读方法白名单正则（防止误触发写操作）；
3. 轻量与资源占用：单个 Fat-JAR（~22MB），常驻内存约 25MB，冷启动耗时 < 100ms；
4. 两阶段检索优化：相比于让浏览器 Agent 操作 Dubbo Admin 页面，实测 Token 消耗降低 98.6%（单次排查约 570 Token）。

开源仓库：
👉 GitHub: https://github.com/b1n9bna/dubbo-mcp

希望能为 Dubbo 生态在 AI Coding 时代的工具链建设提供一个实用参考，非常欢迎社区老师和开发者试用、交流并提出宝贵建议！

Code of Conduct

• I agree to follow this project's Code of Conduct

[reeb-dev]

This is a useful developer-experience direction, especially because generic invocation removes the friction of maintaining a local client dependency graph. The staging/production boundary is the part I would make even more explicit: an MCP server turns an AI client into a powerful RPC caller, so its security model should be as deliberate as the Dubbo Admin model.

A few guardrails would make the production story easier to trust:

1. Do not expose one generic invoke tool in production. Generate narrow MCP tools from an allowlist of service/method pairs, with typed input schemas and an explicit read-only classification. That gives clients less room to discover or call an unintended method.
2. Bind authorization to the authenticated caller, not to the MCP client alone. The policy should decide which service, method, parameter shape, environment, and data classification a user may access.
3. Make every production call auditable: correlation id, principal, tool name, normalized arguments with sensitive fields redacted, result status, and latency. Keep logs separate from prompt/context capture so business data is not unintentionally retained.
4. Use short-lived credentials and require an explicit environment selector. A default that can reach production is risky; development should be the safe default, with a visible warning and stronger approval for staging/production.
5. Treat tool discovery as sensitive metadata too. Even a method signature can reveal internal capabilities, so discovery should follow the same authorization policy as invocation.

The two-stage discovery approach is valuable for token efficiency, but a published threat model plus a small end-to-end authorization test matrix would likely be the strongest next addition to the project.