Reflex

Official

by reflex-search

Overview Schema Related Servers Score Discussions

Rust

Local

Server Quality Checklist

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

Latest release: v1.6.1
Disambiguation5/5
Each tool targets a distinct aspect of codebase analysis (search, dependency, structure, indexing) with clear differences. Overlaps between list_locations and search_code are well-explained, and all tools have unique purposes.
Naming Consistency4/5
Tool names are mostly consistent with a verb_noun pattern (search_code, find_references, count_occurrences), though a few use different orders (gather_context, analyze_summary, check_index_status). Still readable and predictable.
Tool Count4/5
17 tools is somewhat high for a typical server, but each serves a distinct, well-justified purpose in code analysis. The count feels appropriate for the comprehensive scope, though it borders on heavy.
Completeness5/5
The tool set covers text, regex, and AST search; dependency analysis; indexing; and project orientation. No critical gaps like missing update/delete/creation tools, but those are out of scope for analysis.
Average 4.7/5 across 17 of 17 tools scored. Lowest: 4.1/5.
See the Tool Scores section below for per-tool breakdowns.
- 4 of 4 community issues answered or closed in the last 6 months
- 37 commits in the last 12 weeks
- Last stable release on July 6, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is failing
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.
This repository includes a glama.json configuration file.
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

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses there is no result limit, mentions error handling ('Index not found' -> call index_project), and implies read-only operation. Doesn't describe side effects or resource usage in depth, but sufficient.
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?
Description is well-structured with purpose, usage, example, and error handling. Could be slightly more concise, but front-loads the key purpose and differentiation.
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 7 parameters and no output schema, description covers output format, error recovery, and usage context. Lacks detail on some parameters like 'dependencies', but overall sufficient for agent decision-making.
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 baseline is 3. Description adds little beyond listing supported filters and providing an example; does not explain 'force' or 'dependencies' beyond 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 finds every place a pattern occurs, returns file+line objects, and explicitly distinguishes it from Glob and Grep. It also mentions the output format with an example.
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?
Provides explicit when-to-use scenarios (enumerating locations before reading, counting hits, listing without previews). Does not explicitly state when not to use it, but contrasts with alternatives upfront.
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 full burden. It discloses that the tool is incremental by default and describes the effect of `force: true`. However, it does not mention any potential side effects like blocking or unavailability during rebuild.
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?
Two succinct paragraphs: first states purpose and usage triggers, second explains incremental/force behavior. Every sentence adds value with no repetition or fluff.
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?
Covers the tool's purpose, when to use, and parameter effects. Lacks details about return values or success/failure indicators, but given the absence of an output schema, this is not a critical gap. Overall comprehensive for a maintenance 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 coverage is 100% and each parameter has a description. The tool description reinforces the meaning of `force` (full rebuild) but does not add new information beyond the schema. Baseline 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 'Rebuild or update the code search index,' using a specific verb and resource. It distinguishes itself from sibling tools (which focus on searching/analysis) by being an indexing maintenance tool.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios: when search tools return 'Index not found' or 'stale' errors, after git operations, file edits, or stale results. Also differentiates incremental vs full rebuild with the `force` parameter.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses behavior: only static imports are followed, dynamic imports are filtered, it returns a map of file to depth, and handles errors. This exceeds the burden for a tool without annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured with separate concerns: main action, use cases, example, constraints, and error handling. Each sentence contributes meaningful information, though it could be slightly more concise without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite lacking an output schema, the description explains the return format as a map of file to depth. It covers error recovery and constraints. Some detail about the map's exact structure (e.g., depth as integer) is implied but not explicit, which is acceptable.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for both parameters. The description adds value by specifying default depth (3), max recommended depth (5), and that path supports fuzzy matching. This goes beyond the schema's explanations.
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 it walks the transitive dependency tree of a file up to a specified depth. It specifies verb 'walk', resource 'transitive dependency tree', and result 'map of file → depth'. It distinguishes from siblings by recommending this over 'hand-rolling recursive grep' and noting that it only follows static imports.
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 lists use cases: understanding dependency chains, analyzing coupling, planning refactoring. It provides an example with depth=2 and advises on error handling (call index_project on 'Index not found' and retry). It could be improved by explicitly contrasting with siblings like get_dependencies or find_references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully carries the burden. It discloses behavior: returns only total and file count, never loads content, supports all listed filters, and indicates error recovery steps. No contradictions.
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 relatively concise and front-loads the core purpose. It uses bullet-style use cases and example JSON. Minor redundancy could be trimmed, but overall efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 9 parameters, no output schema, and moderate complexity, the description is thorough. It explains return format with example, error handling, and all applicable filters. No gaps identified.
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%, and description adds marginal value by summarizing filter parameters ('Supports all filters (lang, file, glob, exclude, symbols, kind)') but does not add meaning beyond what the schema provides. Baseline 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 it provides 'Count-only statistics for a pattern' and distinguishes itself from siblings by recommending over grep -c, wc -l, rg --count. It specifies it returns total occurrences and file count without loading content.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use (e.g., 'how many times is X used?', impact checks before refactoring, validating search scope) and provides error handling guidance ('On Index not found call index_project, then retry'). Also mentions preferring this over alternative shell commands.
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, the description carries behavioral disclosure. It explains default behavior (all context types gathered), flag usage for focused slices, and depth/path control. It doesn't describe response format or side effects, but the read nature implies no mutation, and the consolidated overview is implied. Good but not exhaustive.
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 separate sentences for purpose, usage guidance, and parameter details. It is slightly verbose but front-loads key actions and the recommendation. Could be more concise, but every sentence adds value.
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 9 optional parameters, no output schema, and 16 siblings, the description covers purpose, usage, parameter semantics, and differentiation. It lacks output format details, but the tool's simplicity (overview) makes this acceptable. The guidance is complete for selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and description adds significant meaning: explains each boolean flag's effect (e.g., 'Show directory structure'), clarifies defaults (depth: 2), and notes that omitting all flags gathers everything. This enriches understanding 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 purpose: 'One-shot codebase orientation' covering structure, file types, project type, frameworks, etc. It distinguishes from siblings by recommending over 'Glob-based recon' and contrasting with 'search_code' or 'find_references' for specific symbol lookup.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit 'Use this for' and 'instead' clauses provide clear when-to or when-not-to guidance. It identifies specific scenarios (unfamiliar codebase, locating entry points) and names alternative tools for different needs (search_code, find_references).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavior: it only considers static imports, returns aggregate counts with a specific structure, and handles errors with a retry pattern. It clearly communicates what the tool does and its limitations, exceeding the minimal requirements.
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 at three sentences plus an example. It front-loads the purpose and usage guidance, with every sentence providing essential information. No waste or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/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 optional parameter, no output schema), the description is complete. It explains what the tool returns (aggregate counts), provides an example, and specifies error handling. No additional context is needed for effective use.
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% with one parameter (min_dependents) already described in the schema. The description does not add additional meaning beyond the schema, so it meets the baseline but does not exceed it.
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 tool as a 'one-call overview of codebase dependency health,' explicitly distinguishing it from sibling tools like find_circular, find_hotspots, find_unused, and find_islands by stating it should be preferred over running them individually. This provides a specific verb and resource with 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 Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly states when to use this tool ('Prefer this over running individual analyses') and provides an alternative: 'so the agent can decide which specific analysis to drill into.' It also gives explicit error recovery instructions ('On Index not found/stale error, call index_project, then retry'), offering comprehensive guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses key behaviors: static imports only, default sort order, default page size (200), filtering defaults (2–500 files or 50% of total), pagination mechanism, and error recovery steps. Since no annotations are provided, the description carries the full burden and excels.
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 and well-structured: purpose first, then usage/advantage, then output format, then pagination details, then filtering, then error handling. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite having 5 optional parameters and no output schema, the description covers all critical aspects: purpose, behavior (static imports), return format, pagination, filtering defaults, and error recovery. It is self-contained and comprehensive.
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 parameter descriptions. The description adds semantic value by explaining default values (e.g., 'default: 2–500 files, or 50% of total'), sort behavior, and pagination usage, enhancing understanding 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 clearly states 'Find disconnected components (islands) in the static import graph' with a precise definition. It distinguishes this tool from siblings (e.g., find_circular, find_hotspots) by focusing on disconnected groups, making its purpose unmistakable.
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 advises preferring this tool over manual alternative methods and provides error-handling guidance ('call index_project, then retry'). It implicitly indicates when to use (for islands) but does not explicitly list when not to use it relative to siblings, though context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description fully discloses performance characteristics: 'SLOW: bypasses trigram optimization and scans the ENTIRE codebase (500ms-10s+).' Also warns about potential 'Index not found' errors and how to retry. This transparency far exceeds minimal requirements.
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?
Well-structured and front-loaded: starts with purpose, then warning, usage guidelines, requirement, examples, and error handling. Every sentence adds value without 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 comprehensive description, it omits details about return format (default output beyond 'paths' option) and result structure, which is notable given no output schema. The complexity (10 parameters) and no output schema demand more completeness.
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%, providing baseline of 3. The description adds significant value with examples for pattern syntax, emphasis on `glob` importance, and explanation of `force` and `paths` usage. However, not every parameter gains additional insight beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function: 'Structure-aware search using Tree-sitter AST patterns (S-expressions).' It distinguishes itself from sibling tools by explicitly recommending `search_code` for most cases and specifying when to use this tool for structural matching.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Excellent guidance: explicitly advises to prefer `search_code` in 95% of cases, states conditions for using this tool ('only when you must match code structure'), and mandates passing `glob` to limit scope. Also provides error recovery instructions.
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?
The description thoroughly explains behavior including result structure (columnar), pagination (offset, has_more), error handling (index_project), and output customization (env var). It does not explicitly state read-only, but the nature of search implies no side effects. Lacks explicit mention of idempotency.
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 efficiently organized with clear sections, immediate purpose statement, and concise guidance. While it is longer than some, the information density justifies the length; no redundant sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with no output schema and no annotations, the description is remarkably complete. It addresses purpose, when to use, parameter semantics, result format, pagination, error recovery, and configuration options. Few gaps remain.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description significantly enriches parameter semantics with concrete examples and escaping rules for the `pattern` parameter, clarifies mode behavior, pagination details, and glob filtering. It leverages the high schema coverage to provide actionable guidance rather than redundancy.
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 explicitly defines the tool's function as regex code search across the entire codebase, distinguishes it from alternatives like search_code and rg/grep, and details the output format (file paths, line numbers, previews). No ambiguity.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit when-to-use and when-not-to-use guidance, directly naming alternatives (search_code, rg/grep) and specifying conditions (simple patterns vs regex, symbol searches). It also gives context for mode selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that only static imports are considered, return format with pagination and sorting, default page size 200, and error recovery actions (call index_project and retry). No annotations exist, so description fully covers behavioral traits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Every sentence is valuable; front-loaded with purpose, then details on return format, pagination, and error handling. No redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 3 parameters, no output schema, and no annotations, the description is remarkably complete: purpose, usage, behavior, parameters, error handling, and return structure are all covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Adds meaning beyond schema by describing default page size (limit), default sort order (desc), pagination offset usage, and the meaning of sort values (asc/desc). Schema coverage is 100%, but description enriches parameter understanding.
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?
Clearly states it detects circular dependencies in the static import graph, with example cycle and return format, distinguishing it from sibling tools like find_references or get_dependencies.
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?
Explicitly says 'Prefer this over manually grepping' and gives error handling instructions, but does not list alternative tools or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description fully discloses behavior: it is a read-only check, does not run a search, and returns specific fields (status, reason, action_required, files_modified). It explains that staleness relates to commit changes, giving the agent full understanding.
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 efficient: first sentence defines purpose, second gives usage guidance, third describes return type, and fourth provides examples. No redundant or irrelevant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (no parameters, no output schema), the description covers all necessary aspects: purpose, usage, return values, examples. It is complete and leaves no ambiguity.
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?
No parameters exist, so schema coverage is 100% trivially. The description does not need to add parameter info, but it does add value by describing the return object structure, which compensates for the lack of output 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 'Check whether the Reflex search index is fresh, stale, or missing' with a specific verb and resource. It distinguishes itself from siblings like 'index_project' (which builds the index) and search tools by emphasizing it runs no search.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says when to call: 'once at session start and before any bulk search/refactoring task'. Also tells what to do if status is stale/missing: 'call index_project before searching'. Provides concrete scenarios like git operations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Even without annotations, description covers key behaviors: only static imports counted, pagination (has_more, offset), sorting, default page size, error conditions, and return format.
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?
Dense yet efficient: purpose first, then usage guidelines, behavior details, error handling, and an example. Every sentence adds value, no fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Comprehensive for a tool with no output schema: describes return structure (pagination, path, import_count), error handling, pagination mechanics, and includes an example. All 4 optional parameters are explained in schema and context is provided in description.
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%, baseline 3. Description adds value by explaining sort default (desc), pagination with offset, and default page size (200). min_dependents parameter is fully described in schema but not elaborated in text; still, overall parameter guidance is strong.
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?
Clearly states it ranks files by import count (dependency hotspots) and distinguishes from grep-based heuristics. Lists specific use cases like finding critical-path files and refactoring blast radius.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to prefer this tool over grep-based alternatives. Provides when-to-use scenarios and error recovery: on 'Index not found' or 'stale' error, call index_project then retry.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, but the description fully discloses default behavior (excludes strings/comments), response structure, pagination details, and error handling (call index_project on stale index). This compensates for missing annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is well-structured and front-loaded with purpose, but slightly verbose. Every sentence adds value, though it could be tightened without losing clarity.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (10 parameters, no output schema), the description covers return structure, pagination, and error recovery comprehensively. It leaves little ambiguity for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, yet the description adds meaningful context beyond schema: e.g., default limit covers most tasks in one call, mode shortcuts, and include_strings semantics. It enhances understanding without redundancy.
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: 'Atomic symbol definition + every usage in one call.' It distinguishes from sibling tools like grep-based patterns and chaining search_code, making the value proposition explicit.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage guidance is provided: 'Use this for: find all callers of X, impact analysis, rename planning, dead-code detection.' It also contrasts with alternative patterns, offering clear when-to-use recommendations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses that only static imports are considered, that entry points are false positives, pagination behavior (default page size 200, offset), and return structure. Fully transparent beyond schema.
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?
Single well-structured paragraph front-loaded with core purpose, followed by usage advice, output format, pagination details, important notes, and error handling. Every sentence adds value, no wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given no output schema, description includes return shape and pagination. Covers special cases (entry points), error recovery, and static import limitation. Complete for a listing tool with pagination and error states.
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%, but description adds meaning: explains default limit value (200) and how offset works for pagination. Also shows output format with example. Adds value 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?
Clear verb ('List files that no other file imports') and resource ('orphan candidates for deletion'). Distinguishes from siblings by mentioning it uses the static import graph, avoiding manual cross-referencing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to prefer this tool over alternatives ('Prefer this over manual Glob + Grep cross-referencing'), warns about entry points appearing unused, and provides error recovery steps ('On "Index not found" / "stale" error, call index_project, then retry').
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/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 discloses behavioral traits: built from pre-built reverse-import index, returns list of file paths, fuzzy matching, only static imports considered, dynamic imports filtered. Also mentions error handling and recovery.
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 brief and front-loaded with purpose. The three sentences contain no fluff: each sentence adds essential information about functionality, usage scenarios, and error recovery. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With one parameter, no output schema, and no annotations, the description covers all aspects: purpose, mechanism (reverse-import index), usage guidelines, parameter behavior (fuzzy matching), limitations (static imports only), and error handling. It is self-contained and complete.
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% for the single 'path' parameter, with a description in the schema itself. The tool description adds clarification on fuzzy matching (exact paths, fragments, bare filenames) but does not significantly enhance beyond the schema. A score of 4 reflects effective but not exceptional additional value.
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 'Reverse dependency lookup — find every file that imports a given file,' clearly stating the verb (find/reverse lookup) and resource (files importing a given file). It distinguishes from sibling tools like 'get_dependencies' and 'grep-based find-callers'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'impact analysis before changing a module; finding consumers of a library; detecting file importance.' Also advises preferring over grep-based alternatives and provides recovery steps for errors: 'On Index not found / stale error, call index_project, then retry.'
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully covers modes (full-text, symbols, count), result shape (columnar vs legacy), pagination behavior, error handling (call `index_project` on stale index), and parameter-specific limitations (e.g., `dependencies` only for Rust).
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?
Well-structured with sections for summary, modes, result shape, pagination, error handling. Front-loaded with purpose. Slightly lengthy with some details (e.g., environment variable) that could be omitted but overall organized.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 16 parameters and no output schema, the description covers all critical behaviors: modes, pagination, error handling, result format, and parameter-specific caveats. Complete for selecting and invoking the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Every parameter has a schema description (100% coverage). The tool description adds extra context beyond schema, e.g., for `limit`, `dependencies`, `mode`, `preview_length`, clarifying defaults, important notes, and usage tips.
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 it is the default code search for the whole codebase, specifying the verb 'search' and resource 'codebase'. It distinguishes from sibling tools like `search_regex` by noting pattern constraints.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit when-to-use scenarios (finding occurrences, usages, definitions) and when-not-to-use (special characters -> use `search_regex`). Includes pagination and error handling instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description fully discloses behavioral traits: returns object per import with path/line/type/symbols, supports fuzzy path matching, extracts only static imports, and handles stale index errors. This is comprehensive and goes beyond basic 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 well-structured, starting with the core action, then providing guidelines, use cases, parameter details, and error handling. Every sentence adds value without redundancy, making it efficient and informative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the single parameter, no output schema, and no annotations, the description covers all necessary aspects: purpose, usage, behavioral details, parameter specifics, and error recovery. It is fully self-contained and leaves no critical gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with a description for the 'path' parameter. The description adds extra context about fuzzy matching and examples (e.g., 'Controllers/FooController.php' vs 'FooController.php'), enhancing understanding 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 clearly states the tool lists every import of a single file, using a specific verb and resource. It distinguishes itself from alternatives like grep and sibling tools by emphasizing the pre-built import index, making the purpose unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly advises when to use this tool over grep, lists specific use cases (understanding dependencies, analyzing structure), and provides error recovery instructions (call index_project then retry). This gives clear guidance on when and how to use it.
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:

[![reflex MCP server](https://glama.ai/mcp/servers/reflex-search/reflex/badges/card.svg)](https://glama.ai/mcp/servers/reflex-search/reflex)

Score Badge

Copy to your README.md:

[![reflex MCP server](https://glama.ai/mcp/servers/reflex-search/reflex/badges/score.svg)](https://glama.ai/mcp/servers/reflex-search/reflex)

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/reflex-search/reflex'

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