fix(mcp): include SandboxAgents in MCP agent listing by LuBingtan · Pull Request #2204 · kagent-dev/kagent

LuBingtan · 2026-07-10T14:09:57Z

Summary

include Ready/Accepted SandboxAgent resources in MCP list_agents and kagent://agents
accept both DeploymentReady and WorkloadReady Ready reasons when filtering MCP-visible agents
let MCP invoke_agent resolve SandboxAgent clients registered under the sandbox route key

Reproduction

Added a focused MCP unit test that fails on main: a regular Agent is listed, but an Accepted/Ready SandboxAgent with WorkloadReady is omitted.

Tests

GOCACHE=/tmp/go-build GOFLAGS=-buildvcs=false go test ./internal/mcp -run TestListReadyAgentsIncludesSandboxAgents -count=1
GOCACHE=/tmp/go-build GOFLAGS=-buildvcs=false go test ./internal/a2a -run TestAgentClientRegistrySendMessageFallsBackToSandboxRoute -count=1
GOCACHE=/tmp/go-build GOFLAGS=-buildvcs=false go test ./internal/a2a -count=1
GOCACHE=/tmp/go-build GOFLAGS=-buildvcs=false go test ./internal/mcp -count=1

Copilot

Pull request overview

This PR fixes MCP agent visibility and invocation for substrate-backed SandboxAgent resources by listing them alongside declarative Agent CRs and by recognizing both deployment- and workload-ready condition reasons, so MCP list_agents / kagent://agents / invoke_agent behave consistently with the REST/UI paths.

Changes:

Extend MCP-ready agent enumeration to include both Agent and SandboxAgent objects.
Treat Ready=True with reason DeploymentReady or WorkloadReady as MCP-invokable (when Accepted=True).
Add AgentClientRegistry.SendMessage fallback to resolve sandbox-registered route keys, plus focused unit tests.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.

File	Description
go/core/internal/mcp/mcp_handler.go	Lists both `Agent` and `SandboxAgent` CRs and applies unified Accepted+Ready filtering for MCP visibility.
go/core/internal/mcp/mcp_handler_test.go	Adds a regression test ensuring Ready/Accepted `SandboxAgent` entries appear in MCP `listReadyAgents`.
go/core/internal/a2a/agent_client_registry.go	Falls back to sandbox route keys when resolving clients during `SendMessage`.
go/core/internal/a2a/agent_client_registry_test.go	Adds a regression test verifying the sandbox-route fallback behavior.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

LuBingtan · 2026-07-10T14:21:57Z

+	called := false
+	server := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
+		called = true
+		var rpcReq map[string]any
+		require.NoError(t, json.NewDecoder(r.Body).Decode(&rpcReq))


Updated in 0b81aba: called is now an atomic.Bool, with the handler using called.Store(true) so the test no longer has an unsynchronized cross-goroutine write/read. Verified with go test -race ./internal/a2a -run TestAgentClientRegistrySendMessageFallsBackToSandboxRoute -count=1 and go test -race ./internal/a2a -count=1.

LuBingtan · 2026-07-10T14:21:58Z

+		&a2atype.SendMessageRequest{Message: a2atype.NewMessage(a2atype.MessageRoleUser, a2atype.NewTextPart("hello"))},
+	)
+	require.NoError(t, err)
+	require.True(t, called)


Updated in 0b81aba: the assertion now reads the atomic value via called.Load(). I also ran the focused test and the full internal/a2a package with -race.

EItanya

Unfortunately this only masks the problem that exists, and we really need to figure out how to really fix this. If an Agent exists with that Name, Namespace it will return that even if you intended to get the SandboxAgent. I think we need to start including the GroupKind in order to properly key the entries

LuBingtan · 2026-07-11T03:51:55Z

@EItanya thanks, that makes sense. I agree the current fallback from namespace/name to the sandbox route can select the wrong target when an Agent and SandboxAgent share the same namespace/name.

Before pushing another revision, I want to confirm the shape I am thinking about:

list_agents / kagent://agents should return each entry with both ref and groupKind, for example:
- ref: "default/my-agent", groupKind: "Agent.kagent.dev"
- ref: "default/my-agent", groupKind: "SandboxAgent.kagent.dev"
invoke_agent should accept an optional groupKind argument. If omitted, it defaults to Agent.kagent.dev for backward compatibility with existing clients.
AgentClientRegistry should route by (groupKind, namespace, name) instead of falling back from the regular Agent key to the SandboxAgent key.
Tests should cover the same namespace/name collision case and assert that groupKind: SandboxAgent.kagent.dev invokes the SandboxAgent backend, not the regular Agent backend.

Does that match what you had in mind, or would you prefer a different MCP input shape (for example encoding the kind directly into the agent ref instead of a separate groupKind field)?

LuBingtan · 2026-07-13T05:04:01Z

@EItanya implemented the GroupKind-based routing in 2d3b17b4.

list_agents and kagent://agents now return groupKind.
invoke_agent accepts groupKind, defaulting to Agent.kagent.dev for backward compatibility.
The registry now selects the exact (groupKind, namespace, name) route and no longer falls back to a SandboxAgent route.
The regression test covers an Agent and SandboxAgent with the same namespace/name and verifies that the SandboxAgent backend is selected.

I also checked that routeKeyForGroupKind delegates to the existing routeKey, preserving the current route keys: namespace/name for Agent.kagent.dev and sandboxes/namespace/name for SandboxAgent.kagent.dev. This matches the A2A registrar, which derives the same keys from workload mode.

