OAuth dynamic client registration omits refresh_token grant, breaking strict servers (e.g. Miro MCP)

[aheritier]

Summary

docker-agent's OAuth Dynamic Client Registration (RFC 7591) only advertises the authorization_code grant type when registering with a remote MCP server's authorization server. Strict authorization servers that require clients to declare every grant they will use reject the registration. Miro's hosted MCP server (https://mcp.miro.com/) is one such server.

Reproduction

Run an agent with a remote MCP toolset pointing at Miro:

toolsets:
  - type: mcp
    remote:
      url: https://mcp.miro.com/
      transport_type: streamable

On first run, the OAuth flow fails during client registration.

Observed error

mcp(remote host=mcp.miro.com transport=streamable) start failed: failed to initialize MCP client: failed to connect to MCP server: calling "initialize": sending "initialize": rejected by transport: Post "https://mcp.miro.com/": OAuth flow failed: client registration failed with status 400: {"error":"invalid_client_metadata","error_description":"grant_types must be authorization_code and refresh_token"}

Root cause

In pkg/tools/mcp/oauth_helpers.go, the registerClient function builds the registration request body advertising only authorization_code:

"grant_types":   []string{"authorization_code"},

docker-agent already implements and uses the refresh-token grant (refreshAccessToken / RefreshAccessToken in the same file send grant_type=refresh_token), so it should declare refresh_token at registration time per RFC 7591.

Fix

Advertise both grants during registration:

"grant_types": []string{"authorization_code", "refresh_token"},

This is RFC 7591-correct and backwards-compatible with lenient servers (Notion, Atlassian ignore the extra declared grant). A regression test asserting both grants are sent should accompany the change.

Impact

Any strict OAuth MCP server that enforces declared grant types is currently unusable via docker-agent's remote MCP support.