Skip to main content
Glama
alfaarghya

MCP keyword search

by alfaarghya

MCP keyword search

A Model Context Protocol (MCP) server that provides keyword search functionality within files

๐Ÿš€ Installation

Step 1: Clone or Create Project

git clone https://github.com/alfaarghya/mcp-keyword-search
cd mcp-keyword-search

Step 2: Install Dependencies

pnpm install

This will install:

  • @modelcontextprotocol/sdk - MCP SDK

  • @types/node - TypeScript definitions for Node.js

  • typescript - TypeScript compiler

Related MCP server: MCP-Grep

๐Ÿ”จ Building the Project

Compile TypeScript to JavaScript:

pnpm run build

This creates a dist/ folder with compiled JavaScript files.

Development Mode (auto-rebuild on changes):

pnpm run dev

๐Ÿงช Testing

Using MCP Inspector

The MCP Inspector provides a visual web interface for testing.

Step 1: Start the Inspector

npx @modelcontextprotocol/inspector node dist/index.js

Step 2: Open in Browser

Navigate to the URL shown

Step 3: Test the Tool

  1. In the web interface, you'll see "search_file" in the tools list

  2. Click on it to expand the input form

  3. Enter the following test data:

{
  "file_path": "./sample.txt",
  "keyword": "Hello",
  "case_sensitive": false
}
  1. Click "Execute" or "Run Tool"

Expected Output:

Found 3 match(es) for "hello" in ./test.txt:

Line 1 (position 0): Hello World! This is a test file.
Line 3 (position 0): Hello again on line 3.
Line 5 (position 0): HELLO in uppercase.

๐Ÿ”ง API Reference

Server Information

  • Name: file-search-server

  • Version: 1.0.0

  • Protocol: Model Context Protocol (MCP)

  • Transport: stdio

Available Tools

search_file

Searches for a keyword within a file.

Input Schema:

{
  file_path: string;      // Required: Path to file
  keyword: string;        // Required: Search keyword
  case_sensitive?: boolean; // Optional: Case sensitivity (default: false)
}

Output:

  • List of matching lines with line numbers and positions

  • Or error message if file not found or other issues

Available Tools

1 tool
search_fileA

Search for a keyword within a file and return all matching lines with line numbers

ParametersJSON Schema
NameRequiredDescriptionDefault
keywordYesThe keyword to search for
file_pathYesThe path to the file to search
case_sensitiveNoWhether the search should be case-sensitive (default: false)

TDQS

A4/5.0
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 that the tool performs a search and returns matching lines with line numbers, which implies a non-destructive read operation. However, it does not mention error cases (e.g., file not found), case-sensitivity behavior (though covered in schema), or whether the search is limited to the first match or all matches. 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 sentence that front-loads the action ('Search'), specifies the target ('a file'), and states the output. There is no wasted wording or redundancy, making it highly efficient.

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 low complexity (3 parameters, no nested objects, no output schema), the description is largely complete. It explains what the tool does and what it returns. However, it does not mention potential edge cases like empty results or file access errors, which could be relevant for an agent invoking the tool. Still, it is sufficient for a straightforward search operation.

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%, with all three parameters (file_path, keyword, case_sensitive) having descriptions. The tool description itself does not add meaning beyond the schema, so the baseline of 3 is appropriate. The description's mention of 'matching lines with line numbers' clarifies the output but does not enhance 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?

The description uses a specific verb ('Search') and resource ('a file'), and specifies the output ('return all matching lines with line numbers'). This clearly distinguishes it from other search tools and leaves no ambiguity about the tool's function.

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 clearly states what the tool does and the context in which it is used (searching within a file). While there are no explicit exclusions or alternatives, the purpose is self-evident given the tool's name and description. Since there are no sibling tools, this is sufficient.

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

TDQS

A3.9/5.0
Disambiguation5/5

With only one tool, there is no ambiguity or risk of confusing it with others. The tool's purpose is clearly defined as searching for a keyword within a file.

Naming Consistency5/5

The tool name follows a clear verb_noun pattern: search_file. This is consistent and predictable, even with only a single tool.

Tool Count3/5

A single tool is extremely minimal, but for a server specifically focused on keyword search in files, it might be acceptable. However, it feels thin and could benefit from additional related tools like directory search or multi-file search.

Completeness1/5

The server only supports searching within a single file, lacking capabilities such as directory-wide search, regex support, or multi-file search. These are significant gaps for a keyword search tool, rendering the surface severely incomplete.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • A
    license
    Not graded
    quality
    D
    maintenance
    A server implementation that exposes grep functionality through the Model Context Protocol, allowing MCP-compatible clients to search for patterns in files using regular expressions.
    24
    GPL 3.0
  • A
    license
    A
    quality
    D
    maintenance
    A Model Context Protocol server that provides tools to find regex pattern positions in files and list allowed directories, enabling text analysis with LSP-like functionality.
    2
    1
    1
    MIT
  • A
    license
    Not graded
    quality
    A
    maintenance
    A Model Context Protocol server that enhances AI agents by providing deep semantic understanding of codebases, enabling more intelligent interactions through advanced code search and contextual awareness.
    88
    MIT

Latest Blog Posts

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/alfaarghya/mcp-keyword-search'

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