How do I use JSX Prop Lookup MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@JSX Prop Lookup MCP Server find usages of prop 'disabled' in Select components" 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.

JSX Prop Lookup MCP Server

by lmn451

Overview Schema Source Related Servers Discussions Admin

JavaScript

Local

JSX Prop Lookup MCP Server

An MCP (Model Context Protocol) server that analyzes JSX prop usage in React/TypeScript codebases using AST parsing.

Features

AST-based Analysis: Uses Babel parser for accurate JSX/TSX parsing
Prop Usage Tracking: Find where props are used across components
Component Analysis: Analyze prop definitions and usage patterns (supports destructuring and identifier-based props access in function/arrow components)
TypeScript Support: Includes TypeScript interface analysis
Identifier Param Support: Detects props accessed via identifier parameters (not just destructured), e.g., p.onClick and buttonProps.disabled inside function/arrow component bodies
Multiple Search Options: Search by component, prop name, or analyze entire directories

Related MCP server: tsx-query

Installation

Option 1: Use with npx (Recommended)

No installation required! Use directly with npx:

npx jsx-prop-lookup-mcp-server

Option 2: Install Globally

npm install -g jsx-prop-lookup-mcp-server
jsx-prop-lookup-mcp-server

Option 3: Development Setup

git clone https://github.com/your-username/jsx-prop-lookup-mcp-server.git
cd jsx-prop-lookup-mcp-server
npm install
npm run build
npm start

Usage

The server provides four main tools:

1. `analyze_jsx_props`

Analyze JSX prop usage in files or directories.

Parameters:

path (required): File or directory path to analyze
componentName (optional): Specific component name to analyze
propName (optional): Specific prop name to search for
includeTypes (optional): Include TypeScript type information (default: true)

2. `find_prop_usage`

Find all usages of a specific prop across JSX files. The directory must be an absolute path.

Parameters:

propName (required): Name of the prop to search for
directory (optional): Directory to search in (default: "."). Must be an absolute path.
componentName (optional): Limit search to specific component

3. `get_component_props`

Get all props used by a specific component. The directory must be an absolute path.

Parameters:

componentName (required): Name of the component to analyze
directory (optional): Directory to search in (default: "."). Must be an absolute path.

4. `find_components_without_prop`

Find component instances that are missing a required prop (e.g., Select components without width prop). The directory must be an absolute path.

Parameters:

componentName (required): Name of the component to check (e.g., "Select")
requiredProp (required): Name of the required prop (e.g., "width")
directory (optional): Directory to search in (default: "."). Must be an absolute path.

Example Output

{
  "summary": {
    "totalFiles": 5,
    "totalComponents": 3,
    "totalProps": 12
  },
  "components": [
    {
      "componentName": "Button",
      "file": "./src/Button.tsx",
      "props": [
        {
          "propName": "onClick",
          "componentName": "Button",
          "file": "./src/Button.tsx",
          "line": 5,
          "column": 10
        }
      ],
      "propsInterface": "ButtonProps"
    }
  ],
  "propUsages": [
    {
      "propName": "className",
      "componentName": "Button",
      "file": "./src/App.tsx",
      "line": 15,
      "column": 20,
      "value": "btn-primary"
    }
  ]
}

Component name matching

Namespaced JSX components (e.g., UI.Select) are supported. You can target either the full dotted name (e.g., UI.Select) or the local component name (e.g., Select) in tool inputs. Results record the full dotted name where applicable.

Supported File Types

.js - JavaScript
.jsx - JavaScript with JSX
.ts - TypeScript
.tsx - TypeScript with JSX

MCP Client Configuration

Using with npx (Recommended)

Add to your MCP client configuration:

{
  "mcpServers": {
    "jsx-prop-lookup": {
      "command": "npx",
      "args": ["jsx-prop-lookup-mcp-server"]
    }
  }
}

Using with global installation

{
  "mcpServers": {
    "jsx-prop-lookup": {
      "command": "jsx-prop-lookup-mcp-server"
    }
  }
}

Using with local development

{
  "mcpServers": {
    "jsx-prop-lookup": {
      "command": "node",
      "args": ["dist/index.js"],
      "cwd": "/path/to/jsx-prop-lookup-mcp-server"
    }
  }
}

Development

npm run dev  # Run in development mode
npm run build  # Build for production
npm start  # Run built version

