Scopewalker MCP

by timohaa

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.5
Disambiguation4/5
Each tool targets a distinct analysis dimension (line counts, smells, functions, thresholds, inventory, complexity, docs, prop drilling), but get_functions and get_code_inventory both report function info, and check_thresholds overlaps with line counts. Descriptions clarify boundaries, so ambiguity is low.
Naming Consistency4/5
Seven of eight tools follow the get_ noun pattern (get_line_counts, get_functions, etc.), but check_thresholds breaks the pattern by omitting 'get'. This is a minor deviation; the overall naming is readable and predictable.
Tool Count5/5
With 8 tools, the set is well-scoped for a code analysis server. Each tool serves a clear purpose without unnecessary bloat, fitting comfortably within the ideal 3-15 range.
Completeness4/5
The set covers core static analysis needs: size, complexity, smells, documentation, and structural inventory. Minor gaps like dependency analysis are absent, but the surface is coherent for code quality assessment and likely covers most agent workflows.
Average 3.3/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 70 commits in the last 12 weeks
- Last stable release on August 9, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 'Finds' implies a read-only operation, but it does not disclose important traits such as default threshold values, recursion behavior, or return format. For a tool with 9 parameters, this is insufficient transparency.
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 concise, with two short sentences that front-load the primary purpose. The second sentence provides a useful hint about the limit parameter without unnecessary verbosity. While it lacks a structured layout, it is appropriately sized for a straightforward tool.
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?
Given the tool's complexity (9 parameters, no annotations, no output schema), the description is incomplete. It does not explain how size thresholds are set (e.g., whether defaults exist for max_file_lines and max_function_lines), what the return structure is, or what path types are accepted. An agent would need more information to invoke the tool correctly in many scenarios.
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 coverage is 100%, so the baseline is 3 because every parameter has a description. The tool description adds a small clarification for 'limit' ('Use limit to control output'), but it does not meaningfully explain the other parameters beyond the schema's terse labels. This meets but does not exceed the baseline.
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 uses a specific verb 'Finds' and identifies the resource as 'files/functions exceeding size thresholds,' clearly indicating the tool's purpose. It distinguishes from siblings like get_line_counts and get_functions by focusing on threshold violations rather than raw data extraction. However, it does not explicitly contrast with alternatives, so it stops 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?
The description provides no guidance on when to use this tool versus sibling tools. The only usage hint is 'Use limit to control output,' which addresses parameter usage, not tool selection. No exclusions or alternative tool recommendations are present.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full behavioral burden. It only discloses that outputs are line counts, but says nothing about default behavior (e.g., recursion, hidden file handling, pagination, or what errors occur). This is insufficient for a tool with 7 parameters.
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?
The description is two sentences with zero waste. It front-loads the core purpose immediately and adds one practical tip. Extremely concise and readable.
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 7 parameters, no output schema, and no annotations. A two-sentence description is inadequate to explain parameter interactions, return format, or how this tool fits with siblings. It leaves the agent to infer too much from the schema alone.
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 coverage is 100%, so the baseline is 3. The description mentions extensions filtering, which slightly reinforces the schema but adds no new meaning. It does not need to compensate, so a 3 is appropriate.
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 returns file line counts with categorized breakdown (code/blank/comment), using a specific verb ('Returns') and resource ('file line counts'). It differentiates from sibling tools which focus on functions, smells, complexity, etc., though it does not explicitly name 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 only guidance is 'Use extensions to filter,' which is a parameter tip rather than a usage context. There is no statement of when to prefer this tool over alternatives like get_code_inventory or get_complexity_metrics, nor any exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It only states what is found, but does not describe return format, scanning behavior (e.g., recursive traversal, respect for ignore_patterns, include_hidden), or any side effects. Since there is no output schema, this is a significant gap.
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?
The description is a single, focused sentence. It is concise, front-loaded with the action, and contains no unnecessary words. Every part contributes to the purpose.
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 9 parameters, no output schema, and no annotations, yet the description only states the purpose. It does not clarify what the result looks like (e.g., a list of matches with file paths), how limits and depth affect scanning, or what 'include_text' returns. This makes the description incomplete for the tool's complexity.
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% with each parameter having a basic description. The tool description adds minimal value by referencing specific smell types that map to the 'types' parameter, but it does not explain parameter syntax or behavior beyond what the schema already provides. This aligns with the baseline for high schema coverage.
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 exactly what the tool does: it finds TODO/FIXME/HACK/BUG markers and unsafe casts. The verb 'Finds' is specific, the resource (code smells) is clear, and listing marker types distinguishes it from siblings like get_line_counts or get_functions.
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 explicit guidance on when to use this tool versus alternatives. The sibling tools are different in purpose, but the description does not mention alternatives or exclusion criteria. Usage is only implied by the tool's name and description, not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full responsibility for disclosing behavior. 'Returns' implies a read operation, but there is no mention of performance implications, path handling, recursion limits, or any side effects. The note about limit/summary_only hints at potentially large outputs but does not explain behavior in depth.
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?
The description is exactly two sentences, front-loaded with the primary purpose, and avoids redundancy. Every word contributes meaning, and the structure is clear and scannable.
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?
For a tool with 8 parameters, no annotations, and no output schema, this description is under-specified. It does not explain the return format, how metrics are computed, or how parameters like max_depth and max_files interact. The description is not sufficient for an agent to fully understand the tool's behavior and output.
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?
All 8 parameters are described in the schema (100% coverage), so the baseline is 3. The description adds minor value by explaining that limit and summary_only control output, but it does not elaborate on the meaning of other parameters like max_depth or ignore_patterns beyond their schema 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 states a specific verb ('Returns'), a clear resource (complexity metrics), and elaborates with concrete metric types (nesting, params, cognitive). This distinguishes it from sibling tools like get_line_counts or get_code_smells, which target different metrics.
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?
No guidance is provided on when to use this tool versus alternatives. The only usage hint ('Use limit/summary_only to control output') addresses output control, not selection criteria. Sibling tools such as get_code_smells or check_thresholds are not mentioned or contrasted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must convey all behavioral context. It only states that it finds undocumented items and that limit/summary_only affect output; it does not disclose whether the operation is read-only, how traversal works, or any side effects, leaving significant behavioral ambiguity.
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?
The description is two sentences long, directly states the purpose in the first sentence, and uses the second to provide a practical tip about output control. There is no redundant or unnecessary wording.
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 9 parameters and no output schema, the description is too sparse to fully contextualize the tool. It does not explain what 'documentation coverage' means, what the return structure looks like, or how parameters like max_depth, extensions, and ignore_patterns affect behavior, making it difficult for an agent to anticipate results.
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?
The input schema describes all 9 parameters (100% coverage), so the baseline is 3. The description adds minimal nuance by highlighting limit and summary_only as output controls, but it does not elaborate on the purpose or interaction of other parameters, so it does not exceed the baseline.
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 a specific action and resource: 'Finds undocumented functions/classes.' This distinguishes it from sibling tools like get_functions (which likely lists all functions) and get_code_smells (which finds code smells), so it meets the highest bar for purpose clarity.
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 only usage guidance is 'Use limit/summary_only to control output,' which addresses output size, not when to select this tool over alternatives. No mention of use cases, prerequisites, or exclusions is provided, leaving the agent without guidance on tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. The description only says 'Returns function/method info' and hints at a detail mode, but does not mention whether this is a read-only operation, any performance implications, how it handles hidden files, ignore patterns, or the structure of the returned data. This is a significant gap for a tool with no annotations.
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?
The description is two sentences long and front-loaded with the core purpose. Every word earns its place, with the first sentence stating what the tool does and the second providing a practical usage tip. It avoids unnecessary verbosity or repetition of schema information.
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 11 parameters and no output schema, but the description is extremely thin. It does not explain the return format, when to use the many filter/sort parameters, or how it relates to siblings like get_line_counts. While the schema covers parameter semantics, the description leaves the agent with limited context about the tool's overall behavior and output, making it incomplete for a tool of this complexity.
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 baseline is 3. The description adds a small but useful semantic hint for the 'detail' parameter (detail=lines produces line counts per function), but does not elaborate on other parameters. This matches the baseline with marginal added value.
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 'Returns function/method info', which is a specific verb+resource. It also adds a usage hint about detail=lines, which helps clarify the tool's capability. However, it does not explicitly distinguish from sibling tools like get_line_counts, which may also return line counts, so it's not 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 Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides one concrete usage guideline: 'Use detail=lines for line counts per function.' This implies when the detail option is useful, but it does not mention when to prefer this tool over alternatives, nor any exclusions. The context is clear for this specific parameter, but overall guidance is minimal.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility for behavioral disclosure. It does not explain scanning behavior, depth limits, or the meaning of 'extensions to filter.' It only states the output categories, leaving significant behavioral traits (e.g., recursion, handling of hidden files) undisclosed.
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?
The description is two short sentences with no redundant phrasing. Every word contributes meaning: the first sentence defines the tool's purpose, and the second highlights a key filtering capability. This is appropriately sized for a tool with a self-explanatory name.
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 9 parameters and no output schema, the description is too sparse. It does not clarify how filters like grep, ignore_patterns, or include_hidden affect results, nor does it describe the output format or return structure. The tool appears to inventory code symbols, but the description leaves critical context around constraints and defaults ambiguous.
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 documents all 9 parameters. The description adds a small hint about the 'extensions' parameter ('Use extensions to filter') but does not add meaning beyond the schema's existing descriptions. This aligns with the baseline for high schema coverage.
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 function: 'Lists classes, functions, methods, and exports.' It uses a specific verb and resource, and the mention of multiple symbol types distinguishes it from sibling get_functions, which likely focuses only on functions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Use extensions to filter' provides a clear usage context, but it does not explicitly state when to prefer this tool over siblings like get_functions or get_complexity_metrics. There are no exclusions or alternative recommendations, so guidance is implied rather than explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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 explains the detection method and offers output control hints, but it does not disclose return format, scanning behavior, or potential side effects. This is moderate transparency.
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?
The description is two sentences, front-loaded with the purpose and followed by a concise usage hint. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 10 parameters and no output schema, the description provides a clear core purpose and a key control hint. However, it leaves out details about return values and parameter interplay beyond the schema. It is reasonably complete but not exhaustive.
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 description coverage is 100%, so the baseline is 3. The description adds value by highlighting limit and summary_only as output control parameters, which helps an agent select them appropriately. This goes slightly beyond the individual schema 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 clearly states the tool detects parameter threading (prop drilling) by finding parameter names passed through function chains. This is a specific verb and resource, and it clearly distinguishes this tool from siblings like get_functions or get_complexity_metrics.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context on the tool's purpose and advises using limit/summary_only to control output. It does not explicitly mention alternatives, but the unique focus on prop drilling makes its use case obvious among the sibling detection tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![scopewalker-mcp MCP server](https://glama.ai/mcp/servers/timohaa/scopewalker-mcp/badges/card.svg)](https://glama.ai/mcp/servers/timohaa/scopewalker-mcp)

Score Badge

Copy to your README.md:

[![scopewalker-mcp MCP server](https://glama.ai/mcp/servers/timohaa/scopewalker-mcp/badges/score.svg)](https://glama.ai/mcp/servers/timohaa/scopewalker-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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/timohaa/scopewalker-mcp'

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