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 WIP: feat(mcp): 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. 😁