Skip to main content
Glama
kapillamba4

Code Memory

by kapillamba4
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

find_dead_code

Identify unused functions, methods, and classes in your codebase by cross-referencing definitions against references. Get confidence scores and reasons for each candidate.

Instructions

USE THIS TOOL to find functions, methods, and classes that look like dead code (defined but never called).

PREREQUISITE: This tool requires indexing. If results are empty or you haven't indexed this session, call index_codebase(directory) first.

HOW IT WORKS: Cross-references the indexed symbol table against the indexed reference table. Any symbol with no reference outside its own definition body is flagged as a candidate. Each candidate is scored with a confidence in [0.0, 0.99] and a list of human-readable reasons explaining the verdict.

TRIGGER - Call this tool when the user asks:

  • "Find dead code / unused functions / unused classes"

  • "What's not used in this codebase?"

  • "Are there functions I can safely delete?"

  • "Show me dead code in "

  • "Find unreachable / orphaned code"

HEURISTICS APPLIED:

  • Excludes Python dunder methods (init, call, etc) — protocol methods

  • Excludes 'main' — common entry point

  • Excludes test files by default (override via include_tests=True)

  • Excludes anonymous and file-level fallback symbols

  • Lower confidence for methods in JS/TS/Go/Rust/C++/Kotlin (member-access calls aren't captured by the reference index)

  • Lower confidence for symbols defined in init.py / index.{js,ts} / mod.rs (likely re-exports)

  • Lower confidence for decorated symbols (likely framework-registered)

  • Lower confidence when the name is shared across multiple symbols

LIMITATIONS: Cannot detect symbols invoked via reflection, dynamic dispatch, string-based imports, or framework registration. Treat results as candidates to investigate, NOT as a definitive deletion list. Always verify before removing code.

Do NOT use this tool for:

  • Finding code definitions (use search_code with "definition")

  • Finding where code is used (use search_code with "references")

  • General code search (use search_code with "topic_discovery")

Args: directory: Path to the project directory to scan. min_confidence: Minimum confidence (0.0-1.0) to include a candidate. Default 0.5. Raise to filter aggressively. kinds: Symbol kinds to scan. Default ['function', 'method', 'class']. Allowed values: 'function', 'method', 'class'. include_tests: If True, also scan symbols in test files. Default False. top_k: Maximum candidates to return, sorted by confidence desc (default 50, max 500).

Returns: Dict with: - candidates: list, each containing name, kind, file_path, line_start, line_end, confidence, reasons, source_excerpt. - count: number of candidates returned. - scanned_symbols: count of symbols inspected after exclusions. - total_symbols: total symbols of the requested kinds in the index. - limitations: list of caveats for interpreting the results.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindsNo
top_kNo
directoryYes
include_testsNo
min_confidenceNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
resultYes

Tool Definition Quality

A4.9/5.0
Behavior5/5

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

Since no annotations are provided, the description fully bears the burden. It explains the mechanism (cross-referencing symbol and reference tables), details heuristics applied (e.g., excluding dunder methods, test files, etc.), and discloses limitations (cannot detect reflection, dynamic dispatch, etc.). It also describes the output format.

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?

The description is well-structured with sections (PREREQUISITE, HOW IT WORKS, TRIGGER, HEURISTICS, LIMITATIONS, Do NOT use). However, it is somewhat verbose with detailed lists of triggers and heuristics; some minor trimming could improve conciseness while retaining clarity.

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?

Given the tool's complexity and that an output schema is provided, the description is exceptionally complete. It covers prerequisites, mechanism, heuristics, limitations, return format, and parameter details. No gaps are apparent.

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

Parameters5/5

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

With 0% schema description coverage, the description explains all five parameters: directory (required), min_confidence (default 0.5, range 0.0-1.0), kinds (default ['function','method','class'], allowed values enumerated), include_tests (default false), top_k (default 50, max 500). It adds meaning beyond the schema.

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 clearly states the tool's purpose: 'find functions, methods, and classes that look like dead code (defined but never called). It distinguishes itself from siblings like search_code by specifying what it should not be used for.

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?

The description provides explicit triggers for when to call the tool (user queries about dead code) and explicitly lists when not to use it, mentioning alternative tools like search_code. It also includes a prerequisite (indexing) and a prerequisite action.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/kapillamba4/code-memory'

If you have feedback or need assistance with the MCP directory API, please join our Discord server