Skip to main content
Glama
timohaa

Scopewalker MCP

by timohaa

find_dead_code

Identify declared symbols that nothing references in a codebase. Distinguish unreachable dead code from unreferenced exports that may be used externally.

Instructions

Finds declared symbols that nothing references. dead_code is proven unreachable within the scan; unreferenced_exports may be used outside it.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesTarget path
limitNoMax results per list
max_depthNoMax depth
max_filesNoMax files to scan
extensionsNoFilter by extensions
include_hiddenNoInclude hidden
ignore_patternsNoExclude patterns

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.3.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It discloses a meaningful behavioral nuance—that dead_code is proven unreachable while unreferenced_exports may be used outside the scan—but it does not address other aspects like read-only nature, side effects, performance, or result format. The coverage is minimal.

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?

Two sentences with zero wasted words. The core purpose is front-loaded, and the second sentence clarifies the output categories. Highly efficient and well-structured.

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

Completeness2/5

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

With no output schema and no annotations, the description leaves important context missing: what the results look like (e.g., file paths, symbol names), how limit and depth interact, and whether the scan is read-only. The description is too sparse for a 7-parameter tool without an output schema.

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

Parameters3/5

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

Schema description coverage is 100%, meaning all 7 parameters are documented in the schema. The description adds no parameter-specific details beyond that. Baseline 3 is appropriate because the schema handles parameter semantics.

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

Purpose4/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: finding declared symbols that nothing references. It specifies the resource (declared symbols) and the action (finds unreferenced ones). It also adds nuance by distinguishing dead_code from unreferenced_exports, but it does not explicitly differentiate from sibling tools like get_code_smells or get_code_inventory, so it falls short of a 5.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus the alternative code-analysis siblings. The description does not mention any exclusions, alternatives, or context that would help an agent decide between find_dead_code and other similar tools. This is a clear gap.

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