Skip to main content
Glama
timohaa

Scopewalker MCP

by timohaa
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

get_prop_drilling

Detect prop drilling by tracing parameter names through function chains. Use limit and summary options to control results.

Instructions

Detects parameter threading (prop drilling) by finding parameter names passed through chains of functions. Use limit/summary_only to control output.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesTarget path
limitNoMax results
max_depthNoMax depth
max_filesNoMax files to scan
extensionsNoFilter by extensions
summary_onlyNoReturn only summary without per-parameter details (default false)
exclude_commonNoExclude common parameter names like id, key, className (default false)
include_hiddenNoInclude hidden
ignore_patternsNoExclude patterns
min_occurrencesNoMinimum function occurrences to flag (default 3)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.3.0
    • addedInput schema / properties / extensions / items / maxLength
      Added value: +32
    • addedInput schema / properties / extensions / items / pattern
      Added value: +"^\\.?[A-Za-z0-9_+-]+$"
    • addedInput schema / properties / extensions / maxItems
      Added value: +100
    • addedInput schema / properties / ignore_patterns / items / maxLength
      Added value: +512
    • addedInput schema / properties / ignore_patterns / maxItems
      Added value: +100
    • changedInput schema / properties / limit / maximum
      Previous value: -9007199254740991New value: +5000
    • changedInput schema / properties / max_depth / maximum
      Previous value: -9007199254740991New value: +64
    • changedInput schema / properties / max_files / maximum
      Previous value: -9007199254740991New value: +10000
    • changedInput schema / properties / min_occurrences / maximum
      Previous value: -9007199254740991New value: +1000
  2. First observedv1.0.4

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the burden of explaining behavior. It discloses the core heuristic approach ('finding parameter names passed through chains of functions'), which is useful. However, it does not explain return format, whether results are summary + per-parameter details, false-positive risks, or what 'prop drilling' detection entails in practice.

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 no filler. The first sentence states purpose and mechanism; the second quickly points to the key output controls. Every sentence earns its place and the core information is front-loaded.

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?

The tool has 10 parameters and no output schema, and there are no annotations to fill gaps. The description does not explain what the output looks like, how chains are defined, what summary-only mode returns, or which fields like max_depth, max_files, and include_hidden affect results in practice.

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%, so the schema already documents all 10 parameters. The description adds only a minor hint by naming limit and summary_only as output controls, but this does not meaningfully improve on the existing parameter descriptions.

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 uses a specific verb ('Detects') and a clear resource ('parameter threading (prop drilling)'), and it explains the mechanism ('finding parameter names passed through chains of functions'). This distinguishes it from sibling tools like get_line_counts or get_functions, even without naming an alternative.

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?

The description says 'Use limit/summary_only to control output' but gives no guidance on when to use this tool versus alternatives such as get_code_smells or find_dead_code. There is no statement of when-not-to-use, and no explicit differentiation from sibling analysis tools.

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