feat: add GoosePlatform to AgentConfig and MCP initialization

[Jazzcort]

Summary

Introduces a GoosePlatform enum to distinguish between GooseCli and GooseDesktop environments.
This allows the MCP client to conditionally advertise capabilities based on the active
platform.

Changes:

• Core: Added GoosePlatform enum to crates/goose/src/agents/agent.rs and included it in
  AgentConfig.

• MCP Integration: Updated GooseClient to include platform info. Now, the client
  advertises its client name as "goose-desktop" while using Goose Desktop and "goose-cli"
  for Goose Cli. Leave params.capabilities.extension part for feat(mcp): upgrade rmcp to 0.15.0 and advertise MCP Apps UI extension capability #6927

• Plumbing: Updated ExtensionManager, McpClient, and Agent constructors across the codebase
  to propagate the platform type.

• Defaults:

  • goose-acp and goose-cli default to GoosePlatform::GooseCli.
  • AgentManager (used by the desktop execution flow) defaults to
    GoosePlatform::GooseDesktop.

• Testing: Updated scenario runners and integration tests to explicitly pass a platform
  variant (typically GooseCli).

Type of Change

• Feature
• Bug fix
• Refactor / Code quality
• Performance improvement
• Documentation
• Tests
• Security fix
• Build / Release
• Other (specify below)

Testing

For the client side, try this in the get_info function at crates/goose/src/agents/mcp_client.rs

eprintln!("Platform: {:?}", self.goose_platform);

And then launch both cli and desktop to see if the displayed platform is correct.

For the server side, just try to catch the initialize request from both goose desktop and goose cli and check if

{
  "io.modelcontextprotocol/ui": {
    "mimeTypes": ["text/html;profile=mcp-app"]
  }
}

exists under experimental field.

[Jazzcort]

I noticed that #6927 also addresses adding the mcp-apps capability to the initialize request and it's waiting on a PR at rmcp to add the extension field under capabilities.

@aharvard, I propose we land this PR first and then merge #6927 to handle the get_info modifications.

The main use case for differentiating between Goose Desktop and the CLI is ensuring the MCP server can provide alternative tools when it detects the client is not mcp-apps compatible. What do you think?

[aharvard]

@Jazzcort, I like the thinking of goose differentiating between desktop and CLI. I can imagine this will be beneficial on many fronts. The more info we can provide to MCP servers, the better end UX can be!

From what I understand, based on looking at this PR, and correct me if I'm wrong, you're introducing the ability to advertise MCP Apps under the capabilities.experimental. And from there, servers could detect if this is goose desktop or goose CLI. Is that your intent here?

It sounds like there might be two distinct problems to solve. Do you agree?

1. Advertising if the client is goose-desktop or goose-cli
2. Declaring MCP App support when users are using goose desktop

Now that both MCP Apps (SEP-1865) and MCP Extensions (SEP-1724) have landed, I think we should collaborate to achieve the below outcome when goose sends the initialize request (I've abbreviated the params for illustration purposes)

Do you want to pivot this PR to conditionally address prams.clientInfo.name?

Then, we can leverage your platform detection to set capabilities.extensions for goose Desktop in #6927 (or based on timing, in a follow-up PR).

// goose Desktop
{
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": {
      "extensions": {
        "io.modelcontextprotocol/ui": {
          "mimeTypes": ["text/html;profile=mcp-app"]
        }
      }
    },
    "clientInfo": {
      "name": "goose-desktop",
      "version": "..."
    }
  }
}

// goose CLI
{
  "method": "initialize",
  "params": {
    "protocolVersion": "2024-11-05",
    "capabilities": { },
    "clientInfo": {
      "name": "goose-cli",
      "version": "..."
    }
  }
}

[Jazzcort]

From what I understand, based on looking at this PR, and correct me if I'm wrong, you're introducing the ability to advertise MCP Apps under the capabilities.experimental. And from there, servers could detect if this is goose desktop or goose CLI. Is that your intent here?

You're absolutely right!

It sounds like there might be two distinct problems to solve. Do you agree?

1. Advertising if the client is goose-desktop or goose-cli
2. Declaring MCP App support when users are using goose desktop

agree!

Do you want to pivot this PR to conditionally address prams.clientInfo.name?

That sounds great! I'll pivot it to just address prams.clientInfo.name and leave the rest for #6927

[jamadeo]

Makes sense to me that we'd need to express different capabilities depending on the client. But I think it would be cleaner if, instead of a CLI/Desktop enum, the extension manager itself were configured directly with these. Since CLI and desktop construct their agent/extension manager in different places, it would be easy enough to configure there.

[Jazzcort]

@jamadeo Thanks for the review! I'll work on the patch! 😁

[Jazzcort]

@jamadeo So after my investigation, I found the last place we can differentiate Desktop/Cli is when we create Agent. (Please correct me if I'm wrong) And the extension manager is created within Agent. Therefore, without passing something to the agent to differentiate the platform, I don't think there is a way to know which platform the users are using while creating the extension manager. Please let me know if you do find a way to make this work without passing the enum. 😁

[Jazzcort]

@jamadeo Any updates on this? Let me know if you think of any better ways other than passing the enum when creating Agent.

[aharvard]

FYI @Jazzcort, we just merged #6927
Happy to review your conditional approach to advertise MCP Apps for Desktop when ready

[Jazzcort]

@aharvard Thanks for the update! I will fix the conflicts. Will ping you when it's done. Does this sounds good to you?

[jamadeo]

sorry for the late reply @Jazzcort - what I meant was, we could specify capabilities instead of a platform type. So instead of passing the cli/desktop enum, you'd configure the extension manager itself to be created with capabilities/name. Something like

struct ExtensionManagerCapabilities {
    mcpui: bool
}

impl ExtensionManager {
    pub fn new(
        provder: ...,
        ...
        client_name: &str,
        capabilities: ExtensionManagerCapabilities
    ) -> { ...

I see that at the Agent level, you might just want to keep the CLI/Desktop distinction, but this way you don't make that a concern of the extension manager itself

[Jazzcort]

@jamadeo Got it! Sorry for the misunderstanding there. 😅 I see your point now and will modify it as you suggested!

[Jazzcort]

@aharvard @jamadeo
Sorry for the delay on this. I ended up adding both ExtensionManagerCapabilities and GooseMcpClientCapabilities. It just felt a bit weird to pass ExtensionManagerCapabilities straight into GooseClient, so I split them out.

They’re basically the same right now, but I see them as handling fine-grained configuration at different levels, so it might give us more flexibility later if they start to diverge.

Curious to hear what you all think — happy to tweak it if this doesn’t feel right.

[jamadeo]

Looks great, thanks @Jazzcort

[Jazzcort]

@jamadeo Thanks for reviewing! 😁