Claude File Manager MCP

Overview Schema Source Related Servers Discussions Admin

Search text inside files

search_content

Searches text files for a string or regular expression and returns matching file, line, and text; skips binary and oversized files.

Instructions

Searches for a string or regular expression inside text files and returns file:line: text. Binary and large files are skipped.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "query": "<query>"
    },
    "name": "search_content"
  }
}

Input Schema

Name	Required	Description	Default
`path`	No	Where to search	.
`query`	Yes	String or regular expression
`ignore`	No	Additional names/globs to skip
`include`	No	File glob, e.g. `.js` or `src//.ts`
`is_regex`	No	Treat query as a regular expression
`files_only`	No	Only list matching files with their match counts
`max_results`	No	Maximum number of matches
`context_lines`	No	Show this many lines before and after each match
`max_file_size`	No	Skip files larger than this size (bytes)
`case_sensitive`	No	Match case

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.3.0Nov 13, 2026

TDQS

A3.5/5.0

Behavior3/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 contribute real behavior: the `file:line: text` return format and the fact that binary and oversized files are silently skipped. It leaves out what happens at max_results (truncation vs error), the regex dialect supported, result ordering, and behavior on nonexistent paths.

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?

Two short sentences with zero waste: the operation and output format come first, the skip caveat second. Nothing is repeated or padded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 10-parameter, unannotated, no-output-schema tool, the description covers the essentials (what it searches, what it returns, what it skips) but omits truncation and regex-dialect details that matter when max_results defaults to 100 and can be capped at 2000.

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 every parameter including path, include, ignore, is_regex, and max_file_size is already documented in the schema. The description only echoes the string/regex choice and the large-file skip, adding no syntax or interaction detail beyond structured fields, which fits the baseline 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource — search for a string or regex inside text files — and adds the concrete return shape `file:line: text`. It is clearly a content search rather than a filename search, which implicitly separates it from find_files, but it never names or contrasts a sibling explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is only implied by the phrase 'inside text files'; an agent can infer this is the grep-style tool versus find_files or read_file. There is no explicit when-to-use, when-not-to-use, or named alternative, so routing still requires inference.

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