Skip to main content
Glama
Majrooo

majrooo-mcp-devkit

by Majrooo

run_command_grep

Destructive

Run any command and return only lines matching a case-insensitive regex pattern. Filters long output in-process, replacing Unix grep, to find errors or specific tests.

Instructions

Runs a command and returns only lines matching the given pattern (case-insensitive regex). Use instead of run_safe_command when you know in advance that the output will be long and you only care about a specific pattern (e.g. searching for 'error' in build output, finding a specific test in test runner output). The command runs in the directory given by the cwd parameter and is subject to the same safety checks as run_safe_command. This is the replacement for Unix 'grep' on Windows — filtering happens in-process, so grep/head/tail are not needed. LIMITATION: The matches themselves can be too long — if you need more control, use run_safe_command first and then read_log_slice on the saved log file. Instead of Unix patterns like 'cmd /c ... | findstr ... & echo DONE' use THIS tool with a pattern — it filters in-process. If the task targets a project other than the primary one (MCP_PROJECT_ROOT), always pass the "cwd" parameter. Get the list of allowed roots via the "list_allowed_roots" tool.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
cwdNoThe directory in which the command will be run (must be inside MCP_PROJECT_ROOT / MCP_EXTRA_ROOTS). Default: the primary project (MCP_PROJECT_ROOT).
commandYesCommand to execute
patternYesPattern (regular expression) to filter lines
timeoutMsNoTimeout in milliseconds (1,000 – 600,000, default 60,000). You can extend it for longer tests/builds, e.g. 180,000 for jest.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and openWorldHint=true, so the description's job is lighter. It adds real context: it is 'subject to the same safety checks as run_safe_command', filtering is in-process, the Windows grep replacement rationale, and an explicit LIMITATION about over-long matches. It does not spell out the destructive/command-execution risk itself, but the safety-check statement covers most of what an agent needs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loaded and purposeful, but the Windows/grep and 'use THIS tool with a pattern' points are made across multiple sentences and overlap with the LIMITATION note, so a few sentences do not fully earn their place.

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?

No output schema exists, but the description implies the return is filtered matching lines. Combined with annotations covering safety and instructions covering cwd, timeouts, and alternatives, an agent has enough to call it correctly; only the exact return shape (e.g. whether line numbers/context are included) is unstated.

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%, so baseline is 3, but the description adds semantics the schema lacks: the pattern is a case-insensitive regex, and cwd scoping ties to MCP_PROJECT_ROOT/MCP_EXTRA_ROOTS with a pointer to list_allowed_roots. It also notes when to always pass cwd (non-primary projects).

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?

States a specific verb+resource ('Runs a command and returns only lines matching the given pattern') and immediately distinguishes itself from the sibling run_safe_command by scope. An agent can pick this without opening the schema.

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 use it ('when you know in advance that the output will be long and you only care about a specific pattern'), names the alternative (run_safe_command) and the fallback (read_log_slice). Also tells the agent what NOT to do (Unix pipes/findstr).

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