refactor: extract environment filtering from handleGetEnvironment into composable helpers

[jongio]

Code Smell: Long Method (Bloaters)

Severity: HIGH
Category: Bloaters > Long Method
File: cli/src/cmd/exec/commands/mcp.go (lines 270-317)

Description

The handleGetEnvironment function is 47 lines long and mixes four distinct responsibilities:

1. Environment reading — calls os.Environ() and parses key=value pairs
2. Prefix allowlist filtering — checks against allowedPrefixes slice
3. Secret denylist filtering — checks against secretPatterns slice
4. Response building — constructs the MCP JSON result

Each responsibility uses its own loop with its own local variables, making the function hard to follow. The prefix and secret filtering logic is interleaved with data transformation, and the filtering criteria (prefixes and patterns) are defined inline as anonymous slices rather than named constants.

Refactoring Recommendation

Extract filtering into composable helper functions:

// isAllowedPrefix checks if an env var name matches the allowlist.
func isAllowedPrefix(name string) bool { ... }

// isSecretVar checks if an env var name matches secret patterns.
func isSecretVar(name string) bool { ... }

// filterEnvironment returns safe, non-secret env vars matching the allowlist.
func filterEnvironment(envVars []string) []envVar { ... }

The handler becomes a thin wrapper:

func handleGetEnvironment(_ context.Context, _ azdext.ToolArgs) (*mcp.CallToolResult, error) {
    return azdext.MCPJSONResult(filterEnvironment(os.Environ())), nil
}

This also enables unit-testing the filtering logic independently of the MCP handler plumbing.

Impact

• Readability: Four interleaved concerns make the function hard to reason about
• Testability: Filtering logic can only be tested through the full MCP handler
• Reusability: If another handler needs env filtering, it would have to duplicate the logic