Security and safe operation

Important: this MCP server reads files and directories on disk based on client-provided paths. Do NOT expose the stdio-based server to untrusted or network-exposed clients. By default there is no filesystem whitelist; to restrict filesystem access, set the ALLOWED_ROOTS environment variable to a comma-separated list of allowed root directories (absolute or workspace-relative). When configured, any tool request that refers to a path outside the allowed roots will be rejected.

Example (restrict to the repository root):

export ALLOWED_ROOTS="."
npm run dev

Recommended practices:

Run this server only in trusted environments, or behind an authenticated proxy.
Use ALLOWED_ROOTS to limit the scope of accessible files.
Do not run the server as a privileged user; run under a least-privileged account.
Consider further sandboxing (containerization) when servicing untrusted inputs.

Available Tools

4 tools

analyze_jsx_propsA

Analyze JSX/React component prop usage across files and directories.

Use this tool when you need to:

Understand what props a component accepts
Find all components in a codebase and their props
Analyze prop usage patterns in a project
Get TypeScript interface information for components

EXAMPLES:

Analyze all components in current directory: { "includeTypes": true }
Analyze all components in src/components: { "path": "src/components", "includeTypes": true }
Find all props for Button component in current directory: { "componentName": "Button", "includeTypes": true }
Find all usages of onClick prop in current directory: { "propName": "onClick", "includeTypes": false }
Analyze specific file with type info: { "path": "src/App.tsx", "includeTypes": true }

Returns:

Component names and their props
Prop types (when includeTypes is true)
File locations where components are defined

ParametersJSON Schema

Name	Required	Description	Default
`path`	No	Absolute or relative path to file or directory to analyze (e.g., "src/components" or "src/App.tsx", defaults to current directory)	.
`componentName`	No	Filter: analyze only this specific component name (e.g., "Button")
`propName`	No	Filter: search only for this specific prop name (e.g., "onClick")
`includeTypes`	No	Include TypeScript type information in results

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description fully carries the transparency burden. It explains that the tool returns component names, props, types (when includeTypes is true), and file locations. The examples imply it is read-only and non-destructive. It does not mention permissions, rate limits, or edge cases, but for an analysis tool, the disclosure is adequate.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement, bullet-point use cases, and five numbered examples. Every sentence provides unique information. The examples are particularly efficient at demonstrating parameter usage without verbosity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the four parameters and no output schema, the description covers the tool's capabilities and expected output format. It explains what is returned (components, props, types, locations). It does not cover error scenarios or limit cases, but the examples and bullet points are sufficient for an agent to understand typical usage.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so each parameter is already described. The description adds significant value by providing concrete examples that illustrate how parameters interact (e.g., combining path with componentName or propName). This helps an agent understand the filtering behavior beyond the schema's static descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool analyzes JSX/React component prop usage across files and directories, with specific verbs and resource. The bullet points and examples distinguish it from siblings by emphasizing it as a general analysis tool that can filter by component or prop, while siblings like find_components_without_prop and get_component_props are more specialized.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use this tool when you need to' and lists four bullet points covering common scenarios. It provides five concrete examples showing when to use different parameter combinations. However, it does not explicitly state when NOT to use this tool or how it differs from siblings, leaving some ambiguity about alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_components_without_propA

Find component instances that are missing a required prop (e.g., Select components without width prop).

Use this tool when you need to:

Audit components for missing required props
Ensure accessibility props are present (e.g., missing aria-label)
Check for missing styling props (e.g., missing width or height)
Enforce prop requirements across the codebase
Refactor components and ensure all usages are updated

EXAMPLES:

Find Select components missing width prop in current directory: { "componentName": "Select", "requiredProp": "width" }
Audit Image components for missing alt text in current directory: { "componentName": "Image", "requiredProp": "alt" }
Find Button components missing type prop in src directory: { "componentName": "Button", "requiredProp": "type", "directory": "src" }
Check Input components for missing label in forms directory: { "componentName": "Input", "requiredProp": "aria-label", "directory": "src/forms" }

Returns:

List of component instances missing the required prop
File paths and line numbers
Existing props on those instances
Summary statistics (total instances vs missing count)

ParametersJSON Schema

