feat(mcp): expose agents as MCP resource with change notifications

[onematchfox]

Adds a kagent://agents MCP resource that lists agents as JSON. Clients can read the resource directly or subscribe to receive notifications when the agent list changes. I've left the existing list_agents tool in place for now to not break existing consumers although this can potentially be removed prior to the next breaking version?

Notes:

• Contains changes from both fix(controller): recover MCP auth session from RequestExtra in tool handlers #1853 and refactor(controller): invoke agents directly in MCP handler #1855 at present. Diff will clean up as those get reviewed.
• Post this change we can also adjust the implementation of list agents to use the registry introduced in refactor(controller): invoke agents directly in MCP handler #1855 to avoid needing to query Kube API every time someone calls the endpoint.

[Copilot]

Pull request overview

Adds an MCP “agents” resource (kagent://agents) backed by the controller’s Kubernetes agent listing, plus change notifications so MCP clients can subscribe and refresh when the agent list changes. It also refactors MCP agent invocation to use in-process A2A clients via a new registry maintained by the A2A registrar (avoiding a loopback HTTP hop).

Changes:

• Introduce kagent://agents MCP resource (JSON) and resources/updated notifications via NotifyAgentsChanged.
• Refactor invoke_agent to call agents via AgentClientRegistry populated by A2ARegistrar.
• Add unit tests validating auth propagation for invoke_agent when MCP request context is detached.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
go/core/pkg/app/app.go	Wires A2ARegistrar into MCP handler via ClientRegistry() and registers agent-change callback for notifications.
go/core/internal/mcp/mcp_handler.go	Adds MCP resource + notifications; refactors list logic; switches invocation to registry-based A2A clients and restores auth session from RequestExtra.
go/core/internal/mcp/mcp_handler_test.go	New tests for recovering auth from MCP RequestExtra and propagating upstream auth to A2A calls.
go/core/internal/a2a/agent_client_registry.go	Adds a concurrency-safe registry for mapping agent refs to A2A clients and invoking them directly.
go/core/internal/a2a/a2a_registrar.go	Populates registry during agent lifecycle and triggers a callback on agent add/update/delete.

Comments suppressed due to low confidence (1)

go/core/internal/mcp/mcp_handler.go:236

• Comment says the agent reference can be "namespace/name or just name", but the implementation rejects values without a slash and returns an error. Either support the name-only form (e.g., defaulting the namespace) or update the comment/jsonschema to match the actual required format.

	// Parse agent reference (namespace/name or just name)
	agentNS, agentName, ok := strings.Cut(input.Agent, "/")
	if !ok {
		return &mcpsdk.CallToolResult{
			Content: []mcpsdk.Content{
				&mcpsdk.TextContent{Text: "agent must be in format 'namespace/name'"},

---

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

[EItanya]

My initial review for this is that it looks great. I think a dynamic list makes a lot of sense here. My one nit pick is the following:

// SetAgentChangeCallback registers a function called whenever an agent is
// added, updated, or removed. The callback receives the context from the
// informer event so it can propagate cancellation.
func (a *A2ARegistrar) SetAgentChangeCallback(fn func(ctx context.Context)) {
	a.onAgentChange = fn
}

func (a *A2ARegistrar) notifyAgentChange(ctx context.Context) {
	if a.onAgentChange != nil {
		a.onAgentChange(ctx)
	}
}

Those 2 functions and the way the interact with the mcp_handlers. Specifically I Have a really hard time tracking down callbacks, maybe we could use a small interface for NotifyAgentsChanged or something? What do you think?

As far as removing the existing list_agents. I'm not sure about that. Resources aren't as widely used yet so I'd rather wait until there's more wide usage of them