Skip to main content
Glama
Majrooo

majrooo-mcp-devkit

by Majrooo

run_command_grep

Filter command output by regex pattern to extract only matching lines, solving the problem of long logs by searching for specific errors or tests directly.

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. Dates show when Glama detected each change.

  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?

With no annotations, the description carries the full burden and does well: it discloses case-insensitive regex, in-process filtering, safety-check parity with run_safe_command, and a limitation about overly long matches. Minor behavioral details like stderr handling or exit code preservation are not mentioned, but the core behavior is transparent.

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?

The description is informative but somewhat repetitive: the Unix grep replacement point is made twice, and the 'filters in-process' detail appears in adjacent sentences. It is not excessively long, but the redundancy and run-on structure prevent it from being tightly concise.

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 4 parameters, no output schema, and no annotations, the description provides enough context to invoke the tool correctly: purpose, alternatives, limitation, cwd handling, and safety checks. It does not detail return format or error behavior, but these are not critical for a line-filtering command tool with this level of explanatory depth.

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 the baseline is 3. The description adds extra meaning by explaining the cwd parameter's behavior ('always pass the cwd parameter' for non-primary projects) and emphasizes that the pattern is case-insensitive, which the schema does not state. This adds value beyond the schema definitions.

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 specific verb-resource pair: 'Runs a command and returns only lines matching the given pattern (case-insensitive regex).' It clearly distinguishes this tool from run_safe_command and positions it as a replacement for Unix grep, so an agent can tell exactly what it does.

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 this tool over run_safe_command ('when you know in advance that the output will be long and you only care about a specific pattern') and names alternatives for cases requiring more control (run_safe_command + read_log_slice). It also gives concrete examples like searching for 'error' in build output.

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

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/Majrooo/majrooo-mcp-devkit'

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