The Tree-Hugger-JS MCP Server is a powerful tool for JavaScript/TypeScript code analysis and transformation, enabling developers to understand, refactor, and improve their code efficiently. It allows you to:
Parse and analyze JavaScript, TypeScript, JSX, and TSX files or code strings
Find code patterns using intuitive CSS-like selectors (e.g., function[name="main"])
Extract metadata about functions, classes, and import statements
Navigate the AST (Abstract Syntax Tree) to analyze code structure
Analyze variable scopes and bindings for enhanced code intelligence
Transform code through:
Renaming identifiers consistently throughout the codebase
Removing unused import statements
Inserting code before/after specific patterns
Chaining multiple transformations
Preview changes before applying them and access transformation history
Provides powerful code analysis and transformation capabilities for JavaScript, enabling parsing, pattern matching, and manipulation of JavaScript code structure
Supports analysis of JSX elements and React components, with pattern matching capabilities specifically designed for React code structures
Enables analysis and transformation of TypeScript code, including handling of TypeScript-specific features like type imports
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Tree-Hugger-JS MCP Server find all async functions in this file"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
An MCP (Model Context Protocol) server that provides AI agents with powerful JavaScript/TypeScript code analysis and transformation capabilities using the tree-hugger-js library.
Parse JavaScript, TypeScript, JSX, and TSX files or code strings
Find patterns using intuitive syntax (e.g., function, class[name="MyClass"])
Extract functions, classes, imports with detailed metadata
Navigate AST nodes and analyze code structure
Get nodes at specific positions
Rename identifiers throughout code
Remove unused imports
Chain multiple transformations
Insert code before/after patterns
Preview transformations before applying
Scope analysis and variable binding
Pattern matching with CSS-like selectors
Support for async functions, classes, methods
TypeScript type import handling
Related MCP server: @aiready/ast-mcp-server
Try immediately with npx - no installation required:
# Use with Claude Code or any MCP client
npx tree-hugger-js-mcp# Install globally for repeated use
npm install -g tree-hugger-js-mcp
# Then run anywhere
tree-hugger-js-mcp# Clone and build from source
git clone https://github.com/qckfx/tree-hugger-js-mcp.git
cd tree-hugger-js-mcp
npm install
npm run build
npm startAdd to your MCP client configuration:
{
"mcpServers": {
"tree-hugger-js": {
"command": "npx",
"args": ["tree-hugger-js-mcp"]
}
}
}{
"mcpServers": {
"tree-hugger-js": {
// If installed globally
"command": "tree-hugger-js-mcp"
// Or if built from source
"command": "node",
"args": ["/path/to/tree-hugger-js-mcp/build/index.js"]
}
}
}parse_codeParse JavaScript/TypeScript code from file or string.
Parameters:
source (string): File path or code string to parse
isFilePath (boolean, optional): Whether source is a file path (auto-detected if not provided)
language (string, optional): Language to use (javascript, typescript, jsx, tsx)
Example:
// Parse a file
await callTool("parse_code", {
source: "./src/app.js",
isFilePath: true
});
// Parse code string
await callTool("parse_code", {
source: "function hello() { console.log('world'); }"
});find_patternFind first node matching a pattern.
Parameters:
pattern (string): Pattern to match using tree-hugger-js syntax
Examples:
// Find any function
await callTool("find_pattern", { pattern: "function" });
// Find async functions
await callTool("find_pattern", { pattern: "function[async]" });
// Find class by name
await callTool("find_pattern", { pattern: "class[name='MyClass']" });find_all_patternFind all nodes matching a pattern.
Parameters:
pattern (string): Pattern to match
limit (number, optional): Maximum matches to return
get_functionsGet all functions with details.
Parameters:
includeAnonymous (boolean, optional): Include anonymous functions (default: true)
asyncOnly (boolean, optional): Only return async functions (default: false)
get_classesGet all classes with methods and properties.
Parameters:
includeProperties (boolean, optional): Include class properties (default: true)
includeMethods (boolean, optional): Include class methods (default: true)
get_importsGet all import statements.
Parameters:
includeTypeImports (boolean, optional): Include TypeScript type-only imports (default: true)
rename_identifierRename all occurrences of an identifier.
Parameters:
oldName (string): Current identifier name
newName (string): New identifier name
preview (boolean, optional): Return preview only (default: false)
Example:
await callTool("rename_identifier", {
oldName: "fetchData",
newName: "fetchUserData",
preview: true
});remove_unused_importsRemove unused import statements.
Parameters:
preview (boolean, optional): Return preview only (default: false)
transform_codeApply multiple transformations in sequence.
Parameters:
operations (array): Array of transformation operations
preview (boolean, optional): Return preview only (default: false)
Example:
await callTool("transform_code", {
operations: [
{ type: "rename", parameters: { oldName: "oldFunc", newName: "newFunc" } },
{ type: "removeUnusedImports" },
{ type: "replaceIn", parameters: { nodeType: "string", pattern: /localhost/g, replacement: "api.example.com" } }
],
preview: true
});insert_codeInsert code before or after nodes matching a pattern.
Parameters:
pattern (string): Pattern to match for insertion points
code (string): Code to insert
position (string): "before" or "after"
preview (boolean, optional): Return preview only (default: false)
get_node_at_positionGet AST node at specific line and column.
Parameters:
line (number): Line number (1-based)
column (number): Column number (0-based)
analyze_scopesAnalyze variable scopes and bindings.
Parameters:
includeBuiltins (boolean, optional): Include built-in identifiers (default: false)
The server provides three resources for accessing internal state:
ast://currentCurrent parsed AST state with metadata and statistics.
ast://analysisResults from the most recent code analysis (functions, classes, imports).
ast://transformsHistory of code transformations and available operations.
Tree-hugger-js uses intuitive patterns instead of verbose tree-sitter node types:
function - Any function (declaration, expression, arrow, method)
class - Class declarations and expressions
string - String and template literals
import/export - Import/export statements
call - Function calls
loop - For, while, do-while loops
[name="foo"] - Nodes with specific name
[async] - Async functions
[text*="test"] - Nodes containing text
class method - Methods inside classes
function > return - Return statements directly in functions
:has() and :not() pseudo-selectors
// Parse and analyze a React component
await callTool("parse_code", { source: "./components/UserProfile.jsx" });
// Get all functions
const functions = await callTool("get_functions", { asyncOnly: true });
// Find JSX elements
const jsxElements = await callTool("find_all_pattern", { pattern: "jsx" });// Rename a function and remove unused imports
await callTool("transform_code", {
operations: [
{ type: "rename", parameters: { oldName: "getUserData", newName: "fetchUserProfile" } },
{ type: "removeUnusedImports" }
]
});// Find all async functions that call console.log
await callTool("find_all_pattern", {
pattern: "function[async]:has(call[text*='console.log'])"
});
// Find classes with constructor methods
await callTool("find_all_pattern", {
pattern: "class:has(method[name='constructor'])"
});# Install dependencies
npm install
# Build the project
npm run build
# Watch mode for development
npm run dev
# Test with MCP inspector
npm run inspectorThe server provides detailed error messages and suggestions:
File not found errors for invalid file paths
Parse errors with helpful context
Pattern matching errors with suggestions
Transformation errors with rollback capability
MIT
Analyze variable scopes, bindings, and potential naming conflicts. Advanced tool for code quality analysis.
Examples: β’ Variable shadowing detection: analyze_scopes() to find naming conflicts β’ Closure analysis: analyze_scopes() to understand variable capture β’ Refactoring safety: analyze_scopes() before variable renames β’ Code review: analyze_scopes() to identify scope-related issues β’ Learning aid: analyze_scopes({includeBuiltins: true}) to see all identifiers β’ Dead code detection: analyze_scopes() to find unused variables
| Name | Required | Description | Default |
|---|---|---|---|
| includeBuiltins | No | Include built-in identifiers (default: false). Set true for comprehensive analysis including globals. |
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.
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.
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.
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.
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.
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.
Find all nodes matching the specified pattern. Use for comprehensive analysis when you need all matches.
Examples: β’ Audit all functions: find_all_pattern('function') β’ Find all TODO comments: find_all_pattern('comment[text*="TODO"]') β’ Security audit: find_all_pattern('call[text*="eval"]') β’ Performance review: find_all_pattern('call[text*="console.log"]') to find debug logs β’ API usage: find_all_pattern('call[text*="fetch"]') to find all API calls β’ React hooks: find_all_pattern('call[text*="use"]') for hooks usage β’ Error patterns: find_all_pattern('string[text*="error"]') for error messages β’ Database queries: find_all_pattern('string[text*="SELECT"]') for SQL β’ Event handlers: find_all_pattern('function[text*="onClick"]')
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Pattern to match: 'function', 'call[text*="console.log"]', 'string[text*="TODO"]' | |
| limit | No | Maximum number of matches to return (default: no limit). Use for large codebases. |
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.
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.
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.
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.
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.
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.
Find first node matching the specified pattern using tree-hugger-js intuitive syntax. Use for targeted searches when you need one specific match.
Examples: β’ Find main function: find_pattern('function[name="main"]') β’ Find React component: find_pattern('function[name="UserProfile"]') β’ Find async functions: find_pattern('function[async]') β’ Find specific class: find_pattern('class[name="UserManager"]') β’ Find error handling: find_pattern('call[text*="catch"]') β’ Find JSX with props: find_pattern('jsx:has(jsx-attribute[name="className"])') β’ Debug specific calls: find_pattern('call[text*="console.log"]')
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Pattern using intuitive syntax: 'function', 'class[name="MyClass"]', 'function[async]', 'call[text*="fetch"]' |
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.
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.
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.
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.
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.
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.
Get all classes with comprehensive method and property analysis. Perfect for OOP code review.
Examples: β’ Architecture review: get_classes() to understand class structure β’ API design: get_classes() to see public method interfaces β’ Inheritance analysis: get_classes() to identify class hierarchies β’ Method-only view: get_classes({includeProperties: false}) to focus on behavior β’ Property audit: get_classes({includeMethods: false}) to review state management β’ Testing prep: get_classes() to identify methods needing unit tests
| Name | Required | Description | Default |
|---|---|---|---|
| includeProperties | No | Include class properties (default: true). Set false to focus only on methods. | |
| includeMethods | No | Include class methods (default: true). Set false to focus only on properties. |
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.
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.
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.
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.
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.
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.
Get all functions with metadata including name, type, location, and async status. Includes class methods, arrow functions, and declarations.
Examples: β’ Code review: get_functions() to see all functions in a file β’ Find async operations: get_functions({asyncOnly: true}) β’ API analysis: get_functions() then look for functions with 'fetch' or 'api' in names β’ Test coverage: get_functions() to identify functions needing tests β’ Refactoring prep: get_functions({includeAnonymous: false}) to focus on named functions β’ Performance audit: get_functions() to find large/complex functions by line count
| Name | Required | Description | Default |
|---|---|---|---|
| includeAnonymous | No | Include anonymous functions (default: true). Set false to focus on named functions only. | |
| asyncOnly | No | Only return async functions (default: false). Use for async/await pattern analysis. |
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.
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.
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.
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.
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.
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.
Get all import statements with detailed module and specifier information. Essential for dependency analysis.
Examples: β’ Dependency audit: get_imports() to see all external dependencies β’ Bundle analysis: get_imports() to identify heavy imports β’ Security audit: get_imports() to check for suspicious packages β’ TypeScript analysis: get_imports({includeTypeImports: false}) to focus on runtime imports β’ Refactoring prep: get_imports() to understand module structure before changes β’ License compliance: get_imports() to generate dependency list
| Name | Required | Description | Default |
|---|---|---|---|
| includeTypeImports | No | Include TypeScript type-only imports (default: true). Set false for runtime dependency analysis. |
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.
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.
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.
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.
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.
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.
Get detailed AST node information at a specific cursor position. Perfect for debugging and precise analysis.
Examples: β’ Debug syntax errors: get_node_at_position(15, 23) to understand what's at error location β’ Understand code structure: get_node_at_position(line, col) to see AST node type at cursor β’ Refactoring assistance: get_node_at_position(line, col) to identify exact node before transformation β’ IDE integration: get_node_at_position(line, col) for hover information β’ Pattern development: get_node_at_position(line, col) to understand node structure for pattern writing
| Name | Required | Description | Default |
|---|---|---|---|
| line | Yes | Line number (1-based) - the line where cursor is positioned | |
| column | Yes | Column number (0-based) - the character position within the line |
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.
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.
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.
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.
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.
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.
Insert code before or after nodes with smart formatting. Professional-quality code insertion with proper indentation.
Examples: β’ Add logging: insert_code('function_declaration', 'console.log("Function started");', 'after') β’ Add validation: insert_code('method_definition[name="save"]', 'if (!this.isValid()) return;', 'after') β’ Add comments: insert_code('class_declaration', '// Main user management class', 'before') β’ Add error handling: insert_code('function[async]', 'try {', 'after') + insert_code('function[async]', '} catch(e) { console.error(e); }', 'after') β’ Add metrics: insert_code('function[name*="api"]', 'performance.mark("api-start");', 'after') β’ Debug mode: insert_code('call[text*="fetch"]', 'console.log("API call:", url);', 'before')
| Name | Required | Description | Default |
|---|---|---|---|
| pattern | Yes | Pattern to match: 'function_declaration', 'class[name="MyClass"]', 'method_definition[async]' | |
| code | Yes | Code to insert. Will be formatted with proper indentation automatically. | |
| position | Yes | Insert position: 'before' (above) or 'after' (below) the matched nodes | |
| preview | No | Return preview only without applying changes (default: false). Always preview first! |
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.
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.
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.
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.
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.
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.
Parse JavaScript/TypeScript code from file or string and load it into the AST state. Must be called before using other analysis tools.
Examples: β’ Parse a React component: parse_code('./src/UserProfile.jsx') β’ Parse code string: parse_code('function hello() { return "world"; }') β’ Parse with explicit language: parse_code('./config.js', language='javascript') β’ Analyze legacy code: parse_code('./old-script.js') then use other tools to understand structure β’ Code review prep: parse_code('./feature.ts') then get_functions() to review all functions
| Name | Required | Description | Default |
|---|---|---|---|
| source | Yes | File path (./src/app.js) or code string ('const x = 1;') | |
| isFilePath | No | Whether source is a file path (true) or code string (false). Defaults to auto-detect. | |
| language | No | Language to use (javascript, typescript, jsx, tsx). Auto-detected if not provided. |
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.
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.
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.
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.
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.
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.
Automatically remove unused import statements to clean up code. Safely detects which imports are actually used.
Examples: β’ Bundle size optimization: remove_unused_imports() to reduce bundle size β’ Code cleanup: remove_unused_imports() after refactoring β’ Linting compliance: remove_unused_imports() to fix ESLint warnings β’ Before deployment: remove_unused_imports({preview: true}) to see what will be removed β’ Legacy cleanup: remove_unused_imports() after removing old code β’ Development workflow: remove_unused_imports() during feature development
| Name | Required | Description | Default |
|---|---|---|---|
| preview | No | Return preview only without applying changes (default: false). Use to see what will be removed. |
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.
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.
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.
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.
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.
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.
Intelligently rename all occurrences of an identifier throughout the code. Avoids renaming in strings/comments.
Examples: β’ Refactor function names: rename_identifier('fetchData', 'fetchUserData') β’ Improve variable names: rename_identifier('data', 'userData') β’ Update class names: rename_identifier('Manager', 'UserManager') β’ API consistency: rename_identifier('getUserInfo', 'fetchUserInfo') β’ Preview first: rename_identifier('oldName', 'newName', {preview: true}) β’ Legacy code update: rename_identifier('XMLHttpRequest', 'fetch')
| Name | Required | Description | Default |
|---|---|---|---|
| oldName | Yes | Current identifier name to find and replace | |
| newName | Yes | New identifier name (should be valid JavaScript identifier) | |
| preview | No | Return preview only without applying changes (default: false). Always preview first for safety. |
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.
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.
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.
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.
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.
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.
Apply multiple transformations in a single operation. Most powerful tool for complex refactoring workflows.
Examples: β’ API refactor: [{type: 'rename', parameters: {oldName: 'getData', newName: 'fetchData'}}, {type: 'removeUnusedImports'}] β’ Environment update: [{type: 'replaceIn', parameters: {nodeType: 'string', pattern: /localhost/g, replacement: 'api.production.com'}}, {type: 'removeUnusedImports'}] β’ Add logging: [{type: 'insertAfter', parameters: {pattern: 'function_declaration', text: 'console.log("Function called");'}}, {type: 'removeUnusedImports'}] β’ Bulk rename: [{type: 'rename', parameters: {oldName: 'user', newName: 'customer'}}, {type: 'rename', parameters: {oldName: 'id', newName: 'customerId'}}] β’ Legacy migration: [{type: 'replaceIn', parameters: {nodeType: 'call_expression', pattern: /XMLHttpRequest/g, replacement: 'fetch'}}, {type: 'removeUnusedImports'}]
| Name | Required | Description | Default |
|---|---|---|---|
| operations | Yes | Array of transformation operations applied in sequence. Use preview:true first! | |
| preview | No | Return preview only without applying changes (default: false). ALWAYS preview complex transformations first. |
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.
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.
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.
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.
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.
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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
analyze_scopesfind_all_patternfind_patternget_classesget_functionsget_importsget_node_at_positioninsert_codeparse_coderemove_unused_importsrename_identifiertransform_codeMost 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.
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.
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.
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.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence platform for AI agents. 20 tools for architecture, security & impact analysis.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Codebase intelligence for agents: 152 structured artifacts across 21 programs, one call.
Shared memory for coding agents. Stop re-explaining your codebase every session.
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
