Tree-Hugger-JS MCP Server

Server Quality Checklist

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

Latest release: v1.0.0
Disambiguation4/5
Most tools have distinct purposes, such as parse_code for loading code, get_functions for retrieving functions, and rename_identifier for refactoring. However, find_pattern and find_all_pattern overlap significantly in functionality, differing only in returning the first match versus all matches, which could cause confusion in selection. The other tools are well-differentiated, with clear boundaries like analyze_scopes for scope analysis and insert_code for code insertion.
Naming Consistency5/5
All tool names follow a consistent snake_case pattern with clear verb_noun structures, such as parse_code, get_functions, rename_identifier, and remove_unused_imports. There are no deviations in naming conventions, making the set predictable and easy to understand. The naming style is uniform throughout, enhancing readability and usability.
Tool Count5/5
With 12 tools, the count is well-scoped for a JavaScript/TypeScript AST analysis server, covering essential operations like parsing, querying, transforming, and refactoring code. Each tool serves a specific purpose, such as get_imports for dependency analysis and transform_code for complex workflows, without redundancy. The number aligns perfectly with the domain's complexity, providing comprehensive coverage without being overwhelming.
Completeness5/5
The toolset offers complete coverage for AST-based code analysis and manipulation, including parsing (parse_code), querying (e.g., get_functions, get_classes), transformation (e.g., insert_code, rename_identifier), and cleanup (remove_unused_imports). It supports full lifecycle operations from loading code to advanced refactoring with transform_code, leaving no obvious gaps. The domain of code analysis and refactoring is thoroughly addressed with tools for both analysis and modification.
Average 4/5 across 12 of 12 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- Last stable release on June 20, 2025
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior3/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 describes the tool's purpose and use cases but lacks details on behavioral traits like whether it modifies code (likely read-only based on 'analyze'), performance considerations, error handling, or output format. The examples hint at functionality but don't fully compensate for the missing annotations.
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 appropriately sized and front-loaded with a clear purpose statement followed by a bulleted list of examples. Each example earns its place by illustrating specific use cases, though the repetition of 'analyze_scopes()' in each bullet is slightly redundant. Overall, it's efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (advanced code analysis), lack of annotations, and no output schema, the description is moderately complete. It covers purpose and usage well but lacks details on behavioral traits and output format, which are important for an analysis tool. The examples help but don't fully address these gaps, making it adequate but with clear room for improvement.
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% for the single parameter (includeBuiltins), so the schema already documents it thoroughly. The description adds minimal value by mentioning includeBuiltins in one example ('Learning aid'), but doesn't provide additional semantics beyond what the schema states. This meets the baseline of 3 when schema coverage is high.
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 analyzes 'variable scopes, bindings, and potential naming conflicts' for 'code quality analysis', providing a specific verb and resource. However, it doesn't explicitly differentiate from sibling tools like get_functions or get_classes, which might also analyze code structure but with different focuses.
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 provides clear context through six example use cases (e.g., variable shadowing detection, closure analysis, refactoring safety), which implicitly guide when to use this tool. However, it doesn't explicitly state when NOT to use it or name alternatives among sibling tools, such as when to use find_pattern instead for different analysis needs.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It implies the tool performs a read-only search operation, which is consistent with its purpose, but does not disclose potential limitations like performance impacts on large codebases, error handling, or return format details. The examples add some context but lack explicit behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with a clear purpose statement, but the extensive list of examples (9 bullet points) adds redundancy and length without providing new semantic value. While helpful for illustration, it reduces conciseness by not earning its place efficiently beyond the initial guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (pattern matching in code analysis), no annotations, and no output schema, the description is moderately complete. It covers the purpose and usage with examples but lacks details on behavioral aspects like performance, error handling, or return structure, which are important for a tool with potential large-scale operations.
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 schema description coverage is 100%, so the input schema already documents both parameters ('pattern' and 'limit') thoroughly. The description does not add significant meaning beyond the schema, as it repeats pattern examples already in the schema description. Baseline 3 is appropriate since the schema does the heavy lifting.
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 with a specific verb ('Find all nodes') and resource ('matching the specified pattern'), and distinguishes it from siblings like 'find_pattern' by emphasizing 'comprehensive analysis when you need all matches'. This provides immediate clarity on what the tool does and its scope.
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 provides clear context for usage ('Use for comprehensive analysis when you need all matches') and includes practical examples that illustrate when to apply the tool. However, it does not explicitly state when not to use it or name alternatives among siblings, such as 'find_pattern' which might handle partial matches differently.
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 describes what the tool returns (class analysis with methods/properties) and suggests use cases, but doesn't disclose behavioral traits like performance characteristics, rate limits, authentication needs, or what 'comprehensive analysis' entails. The examples provide some behavioral context but not complete 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 well-structured with a clear purpose statement followed by specific examples. Each example earns its place by illustrating different use cases. However, the opening 'Perfect for OOP code review' is somewhat promotional and could be more concise. Overall, it's appropriately sized and front-loaded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description provides good usage context but lacks information about what the analysis output actually contains. For a tool with 2 parameters and no structured output documentation, the description should ideally specify what 'comprehensive method and property analysis' returns (e.g., class names, method signatures, property types, inheritance chains).
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 fully documents both parameters. The description adds value by showing practical examples of parameter usage (e.g., 'Method-only view: get_classes({includeProperties: false})'), but doesn't add semantic meaning beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.
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: 'Get all classes with comprehensive method and property analysis.' It specifies the resource (classes) and the type of analysis (method and property). However, it doesn't explicitly differentiate from sibling tools like 'get_functions' or 'analyze_scopes' beyond mentioning OOP code review context.
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 excellent usage guidance with specific examples for different scenarios: architecture review, API design, inheritance analysis, method-only view, property audit, and testing prep. It explicitly shows when to use parameter variations (includeProperties/includeMethods) for different purposes.
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 discloses that the tool returns metadata (name, type, location, async status) and includes various function types, which adds behavioral context beyond the input schema. However, it doesn't mention potential limitations like performance impacts, output format details, or error handling. The description is helpful but lacks completeness 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.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is appropriately sized and front-loaded with a clear purpose statement, followed by practical examples. Each example sentence earns its place by demonstrating specific use cases. However, the list format with bullet points is slightly verbose compared to a more condensed prose, but it remains efficient and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations, no output schema, and 2 parameters with full schema coverage, the description is moderately complete. It explains the tool's purpose, usage, and parameter implications through examples, but lacks details on output structure, error conditions, or performance considerations. For a read-only tool with simple parameters, this is adequate but has clear gaps in behavioral context.
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 schema description coverage is 100%, so the schema already fully documents the two parameters (includeAnonymous and asyncOnly). The description adds value by providing usage examples that illustrate parameter effects (e.g., using asyncOnly for async analysis, includeAnonymous for focusing on named functions), but doesn't introduce new semantic details beyond what the schema descriptions state. This meets the baseline for high schema coverage.
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 retrieves functions with specific metadata (name, type, location, async status) and includes various function types (class methods, arrow functions, declarations). It distinguishes from siblings like 'get_classes' or 'get_imports' by focusing on functions, but doesn't explicitly contrast with 'find_all_pattern' or 'find_pattern' which might also locate functions. The purpose is specific but sibling differentiation could be more explicit.
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 usage scenarios with examples for code review, async operation analysis, API analysis, test coverage, refactoring prep, and performance audits. It implicitly guides when to use this tool (e.g., for function-level analysis) versus alternatives like 'get_classes' for classes or 'get_imports' for imports, though it doesn't name specific exclusions. The examples effectively illustrate practical contexts.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It adds value by describing 'smart formatting' and 'proper indentation automatically', and the 'preview' parameter hint ('Always preview first!') suggests safety considerations. However, it doesn't cover potential side effects, error handling, or mutation behavior beyond insertion, leaving gaps for a tool that modifies code.
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 appropriately sized and front-loaded with a clear purpose statement, followed by useful examples. However, the examples are extensive (six bullet points), which could be streamlined—some are redundant (e.g., multiple 'after' insertion examples). Overall, it's efficient but slightly verbose in the example section.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of a code modification tool with no annotations and no output schema, the description is moderately complete. It covers the purpose and usage through examples but lacks details on return values, error cases, or integration with sibling tools. For a mutation tool, this leaves the agent with incomplete guidance on behavioral outcomes.
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 schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds minimal semantic context through examples (e.g., showing 'pattern' usage like 'function_declaration'), but doesn't provide additional meaning beyond what's in the schema. This meets 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 purpose with specific verbs ('insert code before or after nodes') and resource ('nodes'), distinguishing it from siblings like 'remove_unused_imports' or 'rename_identifier' by focusing on code insertion rather than analysis or transformation. It emphasizes 'smart formatting' and 'professional-quality code insertion' as key differentiators.
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 provides clear context through examples (e.g., 'Add logging', 'Add validation'), implicitly guiding when to use this tool for inserting code snippets. However, it lacks explicit guidance on when not to use it or alternatives among siblings like 'transform_code' for more complex modifications, which would require the agent to infer based on the examples.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes key behaviors: it renames identifiers intelligently (avoiding strings/comments), supports a preview mode for safety, and applies changes throughout the code. However, it lacks details on permissions needed, error handling, or rate limits, which are important for a mutation tool.
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 appropriately sized and front-loaded with a clear purpose statement, followed by relevant examples that earn their place by illustrating usage scenarios. However, the list of examples is somewhat lengthy and could be more streamlined without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity as a mutation tool with no annotations and no output schema, the description is moderately complete. It covers purpose, usage examples, and key behaviors but lacks details on return values, error conditions, or integration with sibling tools, leaving some gaps for an AI agent to infer.
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 parameters (oldName, newName, preview). The description adds minimal value beyond the schema by mentioning that newName 'should be valid JavaScript identifier' and emphasizing preview for safety, but does not provide additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.
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 with specific verbs ('rename all occurrences of an identifier throughout the code') and distinguishes it from siblings by focusing on identifier renaming rather than analysis, insertion, or transformation. It explicitly mentions what it avoids (renaming in strings/comments), which further clarifies its scope.
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 provides clear context for when to use this tool through multiple examples (e.g., refactoring function names, improving variable names, updating class names, API consistency, legacy code updates). It implicitly suggests usage for code refactoring tasks but does not explicitly state when not to use it or name specific alternatives among siblings.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly indicates this is a read operation for 'detailed AST node information' and 'debugging and precise analysis,' which implies non-destructive behavior. However, it doesn't disclose potential limitations like what happens with invalid positions, error formats, or performance characteristics. The description adds value but doesn't provide comprehensive behavioral context.
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 a clear purpose statement followed by bullet-point examples. Each example sentence earns its place by illustrating different use cases. While slightly verbose due to repeated parameter examples, the structure is effective and front-loaded with the core purpose. No wasted sentences, but could be slightly more concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (position-based AST query), no annotations, and no output schema, the description provides good usage context but lacks details about return values, error conditions, or performance. The examples help compensate, but for a debugging/analysis tool without output schema, more information about what 'detailed AST node information' includes would improve completeness.
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%, providing clear documentation for both parameters (line and column). The description doesn't add significant semantic information beyond what's in the schema, though it reinforces the parameters through repeated examples. With high schema coverage, the baseline score of 3 is appropriate as the schema does the heavy lifting for parameter documentation.
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 with specific verb ('Get detailed AST node information') and resource ('at a specific cursor position'). It distinguishes from siblings by focusing on position-based node retrieval rather than broader analysis (analyze_scopes), pattern matching (find_pattern), or code transformation (transform_code). The title being null doesn't affect this clarity.
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 usage guidance through five concrete examples (debugging syntax errors, understanding code structure, refactoring assistance, IDE integration, pattern development). These examples clearly illustrate when to use this tool versus alternatives like get_classes (for class-level analysis) or transform_code (for modifications). The examples serve as effective when-to-use guidance.
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?
With no annotations provided, the description carries the full burden of behavioral disclosure. It explains that the tool loads code into an 'AST state' and is a prerequisite for other tools, which adds useful context. However, it lacks details on error handling, performance implications, or what happens if called multiple times, leaving some behavioral aspects unclear.
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 and front-loaded with the core purpose and prerequisite note, followed by helpful examples. However, the examples are somewhat lengthy and could be more concise, as they repeat similar use cases, slightly reducing efficiency.
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?
Given the tool's complexity as a prerequisite for analysis, no output schema, and no annotations, the description is mostly complete. It covers purpose, usage, and provides examples, but lacks details on return values or error handling, which would enhance completeness for a foundational tool.
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 parameters thoroughly. The description adds minimal value beyond the schema, as it doesn't explain parameter interactions or provide additional semantics. The examples illustrate usage but don't enhance parameter understanding beyond what's in the 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's purpose: 'Parse JavaScript/TypeScript code from file or string and load it into the AST state.' It specifies the verb (parse), resource (JavaScript/TypeScript code), and distinguishes it from siblings by noting it 'must be called before using other analysis tools,' establishing its foundational role in the workflow.
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 usage guidance: 'Must be called before using other analysis tools.' It distinguishes this tool from siblings by positioning it as a prerequisite for tools like get_functions or analyze_scopes, and the examples illustrate when to use it (e.g., for parsing files or strings, with explicit language settings).
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 tool returns the 'first' match (important behavioral trait) and uses 'tree-hugger-js intuitive syntax,' but lacks details on error handling, performance, or output format. For a search tool with no annotations, this is adequate but leaves gaps in behavioral context.
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: it starts with the core purpose, provides usage guidance, and follows with relevant examples. Every sentence adds value, though the example list is lengthy; it could be more concise by summarizing syntax patterns instead of listing many specific cases.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no annotations and no output schema, the description covers purpose and usage well but lacks details on return values, error conditions, or limitations. For a pattern-matching tool with one parameter, it's minimally viable but incomplete for full agent understanding.
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 providing 7 concrete examples (e.g., 'Find main function: find_pattern('function[name="main"]')') that illustrate pattern syntax and use cases, enhancing understanding beyond the schema's generic description.
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 first node matching the specified pattern using tree-hugger-js intuitive syntax.' It specifies the verb ('find'), resource ('first node'), and method ('using tree-hugger-js intuitive syntax'), distinguishing it from siblings like find_all_pattern (which finds all matches) and other analysis tools.
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 explicitly states when to use this tool: 'Use for targeted searches when you need one specific match.' It distinguishes it from find_all_pattern (implied alternative for multiple matches) and other siblings like get_functions or get_classes (which retrieve broader categories without pattern matching).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden of behavioral disclosure. It effectively describes the tool's purpose and use cases, though it doesn't explicitly mention performance characteristics, rate limits, or authentication requirements. The examples provide good context about what kind of analysis the tool enables.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is front-loaded with the core purpose statement, but the extensive examples section (6 bullet points) adds significant length. While the examples are helpful for usage guidelines, they make the description less concise than ideal. Each example earns its place by illustrating different use cases.
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 single-parameter tool with no annotations and no output schema, the description provides substantial context through purpose statement and detailed examples. It adequately explains what the tool does and when to use it, though it doesn't describe the return format or structure of the import data.
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 fully documents the single parameter. The description adds minimal parameter-specific information beyond what's in the schema (only mentioning includeTypeImports in one example). This meets the baseline expectation when schema coverage is complete.
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 with specific verb ('Get') and resource ('all import statements with detailed module and specifier information'). It distinguishes from siblings like 'remove_unused_imports' or 'parse_code' by focusing specifically on import analysis rather than modification or general parsing.
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 usage scenarios through six detailed examples (dependency audit, bundle analysis, security audit, TypeScript analysis, refactoring prep, license compliance), clearly indicating when to use this tool. It also distinguishes from alternatives by showing how parameter configuration (includeTypeImports) enables specific use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by stating the tool 'automatically' removes imports and 'safely detects' which are used. It also explains the preview parameter behavior. However, it doesn't mention potential side effects like breaking code if detection fails or whether changes are reversible.
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 appropriately sized with a clear purpose statement followed by six bullet-point examples. Every sentence earns its place by providing concrete usage scenarios. It could be slightly more front-loaded by moving the examples after the core description.
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 one parameter, 100% schema coverage, and no output schema, the description is quite complete. It explains what the tool does, when to use it, and provides examples. The main gap is lack of output format information, but given the simplicity of the tool, this is acceptable.
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% with one parameter documented in the schema. The description adds value by explaining the preview parameter's purpose in the examples ('to see what will be removed'), providing practical context beyond the schema's technical description.
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 with specific verb ('remove') and resource ('unused import statements'), plus the method ('automatically' and 'safely detects'). It distinguishes from siblings like get_imports (which lists imports) and transform_code (which is more general) by focusing specifically on removal of unused imports.
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 usage scenarios with six concrete examples (e.g., bundle size optimization, code cleanup, linting compliance), giving clear guidance on when to use this tool. It also distinguishes from alternatives by focusing on import removal rather than analysis or other transformations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden and does well by explaining key behavioral traits: it handles multiple transformations in sequence (implied order matters), supports preview mode for safety, and includes concrete examples of destructive operations like renaming and replacing. However, it doesn't explicitly mention error handling, rollback capabilities, or performance implications.
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 a clear purpose statement followed by practical examples, making it front-loaded and informative. However, it could be more concise by integrating the 'preview' advice into the main text rather than relying on the schema, and the examples are lengthy but necessary for clarity.
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?
Given the tool's complexity (batch transformations, no output schema, no annotations), the description is mostly complete: it explains purpose, usage, and provides examples. Gaps include lack of output format details, error handling, and explicit prerequisites (e.g., code must be parsed first). The examples compensate well for the missing output schema.
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 significant value by providing five detailed examples that illustrate how to structure the 'operations' array with different 'type' and 'parameters' combinations, clarifying semantics beyond the schema's enum and descriptions. It doesn't explain the 'preview' parameter beyond what the schema states.
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: 'Apply multiple transformations in a single operation' with the specific context of 'complex refactoring workflows.' It distinguishes itself from sibling tools like rename_identifier and remove_unused_imports by emphasizing batch processing capabilities rather than single operations.
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 guidance on when to use this tool: for 'complex refactoring workflows' and 'most powerful tool for complex refactoring.' It implicitly suggests alternatives through sibling tool names (e.g., use rename_identifier for single renames), and the input schema reinforces this with 'Use preview:true first!' for safety.
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:

[![tree-hugger-js-mcp MCP server](https://glama.ai/mcp/servers/qckfx/tree-hugger-js-mcp/badges/card.svg)](https://glama.ai/mcp/servers/qckfx/tree-hugger-js-mcp)

Score Badge

Copy to your README.md:

[![tree-hugger-js-mcp MCP server](https://glama.ai/mcp/servers/qckfx/tree-hugger-js-mcp/badges/score.svg)](https://glama.ai/mcp/servers/qckfx/tree-hugger-js-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/qckfx/tree-hugger-js-mcp'

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