Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Ressl AI MCP Server search for 'function' in my project's main.js file"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
MCP server for file search functionality with support for both partial and exact word matching.
Partial Keyword Search: Find all occurrences of a keyword including partial matches
Exact Word Search: Match complete words only with optional case sensitivity
Detailed Results: Line numbers, column positions, and matched text for all occurrences
MCP Inspector Integration: Built-in support for testing with MCP Inspector
Related MCP server: MCP Keyword Search
npm installnpm run buildnpm startThis will automatically build the project and launch the MCP Inspector for testing.
npm run devRuns TypeScript compiler in watch mode for continuous development.
Searches for a keyword within a file, finding all occurrences including partial matches.
Parameters:
filePath (string, required): Path to the file to search in
keyword (string, required): Keyword to search for
Example:
{
"filePath": "./sample.txt",
"keyword": "search"
}Result: Finds "search", "searching", "researcher", etc.
Searches for exact word matches within a file using word boundaries.
Parameters:
filePath (string, required): Path to the file to search in
word (string, required): Exact word to search for
caseSensitive (boolean, optional): Whether search should be case sensitive (default: false)
Example:
{
"filePath": "./sample.txt",
"word": "search",
"caseSensitive": false
}Result: Finds only exact "search" matches, not "searching" or "researcher"
A sample.txt file is included in the project for testing purposes.
Search Term | Tool | Matches in "searching" |
"search" | search_in_file | Yes (partial match) |
"search" | exact_word_search | No (exact word only) |
"AI" | search_in_file | Yes (finds "Ressl AI" and "AIR") |
"AI" | exact_word_search | Only "Ressl AI" (not "AIR") |
Run npm start to launch the inspector
Open the provided URL in your browser
Select a tool from the Tools tab
Enter the required parameters
Click Execute to see results
Search for an exact word match within a specified file. Only matches complete words, not partial matches.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the file to search in | |
| word | Yes | Exact word to search for in the file | |
| caseSensitive | No | Whether the search should be case sensitive |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It clearly describes the matching behavior ('exact word match', 'complete words, not partial matches'), which is valuable. However, it doesn't mention error handling, performance characteristics, or what happens if the file doesn't exist, leaving some behavioral aspects unspecified.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is perfectly concise with two sentences that each earn their place. The first sentence states the core functionality, and the second sentence provides crucial behavioral clarification about exact vs. partial matching. No wasted words or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search operation with 3 parameters), no annotations, and no output schema, the description does well by clearly explaining the exact matching behavior. However, it doesn't describe the return format or what happens on no matches, which would be helpful for a search tool without output schema documentation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description doesn't add any parameter-specific information beyond what's in the schema descriptions, but it does reinforce the 'exact word' concept for the 'word' parameter. This meets the baseline of 3 when schema coverage is high.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search for an exact word match') and resource ('within a specified file'), with explicit differentiation from partial matching. It distinguishes from the sibling tool 'search_in_file' by emphasizing exact word matching, providing clear purpose distinction.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context about when to use this tool ('Only matches complete words, not partial matches'), which implicitly suggests alternatives for partial matching. However, it doesn't explicitly name the sibling tool 'search_in_file' or provide explicit when-not-to-use guidance, keeping it at a 4 rather than a perfect 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search for a keyword within a specified file. Finds all occurrences including partial matches.
| Name | Required | Description | Default |
|---|---|---|---|
| filePath | Yes | Path to the file to search in | |
| keyword | Yes | Keyword to search for in the file |
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 tool's behavior of finding all occurrences with partial matches, which is useful. However, it lacks details on error handling (e.g., what happens if the file doesn't exist), output format (e.g., line numbers, context), or performance aspects like case sensitivity, which are important for a search operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences with zero waste: the first sentence states the core purpose, and the second adds critical behavioral detail (partial matches). It is front-loaded and appropriately sized, with every sentence earning its place by providing essential information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's moderate complexity (search operation with two parameters), no annotations, and no output schema, the description is minimally complete. It covers the basic purpose and key behavior (partial matches) but lacks details on output format, error handling, or advanced usage, leaving gaps that could hinder an AI agent's effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, meaning the input schema already fully documents the parameters 'filePath' and 'keyword'. The description adds no additional semantic details beyond what the schema provides (e.g., no examples, constraints, or usage tips), so it meets the baseline of 3 without compensating further.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the specific action ('Search for a keyword'), target resource ('within a specified file'), and scope ('Finds all occurrences including partial matches'). It distinguishes from the sibling tool 'exact_word_search' by explicitly mentioning partial matches, which implies the sibling likely does exact matches only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context for when to use this tool (searching within files for keywords with partial matching). However, it does not explicitly state when not to use it or name the alternative sibling tool 'exact_word_search' as a direct comparison, though the distinction is implied through the mention of partial matches.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The two tools have overlapping purposes, both searching within files, with only subtle differences in matching behavior (exact word vs. keyword with partial matches). This creates ambiguity, as an agent might struggle to choose between them without understanding the nuanced distinction, and they could easily be confused for similar tasks.
The tool names follow a consistent snake_case pattern (exact_word_search, search_in_file) and use clear verbs ('search'), which aids readability. However, the naming is not perfectly consistent, as one specifies 'exact_word' while the other uses 'in_file', but overall, the pattern is predictable and coherent.
With only 2 tools, the server feels thin and under-scoped for a general-purpose AI MCP server, suggesting limited functionality. This low count may not adequately cover the domain implied by the server name, potentially leaving gaps in capabilities and making it less useful for agents.
Inferred as a file search domain, the tool set is severely incomplete, lacking basic operations like listing files, reading file contents, or handling multiple files. The two tools only cover specific search variations, leaving significant gaps that will likely cause agent failures in broader tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Code intelligence for coding agents: semantic, AST, graph, and full-text search. 279+ languages.
Securely search and manage workspace context files for AI agents and teams.
Search your Obsidian vault to quickly find notes by title or keyword, summarize related content, a…
Search public open-source code, documentation, metadata, vulnerabilities, changelogs, and examples.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Vaishnavi-Raykar/mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
