Skip to main content
Glama
hoyt-harness

ProcExecMCP

by hoyt-harness

search_file_contents

Search for regex patterns in file contents, returning matches with line numbers and context lines for efficient code analysis.

Instructions

Search for patterns in file contents across a directory or file.

This tool uses ripgrep to efficiently search for regex patterns in files. It returns matches with line numbers and surrounding context lines.

Args: pattern: Regular expression pattern to search for path: File or directory path to search in case_sensitive: Whether search should be case-sensitive (default: True) file_types: File type filters (e.g., ['py', 'js']). None = all files exclude_patterns: Glob patterns to exclude (e.g., ['node_modules']) max_results: Maximum number of results to return (1-10000) context_lines: Lines of context before/after match (0-10) ctx: MCP context for logging (optional)

Returns: SearchFileContentsOutput with matches and metadata

Raises: ValueError: If input validation fails SanitizedError: If search execution fails

Examples: >>> result = search_file_contents("TODO", "./src", case_sensitive=False) >>> print(f"Found {len(result.matches)} TODO comments")

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYes
patternYes
file_typesNo
max_resultsNo
context_linesNo
case_sensitiveNo
exclude_patternsNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
matchesYesList of search matches found
truncatedYesWhether results were truncated due to max_results limit
total_matchesYesTotal number of matches found (may exceed returned matches if limited)
files_searchedYesNumber of files searched
search_time_msYesTime taken to complete search in milliseconds
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 the use of ripgrep, return type with matches and metadata, and error cases. However, it does not mention potential performance issues with large directories or default behavior like respecting .gitignore, which would be helpful.

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: a concise one-line summary, a brief paragraph about the tool, a detailed argument list, return/error info, and an example. It is front-loaded with the core purpose and each 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 7 parameters and only 2 required, the description covers all parameters, return type, and errors. The presence of an output schema (mentioned) reduces the need to detail return fields. An example is provided. For a tool of this complexity, it is very complete.

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 0% description coverage, meaning no parameter descriptions in JSON. The description compensates fully by listing all 7 parameters with clear explanations of their purpose and defaults. Examples further clarify usage.

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 a clear verb ('Search') and resource ('file contents'), specifying the action of pattern searching across a directory or file. It distinguishes from sibling tools (execute_command, list_processes, kill_process) which serve entirely different purposes.

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 how to use the tool (regex search, file type filters, context lines) but does not explicitly state when NOT to use it or mention alternatives among siblings. However, siblings are unrelated, so the lack of explicit exclusions is acceptable.

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

Install Server

Other Tools

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/hoyt-harness/ProcExecMCP'

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