Skip to main content
Glama

Explain a Symbol

explain_symbol
Read-onlyIdempotent

Explain a C# symbol's source plus chosen callers, callees, implementations, tests, siblings, or quality in one Markdown slice, replacing several separate code-intelligence calls.

Instructions

Explain a symbol: its source PLUS a chosen environment, as ONE dense AI-Builder-Markdown slice - the cold-read in a single call instead of 4-6 (get_context + find_usages + find_implementations + find_tests_for + ...). 'include' selects the environment axes (any combination): callers (the members that reference it, with their bodies, and their owner types as structure - not the calling types whole), callees (what it calls/depends on, depth 1), implementations (the types implementing it, if it's an interface), tests (its covering test cases), siblings (naming/file-convention kin), quality (complexity / efferent-coupling hotspot metrics). A partial type renders as ONE block (its declaration fragments are folded, a leading comment says which files) instead of one identical block per file. An empty include returns just the symbol's source - and then the manifest names the axes you could have asked for, so that answer is a stated choice rather than a silent default; an include token that names no axis is reported as dropped, whether or not a sibling token was valid. A leading manifest comment discloses what each merge axis actually found - so '(none)' is an honest negative (no impl / no caller / no test), not 'not asked'. Pass a type or method simple name (use find_symbol to disambiguate). Recall-safe (reads persisted facts); prefer it over export_markdown for one symbol's world. Multi-TFM solutions are deduplicated to one logical project per name (NEWEST TFM's instance, matching find_symbol's view).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
leanNoLean slice (default TRUE): drop the <AI_CONTEXT_SPEC>/<AI_CONTEXT_META> format-rules preamble and omit enabled-but-empty graph sections. Set false for the full AI-Builder-MD document with the format contract.
budgetNoOptional token budget (floored at 8000). Compacts/drops method bodies and, when the neighborhood overflows, drops the least-relevant types. The center symbol is always kept - with its full source when that fits, otherwise as STRUCTURE (identity, members, every method signature) plus a leading note that names the measured size of the full-code render and the budget that would hold it, so a 2000-line type under budget:8000 costs ~2000 tokens, not ~24000. The bundled environment (callers / tests / siblings / implementations) is BUDGET-BOUND - under a tight budget it is dropped to fit (a leading comment names the drops so you can ask for one by name). Omitted, the slice still renders against a ceiling (the active MCP profile's token budget, else a ~10000-token default budget) that bounds the merged environment - relevant above all with include=["callees"], whose outward neighborhood is the widest slice this server produces.
symbolYesThe type or method simple name to center on (use find_symbol to disambiguate), or the qualified Type.Member form to focus ONE declaration of a shared method name - the same string find_usages / find_tests_for / impact_of_change resolve. A bare name that matches several declarations seeds them all (a whole family can then be budget-capped), and the manifest says so and names the qualified form.
includeNoWhich environment axes to include (any combination, case-insensitive): callers, callees, implementations, tests, siblings, quality. Empty/omitted = just the symbol's source.
sessionIdYesThe session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.46513
    • changedInput schema / properties / sessionId / description
      Previous value: -"The session_id returned by analyze_solution."New value: +"The session_id returned by analyze_solution. Also takes an absolute .sln/.slnx/.slnf path, analyzed on first use."
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare a safe, idempotent, non-destructive read, so the bar is lower; the description nonetheless adds rich behavior: empty include returns only source and names available axes, unknown include tokens are reported as dropped, '(none)' is an honest negative rather than 'not asked', multi-TFM solutions are deduplicated to the newest TFM, and the read is recall-safe from persisted facts. These are meaningful traits not expressible in the annotations.

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?

Content is front-loaded with the core purpose and almost every clause carries non-redundant information (dedup, manifest honesty, budget fallback). However, it is an extremely long single paragraph with heavy nested parentheticals, which harms parseability despite the density.

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?

With no output schema, the description carries the return-shape burden and does so: it explains the manifest, the folded single-block partial-type rendering, the structural fallback under budget, and the honesty semantics of empty results. Given 100% schema coverage and annotations covering safety, nothing an agent needs to call it correctly 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 a baseline of 3 applies, but the description adds real meaning beyond the schema: it defines the empty-vs-dropped-token semantics of 'include', the qualified Type.Member focus form for 'symbol', and the honest-negative behavior of the manifest. The budget semantics are already largely in the schema, so the added value is real but partly overlapping.

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 specific verb ('Explain') and resource ('a symbol') and defines the deliverable precisely as 'ONE dense AI-Builder-Markdown slice.' It explicitly distinguishes itself from siblings by naming the 4-6 calls it replaces (get_context + find_usages + find_implementations + find_tests_for) and from export_markdown. An agent can tell exactly what this does without opening a schema.

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

Usage Guidelines5/5

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

It gives explicit when-to-use ('the cold-read in a single call instead of 4-6'), an alternative preference ('prefer it over export_markdown for one symbol's world'), and a prerequisite workaround ('Pass a type or method simple name (use find_symbol to disambiguate)'). The selection logic against named siblings is fully stated.

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