Name	Required	Description	Default
`componentName`	Yes	Name of the component to check (e.g., "Select", "Button", "Image")
`requiredProp`	Yes	Name of the required prop that should be present (e.g., "width", "alt", "aria-label")
`directory`	No	Directory to search in (defaults to current directory)	.

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It specifies return values (list, file paths, line numbers) but lacks critical behavioral details like file types scanned, recursion behavior, performance implications, or error handling.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with sections for purpose, use cases, examples, and returns. It is appropriately sized and front-loaded, though some information is slightly redundant (e.g., repeating purpose in examples).

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a relatively simple tool, the description covers the main aspects: purpose, parameters (via examples), and return format. It is missing potential edge cases but overall is complete enough given no output schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with clear descriptions. The description adds value with concrete examples (e.g., 'Select components without width prop') and usage patterns that go beyond what the schema alone provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the purpose with a specific verb 'Find component instances that are missing a required prop', and it is easily distinguished from siblings like 'analyze_jsx_props' and 'find_prop_usage' which focus on different aspects.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description includes a dedicated 'Use this tool when you need to' section with five explicit tasks, providing clear context. However, it does not mention when not to use it or explicitly compare to siblings, so it loses the top score.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

find_prop_usageA

Find all usages of a specific prop across JSX/React files.

Use this tool when you need to:

Locate where a prop is used throughout the codebase
Find all components that use a specific prop like "onClick", "className", etc.
Audit prop usage for refactoring or deprecation
Understand prop propagation patterns

EXAMPLES:

Find all onClick handlers in current directory: { "propName": "onClick" }
Find className usage in components directory: { "propName": "className", "directory": "src/components" }
Find variant prop only on Button components in current directory: { "propName": "variant", "componentName": "Button" }
Find all disabled props in specific directory: { "propName": "disabled", "directory": "src/forms" }

Returns:

List of component instances using the prop
File paths and line numbers
Values passed to the prop

ParametersJSON Schema

Name	Required	Description	Default
`propName`	Yes	Name of the prop to search for (e.g., "onClick", "className", "variant")
`directory`	No	Directory to search in (defaults to current directory)	.
`componentName`	No	Filter: only search within this component name (e.g., "Button")

TDQS

A4.3/5.0

Behavior4/5

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

No annotations provided, but the description explains that it returns file paths, line numbers, and values. It implies a read-only search operation without side effects. Could explicitly state read-only nature but overall good transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a main sentence, bulleted use cases, examples in JSON, and return info. It is slightly verbose due to examples but they are directly useful.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With 3 parameters and no output schema, the description covers usage, parameter behavior via examples, and return values. It adequately addresses the complexity and leaves no major gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions, but the description adds practical examples and clarifies default for directory and filtering role of componentName. This adds meaning beyond the schema alone.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description starts with 'Find all usages of a specific prop across JSX/React files' which is a specific verb+resource combination. The examples and sibling tools (analyze_jsx_props, find_components_without_prop, get_component_props) show clear differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists explicit use cases ('Locate where a prop is used', 'Audit prop usage') and provides examples. It does not state when not to use but the context is clear enough for an agent to decide.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_component_propsA

Get detailed information about all props used by a specific component.

Use this tool when you need to:

Understand what props a component accepts and uses
Document component APIs
Check if a component has certain props before using it
Analyze component interfaces

EXAMPLES:

Get all props for Button component in current directory: { "componentName": "Button" }
Check Modal component props in specific directory: { "componentName": "Modal", "directory": "src/components" }
Document Card component API in UI directory: { "componentName": "Card", "directory": "src/ui" }
Analyze Input component interface in current directory: { "componentName": "Input" }

Returns:

All props used by the component
Prop types and default values
Usage statistics across the codebase

ParametersJSON Schema

