tsx-query

by paramhq

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

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

Latest release: v3.1.1
Disambiguation4/5
Most 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.9/5 across 10 of 10 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 0 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: '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.
Usage Guidelines3/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines4/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
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 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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents 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.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 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.
Usage Guidelines4/5
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.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use 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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It 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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

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

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

Card Badge

Copy to your README.md:

[![tsx-query MCP server](https://glama.ai/mcp/servers/paramhq/tsx-query/badges/card.svg)](https://glama.ai/mcp/servers/paramhq/tsx-query)

Score Badge

Copy to your README.md:

[![tsx-query MCP server](https://glama.ai/mcp/servers/paramhq/tsx-query/badges/score.svg)](https://glama.ai/mcp/servers/paramhq/tsx-query)

Latest Blog Posts

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

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/paramhq/tsx-query'

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