Add tags and team membership to users tool, bump SDK to v2026.5.6

[saditya370]

Summary

The users MCP tool returned name, email, contacts, and role but omitted tags and team memberships — both populated in OpsLevel and required for incident-routing and on-call queries (OLX use case: "which users are tagged as on-call leads?", "which team does this user belong to?"). This PR wires the now-available User.Tags and User.TeamsConnection fields (added in opslevel-go v2026.5.6) into the tool response, and bumps the SDK from v2025 to v2026.

Changes

src/cmd/root.go

Users tool (the actual feature)

• New serializedUser and serializedTeamRef types — keeps the JSON output tight: tags as []string of "key:value", teams as []{Id, Alias}.
• users handler now maps client.ListUsers(...) results through serializedUser instead of returning raw SDK nodes. Tags and teams are pulled from node.Tags.Nodes and node.TeamsConnection.Nodes.
• Tool description updated to mention tags and team memberships, with example questions ("which team does this user belong to?", "which users are tagged as on-call leads?") so the model picks the right tool.

v2026 bump fallout

• Import path: github.com/opslevel/opslevel-go/v2025 → /v2026.
• convertToServiceFilterInput updated for v2026's ServiceFilterInput shape change:
  • Key is now *ServiceFilterEnum (was PredicateKeyEnum value).
  • Type is now *TypeEnum (was PredicateTypeEnum value).
  • Predicates is now []ServiceFilterInput (was *[]ServiceFilterInput).
    Wire behavior of the components tool is unchanged.

src/cmd/client.go

• Import path bump: v2025 → v2026.

src/go.mod / src/go.sum

• Bumped github.com/opslevel/opslevel-go/v2025 v2025.7.28 → github.com/opslevel/opslevel-go/v2026 v2026.5.6.
• Pulled in transitive bumps from go mod tidy: iso8601 v1.6.0 → v1.7.0, hasura/go-graphql-client v0.14.4 → v0.15.1, cobra v1.9.1 → v1.10.1, plus minor golang.org/x/* updates.

Test plan

• go build ./... passes
• go vet ./... clean
• Smoke test: hit the users tool against a real account, verify tags and teams populate
• Verify tool description renders cleanly in MCP clients (Claude Desktop, etc.)
• Sanity-check components tool (filter conversion was rewritten for v2026's pointer-typed filter shape)

[andrewstillv15]

is this assignment necessary?

[saditya370]

replaced the named-variable pattern with a small local ptr[T any](v T) *T helper for convertToServiceFilterInput. The SDK's RefOf returns *Nullable[T] which doesn't fit ServiceFilterInput's *ServiceFilterEnum/*TypeEnum/*ConnectiveEnum fields, so a custom helper was the cleanest way to keep the struct literals inline without the named vars

[andrewstillv15]

Was this prompt tested/compared to any other prompts? I'm curious about how this would perform against something a little less verbose.

[saditya370]

Tried both versions in Claude Desktop with 6 test queries — 4 that should hit users and 2 that shouldn't. Both scored 6/6, so going with the shorter one to match the style of the other tool descriptions here.

Heads up: not a real benchmark — queries shared context within each run, so this is more of a sanity check than rigorous testing. If we care about prompt changes going forward, reviving mcp-eval/ or scripting against the API directly would be the way.