nexus-mcp-ci

Overview Schema Source Related Servers Discussions Admin

Call graph

graph

Read-onlyIdempotent

Trace function callers and callees, list transitive dependents, and inspect references before changing a shared symbol to see what breaks.

Instructions

Trace the call graph: who calls a function (direction='callers') or what it calls (direction='callees'). With transitive=true it lists everything that depends on the symbol, directly or indirectly; use that before you change a signature or rename, move or delete a shared function ("what breaks if I change X"). A callers result also has references: every use of the name as a whole word (source lines with their code, test files as counts), so you do not need a grep to check it. Edges are static, so calls through callbacks, reflection or dynamic dispatch are missing from the caller list; references still shows those lines.

Input Schema

Name	Required	Description	Default
`direction`	No	'callers' (who calls this) or 'callees' (what this calls)	callers
`transitive`	No	True = everything that depends on the symbol, directly or indirectly. Use before changing a shared symbol. Only valid with direction='callers'.
`symbol_name`	Yes	Name of the function/symbol to trace

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedv2.1.0Oct 29, 2026

addedInput schema / properties / direction / enum
```
Added value: +[
+  "callers",
+  "callees"
+]
```

removedInput schema / properties / max_depth

Removed value: -{
-  "default": 10,
-  "description": "Max traversal depth when transitive=True (default 10)",
-  "type": "integer"
-}

changedInput schema / properties / transitive / description

Previous value: -"True = full transitive closure for change-impact analysis (MUST use before refactoring a shared symbol). Only valid with direction='callers'."New value: +"True = everything that depends on the symbol, directly or indirectly. Use before changing a shared symbol. Only valid with direction='callers'."

AddedSep 18, 2026

TDQS

A4.6/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive, and the description goes further with the key limitation: edges are static, so callbacks, reflection and dynamic dispatch are absent from caller lists, while `references` still surfaces those lines. It also pre-announces the shape of a callers result (whole-word source lines, test files as counts), which is exactly the context an agent needs before trusting the output.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded with the core verb and both directions, then the risk-analysis use case, then the caveat — a sensible ordering. The parentheticals ('what breaks if I change X', the grep aside) are dense but each carries information, so no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 3-param read-only analysis tool with an output schema, this covers everything: what it returns for each direction, the extra `references` channel, and the static-analysis blind spot. Nothing an agent needs to call it correctly or interpret results is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% so the baseline is 3, but the description adds real meaning: it spells out the consequence of transitive=true ('everything that depends on the symbol, directly or indirectly') and the purpose of the references payload. It stops short of adding anything the schema lacks for direction/symbol_name.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Opens with a specific verb and resource ('Trace the call graph') and immediately disambiguates the two modes via direction='callers'/'callees'. An agent can tell this apart from search/find_symbol without consulting the schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit use case with a condition: use transitive before changing a signature or renaming/moving/deleting a shared function ('what breaks if I change X'). It also names grep as the alternative it replaces, but never mentions sibling tools like find_symbol or search, so routing between MCP tools is left to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server