One remaining extension point: if a new AgentObject kind is added, or an existing kind can map to a different workload mode, its GroupKind-to-route mapping must be added explicitly. Unsupported kinds return an error instead of silently falling back to a potentially wrong target.

Verified with go test ./internal/a2a -count=1 and go test ./internal/mcp -count=1.

EItanya · 2026-07-14T13:02:05Z

+func (r *AgentClientRegistry) RegisterForGroupKind(groupKind, namespace, name string, c *a2aclient.Client) error {
+	key, err := routeKeyForGroupKind(groupKind, namespace, name)
+	if err != nil {
+		return err
+	}
+	r.set(key, c)
+	return nil
+}
+


I don't like adding functionality like this just for tests, and it seems to be only called by the tests

Updated in a6e6be8: removed RegisterForGroupKind. The production registrar continues to register its workload-derived route key via set, and the A2A test uses that internal route setup directly, so no test-only registration API remains.

EItanya · 2026-07-14T13:03:39Z

+}
+
+// SendMessageForGroupKind invokes an agent directly via its cached A2A client.
+func (r *AgentClientRegistry) SendMessageForGroupKind(ctx context.Context, groupKind, namespace, name string, req *a2atype.SendMessageRequest) (a2atype.SendMessageResult, error) {


This is a classic claudism. Let's just break the SendMessage API and add the new param

Updated in a6e6be8: removed SendMessageForGroupKind and changed SendMessage to require groupKind directly. The MCP handler now calls the revised API. Verified with go test ./internal/a2a ./internal/mcp -count=1 and the focused A2A route test under -race.

Signed-off-by: lubingtan <bingtanlu@gmail.com>

LuBingtan · 2026-07-17T03:40:57Z

Hi @EItanya would you pls take a look again? thanks!

Copilot AI review requested due to automatic review settings July 10, 2026 14:09

LuBingtan requested a review from a team as a code owner July 10, 2026 14:09

github-actions Bot added the bug Something isn't working label Jul 10, 2026

Copilot started reviewing on behalf of LuBingtan July 10, 2026 14:10 View session

Copilot AI reviewed Jul 10, 2026

View reviewed changes

LuBingtan force-pushed the fix-mcp-sandboxagent-listing branch 2 times, most recently from 35bee8d to 0b81aba Compare July 10, 2026 14:20

EItanya requested changes Jul 10, 2026

View reviewed changes

LuBingtan force-pushed the fix-mcp-sandboxagent-listing branch from 1e15cae to 2d3b17b Compare July 13, 2026 04:11

EItanya requested changes Jul 14, 2026

View reviewed changes

iplay88keys mentioned this pull request Jul 14, 2026

Resolve agent kind name collisions with kind-qualified DB ids and per-kind API routes #2246

Draft

LuBingtan added 3 commits July 15, 2026 13:21

fix(mcp): include sandbox agents in agent listing

d493404

Signed-off-by: lubingtan <bingtanlu@gmail.com>

fix(mcp): route agent invocations by group kind

74df431

Signed-off-by: lubingtan <bingtanlu@gmail.com>

fix(mcp): disambiguate agent invocation by group kind

a6e6be8

Signed-off-by: lubingtan <bingtanlu@gmail.com>

LuBingtan force-pushed the fix-mcp-sandboxagent-listing branch from d03f473 to a6e6be8 Compare July 15, 2026 05:27

the-mentor mentioned this pull request Jul 15, 2026

fix(mcp): include SandboxAgents in list_agents and invoke_agent #2249

Open

4 tasks

EItanya and others added 2 commits July 15, 2026 11:11

Merge branch 'main' into fix-mcp-sandboxagent-listing

97f7934

Merge branch 'main' into fix-mcp-sandboxagent-listing

e509a53

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

fix(mcp): include SandboxAgents in MCP agent listing#2204

fix(mcp): include SandboxAgents in MCP agent listing#2204
LuBingtan wants to merge 5 commits into
kagent-dev:mainfrom
LuBingtan:fix-mcp-sandboxagent-listing

LuBingtan commented Jul 10, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

LuBingtan Jul 10, 2026

Uh oh!

LuBingtan Jul 10, 2026

Uh oh!

EItanya left a comment

Uh oh!

LuBingtan commented Jul 11, 2026

Uh oh!

LuBingtan commented Jul 13, 2026 •

edited

Loading

Uh oh!

EItanya Jul 14, 2026

Uh oh!

LuBingtan Jul 15, 2026 •

edited

Loading

Uh oh!

EItanya Jul 14, 2026

Uh oh!

LuBingtan Jul 15, 2026 •

edited

Loading

Uh oh!

LuBingtan commented Jul 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Conversation

LuBingtan commented Jul 10, 2026

Summary

Reproduction

Tests

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Reviewed changes

Uh oh!

LuBingtan Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

LuBingtan Jul 10, 2026

Choose a reason for hiding this comment

Uh oh!

EItanya left a comment

Choose a reason for hiding this comment

Uh oh!

LuBingtan commented Jul 11, 2026

Uh oh!

LuBingtan commented Jul 13, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

EItanya Jul 14, 2026

Choose a reason for hiding this comment

Uh oh!

LuBingtan Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

EItanya Jul 14, 2026

Choose a reason for hiding this comment

Uh oh!

LuBingtan Jul 15, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

LuBingtan commented Jul 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

LuBingtan commented Jul 13, 2026 •

edited

Loading

LuBingtan Jul 15, 2026 •

edited

Loading

LuBingtan Jul 15, 2026 •

edited

Loading