Skip to main content
Glama
nikolai-vysotskyi

trace-mcp

by nikolai-vysotskyi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

get_outline

Read-onlyIdempotent

Get all symbols for a file (signatures only, no bodies) — cheaper than Read for understanding a file before editing. Follow up with get_symbol to read one symbol's source.

Instructions

Get all symbols for a file (signatures only, no bodies) — cheaper than Read for understanding a file before editing. Follow up with get_symbol to read one symbol's source. nested: true expands large top-level symbols (default ≥100 LOC) into inner declarations, each carrying parentId + depth (max 3). Accepts project-relative or absolute file paths. For files in other registered projects, use call_project_tool. Read-only. Returns JSON: { path, language, symbols: [{ symbolId, name, kind, signature, lineStart, lineEnd, parentId?, depth? }] }. Supports output_format: "toon".

Input Schema

NameRequiredDescriptionDefault
pathYesRelative file path from project root (or absolute path)
nestedNoWalk the body of each top-level symbol past min_loc_for_nesting and emit inner declarations as extra rows carrying `parentId` + `depth`. Default false.
detail_levelNoOutput verbosity. "minimal" saves ~40-60% tokens (drops scores, fqn, signatures, summaries). Use to pick a candidate before get_symbol. Default: "default".
output_formatNo"json" (default) or "toon" (lossless, 30-60% fewer tokens). "markdown" is unsupported here and behaves as json.
min_loc_for_nestingNoMinimum (line_end - line_start) for a top-level symbol to be expanded when nested=true. Default 100.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv3.37.3
    • changedInput schema / properties / path / description
      Previous value: -"Relative file path"New value: +"Relative file path from project root (or absolute path)"
  2. Changed1 schema field changedv3.31.0
    • changedInput schema / properties / detail_level / description
      Previous value: -"Output verbosity. \"minimal\" returns ~40-60% fewer tokens (drops scores, fqn, signatures, summaries — keeps name/file/line). Use when you only need to pick a candidate before drilling in with get_symbol. Default: \"default\"."New value: +"Output verbosity. \"minimal\" saves ~40-60% tokens (drops scores, fqn, signatures, summaries). Use to pick a candidate before get_symbol. Default: \"default\"."
  3. Changed3 schema fields changedv3.3.0
    • removedInput schema / $schema
      Removed value: -"http://json-schema.org/draft-07/schema#"
    • changedInput schema / properties / nested / description
      Previous value: -"When true, walks the body of each top-level symbol whose LOC exceeds min_loc_for_nesting and emits inner function-like declarations as additional rows carrying `parentId` + `depth`. Default false — fully backward compatible."New value: +"Walk the body of each top-level symbol past min_loc_for_nesting and emit inner declarations as extra rows carrying `parentId` + `depth`. Default false."
    • changedInput schema / properties / output_format / description
      Previous value: -"Output format. \"json\" (default) returns JSON; \"toon\" returns Token-Oriented Object Notation — 30-60% fewer tokens, lossless. \"markdown\" is unsupported here and behaves as json."New value: +"\"json\" (default) or \"toon\" (lossless, 30-60% fewer tokens). \"markdown\" is unsupported here and behaves as json."
  4. Added
  5. Removedv1.38.0
  6. Changed2 schema fields changedv1.35.1
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / detail_level
      Added value: +{
+  "description": "Output verbosity. \"minimal\" returns ~40-60% fewer tokens (drops scores, fqn, signatures, summaries — keeps name/file/line). Use when you only need to pick a candidate before drilling in with get_symbol. Default: \"default\".",
+  "enum": [
+    "minimal",
+    "default",
+    "full"
+  ],
+  "type": "string"
+}
  7. First observedv0.1.0

TDQS

A4.8/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context beyond them: signatures-only output, nesting behavior with parentId/depth capped at max 3, toon format support, and the full JSON return shape. Since no output schema exists, disclosing the return structure is genuinely valuable.

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?

Well front-loaded: purpose first, then follow-up tool, then nesting, path handling, cross-project routing, and return shape. Dense with parentheticals and backticks, but essentially every clause carries actionable information; only the redundant 'Read-only' restates an annotation.

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 5-parameter read tool with no output schema, the description supplies everything an agent needs: scope, cost rationale, follow-up path, cross-project routing, nesting semantics, and the return shape. Nothing material 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 baseline is 3, but the description adds semantics the schema lacks: the nesting threshold default of >=100 LOC, the max depth of 3, and that inner rows carry parentId. The `nested` and path behaviors are clarified beyond the schema's own text.

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?

States a specific verb and resource ('Get all symbols for a file') and immediately scopes it ('signatures only, no bodies'). It also distinguishes itself from siblings by naming Read, get_symbol, and call_project_tool, so an agent can route correctly without opening any 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?

Explicit when-to-use ('cheaper than Read for understanding a file before editing'), explicit follow-up ('Follow up with get_symbol to read one symbol's source'), and explicit alternative for cross-project files ('use call_project_tool'). The detail_level guidance ('use to pick a candidate before get_symbol') reinforces the workflow.

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