Add Service Dependency Support

[p25marti]

No ticket:

Problem

• Allow the MCP server to query for Service dependencies and dependants
• cc: Soufiane Amanzoul made these changes with Claude Code, I'm just pushing them up for him!

Solution

Checklist

• I have run this code, and it appears to resolve the stated issue.
• This PR has no user interface changes or has already received approval from product management to change the interface.
• Make a changie entry that explains the customer facing outcome of this change.

[souf-gmail]

Thanks, Paul!

[wesleyjellis]

One question about why we're returning locked?

I also ran claude with the goal of testing this out and found a few things:

1. search parameter is broken (both tools)

Passing any search value causes a GraphQL error:

failed to get dependencies: Message: Variable $search is declared by
ServiceDependenciesList but not used

Root cause (cmd/root.go:807-813): The MCP tool handler adds search to PayloadVariables, but the underlying GraphQL queries in dependencies.go:53 and
dependencies.go:86 only declare $after and $first — they have no $search variable. The GraphQL server rejects any undeclared variable.

Recommendation: remove the search field

2. Empty results return null instead of []

When a component has no dependencies/dependents, the response is null:

null

Root cause (cmd/root.go:820, 863): The dependencies and dependents slices are declared as var dependencies []serializedDependency (nil). When the loop finds no
edges, the slice stays nil, and json.Marshal(nil) produces null. It should be initialized as dependencies := []serializedDependency{}.

Recommendation: Initialize dependencies := []serializedDependency{}

3. Invalid service IDs silently return null instead of an error

Passing a completely invalid ID like "invalid-id-that-does-not-exist" returns null with no error, making it indistinguishable from a valid component with no dependencies. The API likely returns a null/empty service node, which produces no edges, leading to the same nil-slice-→-null outcome as bug #2.

Recommendation I think we should actually raise on this one, although I don't know we can? If not, returning [] is fine

[wesleyjellis]

These are kind of odd values to return. I think we should drop Locked, and I'm not sure what Notes contains, will have to look

[Farjaad]

even Aliases is odd

[wesleyjellis]

Apparently that's just what's returned by dependencies.go. We get the information on the edge (like note, locked) and ServiceId, which is just Id, and Aliases[], no name. I don't really want to muck with the opslevel-go submodule for this so this is the best we can do for now