Skip to main content
Glama
AlaeddineMessadi

ContextPro

by AlaeddineMessadi
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

grep

Read-onlyIdempotent

Search the project's indexed files by literal string or regex to locate log messages, config keys, or error traces, while skipping binaries and respecting .gitignore.

Instructions

Fast literal or regex string search across the project's indexed file set. Use this for log-message lookups, config-key searches, error-message tracing, or any time you know the exact characters you want to find. Use 'search' instead for semantic intent queries. Skips binary files; respects .gitignore via the indexed walker.

Input Schema

NameRequiredDescriptionDefault
globNoOptional file glob filter, e.g. "src/**/*.ts" or "*.md". Comma-separated for multiple.
rootNoAbsolute project root. Required with linked worktrees; subagents must pass their own worktree root on every call.
regexNoTreat pattern as a line-based regular expression (set true for A|B alternation). Default: false, literal match.
patternYesLiteral string to search for (or regex when regex=true).
target_pathNoOptional subdirectory to scope the search.
context_charsNoCharacter window within the matched line; surrounding lines are clipped to this width. 40–400, default: 160. Use context_lines for nearby lines.
context_linesNoLines before and after each match (0–10, default: 0). Overlapping ranges are deduplicated; L<line>- marks context, L<line>:<column> marks a hit.
case_sensitiveNoMatch case-sensitively. Default: false.
max_file_bytesNoSkip files larger than this (bytes). Default: 1000000.
max_total_matchesNoMax total matches across all files. Default: 200.
max_matches_per_fileNoMax matches per file. Default: 10.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.4.0

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already establish read-only, idempotent, non-destructive, closed-world behavior, yet the description still adds real value by disclosing that binary files are skipped and that .gitignore is honored through the indexed walker — scope limits an agent cannot infer from annotations. It stops short of describing how results are shaped or truncated, which leaves a small gap.

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?

Four compact sentences, front-loaded with what the tool does, then when to use it, then the sibling alternative, then the behavioral caveat. Nothing is repeated from the schema and no sentence is filler.

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?

For an 11-parameter tool with no output schema, the description covers scope, filtering rules, and the alternative tool, which is most of what is needed. The remaining gap is return-value shape — the description never says results come back as file/line/column hits, leaving that to the context_lines schema text.

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%, so the schema already explains glob, root, regex, context_chars, context_lines, and the match caps in detail. The description only reinforces literal-vs-regex matching and adds no format, interaction, or defaulting guidance beyond the structured fields, so baseline 3 applies.

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?

Names a specific verb (search) plus the resource (indexed file set) and the two matching modes (literal or regex). It also explicitly separates itself from the semantic sibling by saying to use 'search' for intent queries, so an agent can choose without opening either 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?

Gives concrete use cases (log-message lookups, config-key searches, error-message tracing) and the decision rule: exact characters here, semantic intent in 'search'. That is both a when-to-use and a named alternative with the condition that selects it.

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

Deploy Server

Other Tools