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., "@tsx-query Find Button components with inline onClick handlers"
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.
Semantic React/TSX analysis MCP server for AI coding assistants.
Save 70-90% tokens compared to grep + file reads.
LLMs waste tokens on grep + file reads. tsx-query uses semantic AST analysis to return precisely what you need.
Query | grep + read | tsx-query | Savings |
Find Button usages | ~15,000 tokens | ~800 tokens | 95% |
Trace prop flow (5 levels) | ~75,000 tokens | ~3,000 tokens | 96% |
Find all setState calls | ~30,000 tokens | ~1,500 tokens | 95% |
Analyze re-render triggers | ~40,000 tokens | ~2,000 tokens | 95% |
Related MCP server: Component Library MCP
npm install -g @paramhq/tsx-queryclaude mcp add tsx-query -- npx -y @paramhq/tsx-queryOr manually add to your MCP config (~/.claude/mcp.json or project .mcp.json):
{
"mcpServers": {
"tsx-query": {
"command": "npx",
"args": ["-y", "@paramhq/tsx-query"]
}
}
}{
"command": "npx",
"args": ["-y", "@paramhq/tsx-query"]
}git clone https://github.com/paramhq/tsx-query.git
cd tsx-query
npm install
npm run build
npm run mcpFind all JSX usages of a component with powerful filtering.
{
"projectPath": "/path/to/project",
"componentName": "Button",
"withProp": "onClick",
"hasInlineHandler": true
}Filters:
withProp / withoutProp - Filter by prop existence
withPropValue - Filter by prop value (exact or regex)
hasInlineHandler - Find inline arrow handlers
hasSpreadProps - Find spread props usage
onlyConditional - Only conditional renders
Returns: File locations, props with values, parent component, code snippets.
Trace a prop through the component hierarchy. Replaces reading 5-10 files manually.
{
"projectPath": "/path/to/project",
"propName": "userId",
"startFile": "src/components/UserDetails.tsx",
"direction": "up"
}Returns: Complete prop path through components with transformations (renamed, destructured, spread).
Find all locations that update a state variable. Understand state flow without reading handlers.
{
"projectPath": "/path/to/project",
"filePath": "src/components/UserForm.tsx",
"stateName": "formData"
}Returns: All setState calls with context (handler, useEffect, inline), trigger events, async/conditional flags.
Analyze what causes a component to re-render with optimization suggestions.
{
"projectPath": "/path/to/project",
"filePath": "src/components/UserProfile.tsx",
"componentName": "UserProfile"
}Returns: Props, state, context, hooks that trigger renders + memoization status + suggestions.
Analyze import/export relationships with cached import graph.
{
"projectPath": "/path/to/project",
"filePath": "src/components/Button/index.ts",
"direction": "importedBy"
}Returns: What imports this file, unused exports, circular dependencies.
Tool | Purpose |
| Find all usages of a hook across codebase |
| Find missing/unnecessary hook dependencies |
| Analyze single file structure |
| List all JSX in a file |
| Clear project cache after external changes |
trace_event_handler - Trace callback chains from event to side effects
trace_context_usage - Map Context providers to consumers
Grep Limitation | tsx-query Solution |
Finds "Button" in comments/strings | Only finds JSX |
Can't filter by prop values |
|
Can't detect aliased imports | Handles |
Can't trace prop flow | Full cross-file prop tracing |
Reads entire files | Returns only relevant data |
ts-morph - TypeScript AST manipulation
Model Context Protocol SDK - MCP server implementation
Zod - Schema validation
Sukhdev - @paramhq
See CONTRIBUTING.md for guidelines.
MIT - see LICENSE
Analyze a single React/TSX file. Returns components, hooks, imports, exports, and directive.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the TSX/JSX file to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only lists return values and does not state whether the operation is read-only, whether side effects occur, or error behavior. For an analysis tool this is a notable gap.
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 a single concise sentence that front-loads the verb and resource, then lists outputs. Every word earns its place; no redundancy or filler.
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 simplicity (one parameter, no nested objects) and the description's enumeration of expected return categories, the description is largely complete. The lack of behavioral details (e.g., read-only nature) is a minor gap, partially offset by the absence of an output schema and annotations.
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 input schema already provides 100% description coverage for the single filePath parameter. The description adds only that the file is a React/TSX file, matching the schema. It does not provide path format, suggested usage, or clarifying examples beyond the schema.
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 it analyzes a single React/TSX file and lists specific outputs (components, hooks, imports, exports, directive), making the purpose concrete. It does not explicitly differentiate from sibling analysis tools, but its scope as a general single-file analyzer is distinct enough.
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 phrase 'Analyze a single React/TSX file' implies when to use it (when you need a broad file overview), but it does not mention alternatives or explicitly exclusions. No guidance is given on when to prefer sibling tools such as find_component_usages or analyze_hook_deps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze React hook dependencies in a file. Finds missing dependencies (bugs), unnecessary dependencies, async callbacks in useEffect, and cleanup functions. Essential for catching stale closure bugs.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the TSX/JSX file to analyze | |
| hookTypes | No | Hook types to analyze (default: useEffect, useMemo, useCallback, etc.) | |
| componentName | No | Specific component to analyze (analyzes all if not provided) |
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 the type of analysis performed and categories of issues found, but does not describe the output format, whether the tool modifies files (though 'Analyze' implies read-only), or any limitations. This is a moderate gap for a tool that is expected to return diagnostics.
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 three concise sentences, each earning its place: what it analyzes, what it finds, and when it's essential. There is no fluff or repetition.
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?
With no output schema or annotations, the description should explain the expected return value. It describes the types of findings but not how they are presented (e.g., line numbers, severity, structured list). The tool is moderately complex with three parameters, and while the purpose is clear, the output contract is missing.
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 input schema has 100% description coverage for all parameters (filePath, hookTypes, componentName). The description adds no parameter-specific details, but the baseline for high schema coverage is 3, and the schema already provides adequate meaning.
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 React hook dependencies in a file, with a specific verb and resource. It details the specific categories of findings (missing dependencies, unnecessary dependencies, async callbacks in useEffect, cleanup functions), distinguishing it from sibling tools like find_hook_usages or analyze_file.
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 by stating it is 'Essential for catching stale closure bugs,' implying when to use it. However, it does not explicitly mention when not to use it or name alternative tools for different scenarios, such as trace_state_updates for state flow analysis.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze import/export relationships for a file. Find what imports this file (importedBy), detect unused exports, and circular dependencies. Uses cached import graph for fast subsequent queries. Returns summary + limited results.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results per category (default: 10, max: 50) | |
| exclude | No | File patterns to exclude | |
| include | No | File patterns to include | |
| filePath | Yes | File to analyze (relative to project root) | |
| direction | No | What to analyze: imports (what this file imports), importedBy (what imports this file), or both (default: both) | |
| projectPath | Yes | Root path of the project | |
| includeUnused | No | Include unused exports analysis - exports not imported by any file in the project (default: true) | |
| detectCircular | No | Detect circular dependencies involving this file (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the behavioral disclosure burden. It does reveal key behaviors: it uses a cached import graph and returns 'summary + limited results,' which implies truncation. However, it does not explicitly state read-only behavior, potential staleness of the cache, or how to refresh it, nor does it clarify what 'limited' means beyond a limit parameter.
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 three sentences, each earning its place: the first states purpose, the second lists key capabilities, and the third adds behavioral details about caching and output scope. It is front-loaded, efficient, and free of fluff or redundancy.
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?
Despite a rich schema (8 parameters) and clear purpose, there is no output schema, so the description's mention of 'Returns summary + limited results' offers only vague insight into the return value. The description omits details about result structure, pagination, or how caching affects freshness. While the schema fills in parameter details, the lack of output schema and limited return description leave gaps.
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 input schema has 100% coverage, documenting all 8 parameters with descriptions, enums, and defaults. The description adds little beyond high-level mentions of importedBy, unused exports, and circular dependencies, which are already in the schema. Since the schema carries the full detail, a baseline score of 3 is appropriate.
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: 'Analyze import/export relationships for a file.' It explicitly mentions specific capabilities—importedBy, unused exports, and circular dependencies—which distinguishes it from sibling tools like find_component_usages or trace_prop_flow. The verb 'analyze' combined with the resource 'import/export relationships' is specific and unambiguous.
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 implies when to use the tool (when analyzing imports/exports) and even hints at repeated use via caching ('Uses cached import graph for fast subsequent queries'), but it does not explicitly state exclusions or alternatives. No reference to sibling tools or scenarios where another tool would be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Clear the project and import graph caches. Use this after making changes to files outside the MCP to ensure fresh analysis.
| Name | Required | Description | Default |
|---|---|---|---|
| projectPath | No | Specific project path to clear (clears all 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 states that the tool clears both 'project and import graph caches' and implies that it invalidates cached state for fresh analysis. This is sufficient for a destructive operation on caches, though it could have noted that this forces recomputation on subsequent calls.
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 two sentences, front-loaded with the action and resource, followed by a practical usage note. Every word earns its place with no redundancy or filler.
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 simple cache-clearing operation with no output schema, the description adequately covers what, when, and why. It does not explain return behavior, but that is likely unnecessary for a void side-effectful action. The sibling context shows this is a utility that complements the analysis tools.
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 input schema has 100% coverage for its single optional parameter 'projectPath', including a description ('Specific project path to clear (clears all if not provided)'). The description does not add additional parameter-specific semantics beyond what the schema already states, so a baseline score of 3 is appropriate.
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 identifies the action ('Clear') and the specific resource ('project and import graph caches'), making it unambiguous what the tool does. It also inherently distinguishes itself from the sibling analysis tools, which are all read-only inspection tools, not cache manipulators.
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 gives a specific, actionable trigger: 'Use this after making changes to files outside the MCP to ensure fresh analysis.' This provides clear context for when to invoke it. It does not explicitly state when not to use it or mention alternatives, but no sibling tool serves the same cache-clearing purpose, so exclusion is not critical.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all JSX usages of a component across the codebase. Returns summary (totalUsages, filesCount), distribution by path, and limited usages with detailed prop info. Supports filtering by props (withProp, withoutProp, withPropValue), patterns (hasInlineHandler, hasSpreadProps), and conditional rendering.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max usages to return (default: 10, max: 50) | |
| exclude | No | File patterns to exclude (default: ["**/node_modules/**"]) | |
| include | No | File patterns to include (default: ["**/*.tsx", "**/*.jsx"]) | |
| filePath | No | Filter to specific file or folder path (e.g., "src/app/sections/") | |
| withProp | No | Only usages that have this prop (e.g., "onClick", "disabled") | |
| projectPath | Yes | Root path of the project (must contain tsconfig.json or source files) | |
| withoutProp | No | Only usages that do NOT have this prop | |
| componentName | Yes | Component name to search for (e.g., "Button", "DataGrid") | |
| withPropValue | No | Only usages where prop has specific value (e.g., variant="danger") | |
| hasSpreadProps | No | Filter by presence of spread props (e.g., {...props}) | |
| onlyConditional | No | Only usages inside conditional expressions (ternary, &&, etc.) | |
| parentComponent | No | Filter to usages within specific parent component | |
| hasInlineHandler | No | Filter by presence of inline arrow function handlers (e.g., onClick={() => ...}) | |
| includeExportChain | No | Include component definition and export chain (default: false) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the transparency burden. It discloses the output format (summary, distribution, limited usages) and the filter categories, which gives a good sense of behavior. 'Find' implies a non-mutating operation, though it doesn't explicitly confirm read-only 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 concise, front-loaded with the primary purpose, and packs return shape and filter categories into just three sentences. Every sentence adds value without redundancy.
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 complex tool with no output schema, the description covers the main return values and filter types, which is helpful. However, it doesn't explain how multiple filters interact (AND/OR) or the meaning of 'limited' usages regarding the limit parameter, leaving some gap for accurate invocation.
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 already provides full descriptions for all 14 parameters, so the description adds little beyond grouping filters (props, patterns, conditional rendering). This is adequate but doesn't transcend the schema's coverage, matching the baseline for 100% 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 opens with 'Find all JSX usages of a component across the codebase', which is a specific verb and resource. It clearly distinguishes from sibling tools like find_hook_usages or analyze_imports by focusing on JSX component usage and enumerating the return structure.
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 implies when to use the tool by stating its core capability and listing the available filters, which helps target searches. However, it does not explicitly mention alternatives or exclude scenarios, so it doesn't fully cover when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all usages of a React hook across the codebase. Returns summary (totalUsages, filesCount), distribution by path, and limited usages (default: 10). Use filePath/component filters to drill down.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max usages to return (default: 10, max: 50) | |
| exclude | No | File patterns to exclude | |
| include | No | File patterns to include | |
| filePath | No | Filter to specific file or folder path (e.g., "src/app/sections/") | |
| hookName | Yes | Hook name to search for (e.g., "useState", "useQuery", "useAuth") | |
| component | No | Filter to usages within specific component | |
| projectPath | Yes | Root path of the project |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description carries the full burden. It discloses key behavioral aspects: returns summary (totalUsages, filesCount), distribution by path, and limits usages with a default of 10. This goes beyond the verb and gives useful output expectations.
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 two sentences: the first states purpose and return summary, the second gives filter guidance. No wasted words, with the most important information 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?
With no output schema, the description should detail return values more thoroughly. It outlines the summary and distribution, but does not specify fields within individual usages (e.g., file path, line number). The limit default is mentioned but the maximum (50) is only in the schema. Adequate but with room for more detail.
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 baseline is 3. The description adds some semantic value by mentioning 'filePath/component filters' and the default limit, but it does not systematically explain each parameter beyond what the schema already provides.
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 opens with a specific verb and resource: 'Find all usages of a React hook across the codebase.' This clearly states the tool's function and distinguishes it from sibling tools like find_component_usages, which targets components.
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 phrase 'Use filePath/component filters to drill down' provides clear guidance on how to refine searches. While it does not explicitly mention alternatives or exclusions, the purpose statement makes the intended use case obvious.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Analyze what triggers a component to re-render: props, state, context, hooks. Includes memoization status and optimization suggestions. Helps understand re-render causes without reading component internals.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | File containing the component | |
| projectPath | Yes | Root path of the project | |
| componentName | Yes | Component name to analyze | |
| includeParentAnalysis | No | Whether to analyze parent render impacts (default: true) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must disclose side effects and safety, but it does not state whether the tool modifies files or requires specific permissions. It only mentions output details like memoization status and suggestions, leaving behavioral traits largely unspecified.
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 two sentences, front-loaded with the core action, and wastes no words. It effectively conveys the tool's purpose and key outputs.
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?
The description covers the tool's purpose and what it returns, but given no output schema and moderate complexity, it lacks details on failure modes, prerequisites, or the exact nature of the analysis. It is functional but not fully comprehensive.
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 documents all four parameters with clear descriptions, so the description adds no additional parameter context. Baseline of 3 applies because schema coverage is 100%.
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 re-render triggers and lists specific categories (props, state, context, hooks). It distinguishes itself from siblings like find_hook_deps by covering all trigger types and including memoization and optimization advice.
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 indicates a clear use case: understanding re-render causes without reading component internals. However, it does not explicitly contrast with sibling tools like trace_state_updates or analyze_hook_deps, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all JSX components in a file with their locations, props, and children info.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the TSX/JSX file |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It describes the returned information (locations, props, children) but does not disclose side effects, error behavior, or explicitly state that it is read-only. For a simple listing tool, this is adequate but not rich.
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 a single, concise, front-loaded sentence that clearly states the tool's purpose and output. Every word earns its place with no extraneous information.
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?
The tool is simple (one parameter, no output schema) and the description sufficiently covers what the tool does and returns. However, without an output schema, adding a note about the return format or limitations (e.g., only parses valid TSX/JSX) would make it more complete.
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 input schema already fully documents the single parameter filePath with a clear description. The tool description does not add additional parameter semantics beyond what the schema provides, so the baseline score of 3 is appropriate.
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 'List all JSX components in a file' with specific output details (locations, props, children info). This is a specific verb and resource, and it distinguishes from sibling tools like find_component_usages or analyze_file by focusing on component listing.
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 implies usage when an overview of components in a file is needed, but does not explicitly mention when to use it over alternatives or any exclusions. No sibling tools are referenced, so guidance is limited to the natural reading of the purpose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Trace a prop through the component hierarchy. Direction "up" finds where the value comes from, "down" finds where it propagates to children. Uses import graph for cross-file tracing.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max flow entries to return (default: 20, max: 50) | |
| maxDepth | No | Maximum depth to trace (default: 10) | |
| propName | Yes | Prop name to trace (e.g., "userId", "onChange") | |
| direction | Yes | Direction to trace: "up" (find origin), "down" (follow propagation), or "both" | |
| startFile | Yes | File containing the starting component | |
| projectPath | Yes | Root path of the project | |
| startComponent | No | Starting component name (uses first component in file if not specified) |
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 does reveal key behaviors: direction semantics and use of the import graph. However, it does not describe output format, behavior on cycles, or what 'both' direction yields, leaving significant gaps for an agent anticipating return values.
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 two sentences long and immediately front-loads the core purpose. It avoids redundancy and every phrase adds value, making it highly efficient.
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?
The tool has 7 parameters and no output schema, so the description should ideally explain what the trace results look like. It gives a hint about direction outcomes but omits return structure (e.g., list of files/components, match info). Parameter details are well-covered by the schema, but the absence of output description reduces completeness for this moderately complex 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 every parameter. The description adds marginal value by explaining direction semantics (already in schema) and the import graph mention, but it does not introduce new parameter-level meaning beyond the schema.
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 function: tracing a prop through the component hierarchy. It distinguishes itself from sibling tools like trace_state_updates by focusing on props rather than state, and it specifies the two direction modes (up/down) which 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 explains when to use each direction ('up' finds origin, 'down' finds propagation) and mentions cross-file tracing via the import graph. However, it does not explicitly compare against alternatives like find_component_usages or state when this tool is not appropriate, so context is clear but exclusions are absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find all locations that update a state variable. Returns setter calls with context (handler, useEffect, inline), trigger events, and whether updates are async/conditional. Helps understand state flow without reading entire files.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max updates to return (default: 20, max: 50) | |
| filePath | Yes | File containing the state | |
| stateName | Yes | State variable name (e.g., "count", "user", "isLoading") | |
| projectPath | Yes | Root path of the project | |
| componentName | No | Specific component to analyze |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses behavioral details such as returning setter calls with context (handler, useEffect, inline), trigger events, and async/conditional status. However, it does not clarify whether 'all locations' is scoped to the specified file or the entire project, leaving a minor ambiguity.
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 two sentences long, with the core purpose in the first sentence and complementary details in the second. It is concise, front-loaded, and contains no filler content.
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 absence of an output schema, the description adequately explains what the tool returns (setter calls with context, trigger events, async/conditional flags). The required parameters are clear from the schema, and the description aligns with the tool's function. It does not detail the return structure, but that is covered by the description's summary.
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?
All parameters are covered in the schema with descriptions, so the baseline is 3. The description adds no additional parameter-level details but provides conceptual context about what the tool traces (state updates), which is helpful but not necessary.
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 uses a specific verb and resource ('Find all locations that update a state variable'), which clearly distinguishes it from sibling tools like trace_prop_flow and find_render_triggers. It also adds value with the promise of understanding state flow without reading entire files.
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 the tool ('Helps understand state flow without reading entire files'), but does not explicitly mention alternatives or when not to use it. It stops short of naming sibling tools as alternatives, but the implied use case is evident.
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.
v3.1.1analyze_fileanalyze_hook_depsanalyze_importsclear_cachefind_component_usagesfind_hook_usagesfind_render_triggerslist_componentstrace_prop_flowtrace_state_updatesMost tools have clearly distinct purposes (state tracing, component usages, hook deps, imports, etc.). A minor overlap exists between analyze_file and list_components, as both can return component information, but the descriptions clarify the difference between broad file analysis and focused component listing.
All tool names follow a consistent verb_noun pattern with snake_case (trace_, find_, analyze_, list_, clear_). The verbs vary appropriately by action, and naming is predictable across the set.
With 10 tools, the set is well-scoped for a React/TSX analysis server. Each tool covers a distinct aspect of code analysis, and the count feels neither sparse nor bloated.
The surface covers major analysis needs: state updates, component/hook usage, hook dependencies, imports, render triggers, prop flow, and file-level component listing. Minor gaps exist, such as no dedicated context provider analysis or type-level queries, but agents can work around these with existing tools.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
An MCP server that gives your AI access to the source code and docs of all public github repos
The official Svelte MCP server providing docs and autofixing tools for Svelte development
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/paramhq/tsx-query'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