Name	Required	Description	Default
`componentName`	Yes	Name of the component to analyze (e.g., "Button", "Modal", "Card")
`directory`	No	Directory to search in (defaults to current directory)	.

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description must cover behavioral aspects. It mentions the tool returns props, types, defaults, and usage statistics, but does not disclose if it scans recursively, performance implications, or error handling (e.g., missing component). Safe read-only behavior is implied but not stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is well-structured with a clear purpose statement, usage bullets, examples, and a return summary. It is front-loaded and each section earns its place. The examples are helpful but could be slightly condensed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite lacking an output schema, the description adequately describes the return values (all props, types, defaults, usage statistics). It covers essential information for a simple analysis tool. Missing details about error states or edge cases prevent a higher score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters (componentName, directory) are described. The description adds examples showing real usage but does not provide additional semantic meaning beyond the schema. Baseline score of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly specifies the tool retrieves detailed prop information for a component, including types, defaults, and usage statistics. The verb 'get' and resource 'component props' are explicit, and the examples reinforce the purpose. It distinguishes from siblings like find_prop_usage and find_components_without_prop by focusing on complete prop details.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description lists concrete use cases (e.g., understand props, document APIs, check before using) which guide the agent effectively. However, it does not explicitly state when not to use this tool or mention direct alternatives, which slightly limits guidance completeness.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv3.5.0May 26, 2026
- First observedanalyze_jsx_props
- First observedfind_components_without_prop
- First observedfind_prop_usage
- First observedget_component_props

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.1/5.0

Scored 2026-05-26 13:00 across 4 tools

Disambiguation4/5

Tools have distinct purposes, but 'analyze_jsx_props' with a component name overlaps with 'get_component_props'. Descriptions help differentiate, but an agent might be unsure which to use for listing props of a single component.

Naming Consistency5/5

All tool names follow a consistent verb_noun snake_case pattern (e.g., 'analyze_jsx_props', 'find_components_without_prop'), making them predictable and easy to parse.

Tool Count5/5

With 4 tools, the server is well-scoped for JSX prop lookup. Each tool has a clear role, and the count is neither too sparse nor excessive for the domain.

Completeness4/5

The tool surface covers major lookup needs (analyze props, find missing props, find prop usage, get component props). A minor gap is the lack of a tool to list all components without analyzing props, but the set is functional for its purpose.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

Priority — TypeScript Compiler Intelligence B
dev.semanticreader
Stateless TS/JS compiler facts for agents: references, imports, impact. No repo index or OAuth.
Code Analysis Developer Tools
121
XRay-VisionOAuth
com.emtailabs
AI-powered codebase analysis — call graphs, security, dead code, complexity. 150+ tools.
Code Analysis Developer Tools Autonomous Agents
2
coderegistry A
io.github.hellosg
Enterprise code intelligence for M&A, security audits, and tech debt. Hosted server with 200k free.
Code Analysis Developer Tools Security
2321
Nekzus-npm-sentinel-mcpOAuth
ai.smithery
Provide AI-powered real-time analysis and intelligence on NPM packages, including security, depend…
Developer Tools Monitoring Security
218

Related MCP Servers

react-analyzer-mcp
Code Analysis Documentation Access
azer
A
license
Not graded
quality
F
maintenance
* analyze your react projects locally * consistent output w/ AST parsing + AI * create markdown docs, llm.txt for your react code at once
Updated a year ago (2025-04-09 20:50 UTC)
7 npm
58
ISC
tsx-query
Developer Tools Code Analysis Software Architecture
paramhq
A
license
A
quality
D
maintenance
Semantic React/TSX analysis MCP server that saves 70-90% tokens by using AST to retrieve precise component usages, prop flow, and state update information for AI coding assistants.
Updated 8 months ago (2026-01-22 10:06 UTC)
10
10 npm
MIT
jsx-analyzer
Code Analysis Developer Tools
lmn451
A
license
Not graded
quality
F
maintenance
Analyzes JSX component prop usage in React/JSX codebases, enabling detection of specific props, missing props, and substring matching for prop values.
Updated a year ago (2025-07-19 09:34 UTC)
20 npm
ISC
mcp-component-finder
Code Analysis Developer Tools
karudo
A
license
Not graded
quality
C
maintenance
Enables searching for component, function, and type usage in React/TypeScript projects.
Updated a year ago (2025-09-03 06:09 UTC)
4 npm
MIT

JSX Prop Lookup MCP Server

Features

Installation

Option 1: Use with npx (Recommended)

Option 2: Install Globally

Option 3: Development Setup

Usage

1. analyze_jsx_props

2. find_prop_usage

3. get_component_props

4. find_components_without_prop

Example Output

Component name matching

Supported File Types

MCP Client Configuration

Using with npx (Recommended)

Using with global installation

Using with local development

Development

Security and safe operation

Available Tools

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

1. `analyze_jsx_props`

2. `find_prop_usage`

3. `get_component_props`

4. `find_components_without_prop`