vibedeploy

Grep across a site's files

search_files

Read-onlyIdempotent

Search for a literal string or basic regex across all files in either the served dist or the editable source tree. Use this BEFORE batch-reading files to find candidates — saves the 'read 14 batches just to find which 3 files matter' round trip. Pass target: "source" to search the editable tree (requires Site.sourceStored=true).

Input Schema

TableJSON Schema

Name	Required	Description
`glob`	No	Filename glob filter, e.g. '.js' or '.{js,html}'. Applied via find before grep so we don't read non-matching files.
`name`	No
`regex`	No	When true, the pattern is interpreted as a basic regular expression. Default: false (literal substring match).
`siteId`	No
`target`	No	Where to search. 'dist' (default) searches the served files. 'source' searches the editable source tree (requires Site.sourceStored=true).
`pattern`	Yes	Pattern to search for. Treated literal by default; pass regex:true to use as a basic regex (BusyBox grep BRE — no PCRE features).
`maxMatches`	No	Cap on returned matches. Default 200, hard max 1000. Truncation is reported via budgetExceeded.
`caseInsensitive`	No	Default: false. When true, adds -i to grep.

Output Schema

TableJSON Schema

Name	Required	Description
`name`	Yes
`siteId`	Yes
`target`	Yes
`matches`	Yes
`totalMatches`	Yes
`budgetExceeded`	Yes	True if the search hit maxMatches and there are likely more matches not returned.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 6, 2026

removedOutput schema / properties / request_id

Removed value: -{
-  "description": "Server-assigned request correlation id. Quote it when contacting support.",
-  "type": "string"
-}

Changed1 schema field changedJul 20, 2026

addedOutput schema / properties / request_id

Added value: +{
+  "description": "Server-assigned request correlation id. Quote it when contacting support.",
+  "type": "string"
+}

First observedJun 29, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint and idempotentHint, and the description adds useful behavioral context: literal vs basic regex search, the two target trees, and the prerequisite for searching source. It doesn't mention truncation or return shape, but the output schema covers budgetExceeded, so this is a reasonable burden split.

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?

Three sentences, each earning its place: the first states what the tool does, the second gives a concrete usage directive, and the third explains the key parameter option. The most important differentiation is front-loaded.

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 a tool with 8 parameters, one required, an output schema, and safety annotations, the description covers the core decision points and workflow. It leaves name and siteId unexplained, but they are likely conventional context fields, and the schema covers pattern, regex, target, glob, maxMatches, and caseInsensitive.

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 75%, with name and siteId left undocumented in both schema and description. The description adds some value by explaining the target parameter's purpose and the source tree requirement, but it does not compensate for the two undocumented parameters.

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 names the exact verb and resource: 'Search for a literal string or basic regex across all files in either the served dist or the editable source tree.' It also distinguishes itself from batch-reading tools by framing it as the way to find candidates before reading, so an agent can tell this apart from read_files and related siblings.

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?

The description is explicit about when to use it: 'Use this BEFORE batch-reading files to find candidates' and gives a concrete cost-saving rationale. It also gives a conditional guidance for choosing the editable tree with target: "source", including the Site.sourceStored=true prerequisite.

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

All vibedeploy tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.