unbridled-41 opened a new issue, #4556:
URL: https://github.com/apache/rocketmq-dashboard/issues/4556
### Before Creating the Issue
- [x] I have searched the open issues of this repository and believe this is
not a duplicate.
- [x] This is a defect in RocketMQ Studio.
### Studio Version
branch: `master`, commit `d50ffecc` (the MCP tool framework introduced by
#4225, reshaped by #4306/#4308)
### Describe the Bug
Nine of the forty catalog tools are platform-level: they are addressed by a
physical `clusterName` instead of an `instanceId`, their input schemas reject
`instanceId` (`additionalProperties: false`), and
`ToolCatalog.INSTANCE_ID_EXEMPT_TOOLS` exempts them from the mandatory instance
argument. Every one of them nevertheless declares `requiredCapabilities`. When
such a call is dispatched, `ToolExecutionService.resolveTargetInstance`
produces a **null** context instanceId by design, and `ToolCapabilityFilter`
then calls `CapabilityResolver.resolve(null)`, which throws
`CAPABILITY_INSTANCE_REQUIRED`.
Affected tools (all with non-empty `requiredCapabilities`):
`rmq.cluster.list`, `rmq.dashboard.summary`, `rmq.broker.list`,
`rmq.broker.describe`, `rmq.broker.config`, `rmq.nameserver.list`,
`rmq.nameserver.config`, `rmq.proxy.list`, `rmq.proxy.config`. Only
`rmq.audit.list` and `rmq.alert.rule.list` (empty `requiredCapabilities`) work.
The failure is total: passing `instanceId` in the body fails schema
validation first; omitting it hits `CapabilityResolver.resolve(null)`.
Discovery advertises these tools for a capable instance (`ToolDiscoveryService`
filters by that instance's capabilities), `McpToolRegistrar` lists them, and
the CLI faithfully follows the catalog — so every transport advertises tools
that can never execute.
### Steps to Reproduce
1. Start Studio with a default cluster and credentials so capabilities
resolve.
2. `POST
/api/ai/tools/rmq.cluster.list/execute?instanceId=open-source-local` with body
`{}` (the schema has no `instanceId` property).
3. The response is 400 `INVALID_ARGUMENT: Capability lookup requires a bound
Instance`.
The same call through MCP `tools/call` fails identically, and `rmqctl
cluster list --instance-id open-source-local` reports the same error.
### What Did You Expect to See?
The platform tool executes (its handler resolves clusters itself via
`PlatformClusterResolver`, no instance context needed).
### What Did You See Instead?
HTTP 400 `INVALID_ARGUMENT: Capability lookup requires a bound Instance` for
all nine platform tools, on every transport.
### Impact
The whole platform-tool surface of the v10 catalog (#4306) is unreachable:
cluster, dashboard, broker, nameserver and proxy inspection tools are
advertised but dead. Any chain test would have caught it —
`ToolInstanceRoutingTest` only runs `rmq.topic.list`, and `ToolControllerTest`
mocks the executor.
### Related work
- #4306 introduced the 40-tool catalog; #4308 moved capability resolution to
the instance context. The incompatibility between the two (exempt tools ×
non-empty capabilities) landed with them.
- #4506 (open) is about ambiguous platform cluster names — a different
platform-tool defect.
### PR
Fix incoming.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
