all2md

Overview Schema Source Related Servers Discussions Admin

search_documents

Find the most relevant passages across many documents using keyword ranking or grep-style regex matching, returning ranked snippets with hit markers instead of whole files.

Instructions

Search a corpus of documents and return ranked snippets.

Instead of returning whole files, this tool returns the most relevant passages (with hit spans wrapped in << >> markers), so an agent can locate information across many documents cheaply.

Modes:

keyword: BM25 relevance ranking (requires the optional rank-bm25 dependency). Best for "find the most relevant passages" queries.
grep: literal/regex line matching. Best for "find every occurrence of X". Stateless, no extra dependencies.

Supports all formats the read tool supports (PDF, DOCX, HTML, etc.); files are converted to text before searching.

Returns a dictionary with:

results: list of {snippet, score, document_path, section_heading, chunk_id}
mode: the search mode used
total: number of results returned

Input Schema

Name	Required	Description	Default
`mode`	No	Search mode: 'keyword' (default, BM25 relevance ranking) or 'grep' (literal/regex line matching).	keyword
`paths`	No	Files, directories, or globs to search (each must be within the read allowlist). If omitted, the server's read allowlist is searched.
`query`	Yes	Search query. Natural language for keyword mode; a literal string (or regex) for grep mode. REQUIRED.
`regex`	No	Treat the query as a regular expression (grep mode only). Default: false.
`top_k`	No	Maximum number of results to return (default: 10).
`recursive`	No	Recurse into directories when collecting input files. Default: true.
`ignore_case`	No	Case-insensitive matching (grep mode only). Default: false.

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.19.0Nov 7, 2026

TDQS

A4.1/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 that keyword mode needs the optional rank-bm25 dependency, that grep is stateless, that files are converted to text first, and that hit spans are marked with << >>. It omits permission/allowlist behavior (only in the schema) and any performance or size limits.

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

Conciseness4/5

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

Front-loaded with purpose then structured into modes and return shape; every section is scannable. The return dictionary listing is partly redundant given an output schema exists, which costs a bit of tightness.

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?

Covers purpose, mode tradeoffs, format support, and conversion behavior for a 7-parameter search tool. Because an output schema exists, the return-value enumeration is unnecessary, and allowlist scoping is left entirely to the schema.

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 baseline is 3. The description corroborates mode semantics and the format support, but adds little parameter meaning beyond what the schema already documents for paths, regex, top_k, and recursive.

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 and resource ('search a corpus of documents and return ranked snippets') and immediately contrasts it with the sibling read tool by explaining it returns passages rather than whole files. An agent can distinguish it from read_document_as_markdown 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 Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives explicit when-to-use guidance for each mode: keyword for 'find the most relevant passages', grep for 'find every occurrence of X'. It does not explicitly say when to prefer this over list_workspace_files or when a direct read is better, but the mode routing is clear.

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

Deploy Server