Skip to main content
Glama
Sign In
codegraph

codegraph

by attnstack
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Rust
Local

callees

Query the downstream symbols that a given symbol statically calls, with call-site locations, to trace outgoing dependencies and invert who-calls analysis.

Instructions

查询某个符号静态调用了哪些下游符号（who_calls 的镜像），附调用点位置

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "symbol": "<symbol>"
    },
    "name": "callees"
  }
}

Input Schema

NameRequiredDescriptionDefault
symbolYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A3.8/5.0
Behavior3/5

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

With no annotations, the description carries the whole burden. It does disclose two valuable behavioral traits: the analysis is 'static' (not runtime) and results include call-site locations. However it never says whether results are direct (1-hop) only or transitive, nor what happens for an unknown symbol, which are the key ambiguities for a call-graph tool.

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

Conciseness5/5

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

A single short sentence with the core operation front-loaded, the sibling contrast in parentheses, and the extra return detail last. No wording is redundant.

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

Completeness3/5

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

The tool is simple (one required parameter) and has no output schema, so the description should at least pin down symbol format and result depth. It covers the return value loosely ('附调用点位置') but leaves the input format and direct-vs-transitive question open — a meaningful gap for a graph query.

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

Parameters2/5

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

Schema coverage is 0%, so the single 'symbol' parameter has no documentation anywhere. The description only implies it takes a symbol and adds no meaning about expected format (bare name, qualified name, or ID), which matters for correct invocation. The gap is not compensated.

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?

The description states a precise verb + resource ('查询某个符号静态调用了哪些下游符号') and immediately scopes directionality by naming the sibling it mirrors ('who_calls 的镜像'). An agent can distinguish callees from who_calls without opening either 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?

Naming who_calls as the mirror gives an implicit routing rule: use this for outgoing edges, use who_calls for incoming ones. There is no explicit 'do not use when' clause and no guidance on choosing between this, trace, or impact for deeper analysis, so it stops short of full when/when-not coverage.

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

Deploy Server

Other Tools