feat(DATAGO-118768): Support remote MCP server configuration in sam add agent --gui

[solace-pjones]

What is the purpose of this change?

This PR adds support for configuring remote MCP (Model Context Protocol) servers through the agent configuration GUI (sam add agent --gui). Previously, users had to manually edit YAML files to configure remote MCP servers with authentication. This change provides a user-friendly form-based interface for all MCP transport types (stdio, SSE, streamable-http) with built-in authentication support.

How was this change implemented?

Frontend (React/TypeScript):

• Created two new reusable input components:

  • KeyValueInput.tsx: Manages key-value pairs (environment variables, config options) with inline editing
  • ListInput.tsx: Manages ordered lists (command arguments) with move up/down functionality

• Enhanced AgentToolsStep.tsx with transport-specific configuration forms:

  • Separate UI sections for stdio, SSE, and streamable-http transports
  • Authentication configuration (Bearer token, API key with custom headers) for remote transports
  • Environment variables UI restricted to stdio transport only (matching backend behavior)
  • Auto-inclusion of "web" builtin tool group when remote transports are configured
  • Transport type now displayed in the tools table details column

• Updated AddAgentFlow.tsx:

  • Ensures tool_type field is always first in generated YAML for better readability
  • Improved field ordering logic

Backend (Python):

• agent_cmd.py: Adds default 30s timeout to MCP connection params, uses sort_keys=False for YAML preservation
• setup.py: Enhanced MCP tool loader with SSE and streamable-http transport support, authentication header construction

Key Design Decisions (optional - delete if not applicable)

Why store auth fields separately?
Auth credentials are stored both in connection_params.headers (for runtime use) and as separate fields (auth_type, auth_token, auth_header_name) to enable proper round-trip editing. When users edit an existing MCP tool, the form fields are pre-populated from these separate fields.

Why restrict environment variables to stdio?
The backend only applies environment variables to stdio connections (local process environments). While the UI previously allowed setting env vars for all transport types, they were ignored for remote transports. We restricted the UI to match backend behavior and avoid user confusion.

Why auto-include web tools for remote transports?
Remote MCP servers (SSE/streamable-http) require network access. The "web" builtin tool group is automatically added to ensure agents have the necessary capabilities to connect to remote servers.

How was this change tested?

• Manual testing:

  • ✅ Created MCP tool with stdio transport - verified environment variables UI appears
  • ✅ Created MCP tool with SSE transport - verified no environment variables UI, auth fields work
  • ✅ Created MCP tool with streamable-http transport - verified auth configuration works
  • ✅ Edited existing MCP tools - verified all fields properly populated
  • ✅ Verified transport type displays correctly in tools table ("Transport: stdio/sse/streamable-http")
  • ✅ Verified "web" tool group auto-added for remote transports

• Unit tests: None added (UI component tests would be beneficial future work)

• Integration tests: Tested through live config portal server

• Known limitations:

  • Duplicate key validation in KeyValueInput silently ignores duplicates (low priority UX improvement)

Is there anything the reviewers should focus on/be aware of?

Key areas for review:

1. Auth field round-tripping (lines 136-175 in AgentToolsStep.tsx): Verify auth credentials are properly extracted when editing
2. Environment variables scoping (line 841): Now only shown for stdio - confirm this matches expected behavior
3. Transport type display (lines 422-438): Extracts from connection_params.type - verify this works for all scenarios

This PR supersedes: Original PR #673 by @RZuchniak - I've taken over shepherding this feature to main with the improvements listed above.

Breaking changes: None - fully backwards compatible with existing agent configurations.

[sonarqube-solacecloud]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[gregmeldrum]

Looks good!