ftp-mcp

ftp_grep

Search remote files on FTP/SFTP for text or regex patterns, downloading each file to find matches. Filter by path, file pattern, depth, and case sensitivity.

Instructions

Search for text content within remote files (downloads and searches each file)

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": {
      "connection": "<connection>",
      "pattern": "<pattern>"
    },
    "name": "ftp_grep"
  }
}

Input Schema

Name	Required	Description
`path`	No	Starting directory (defaults to cwd)
`pattern`	Yes	Text or regex pattern to search for within files
`maxDepth`	No	Maximum search depth (default: 5)
`maxFiles`	No	Maximum files to search (default: 50)
`connection`	Yes	Connection name
`filePattern`	No	Glob pattern to filter which files to search (e.g., '*.txt')
`caseSensitive`	No	Case-sensitive search (default: false)

Schema Changelog

Changes observed during successful MCP inspections.

First observedv1.0.0Aug 9, 2026

TDQS

B3.4/5.0

Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only reveals that files are downloaded and searched, leaving unknown the return format, recursion behavior, handling of binary files, performance implications, and error conditions. This is insufficient for confident invocation.

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?

The description is a single sentence with no filler words. It front-loads the key action ('Search') and resource, making it appropriately concise and well-structured.

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

Completeness2/5

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

Given the tool's complexity (7 parameters, no output schema, no annotations), the description is too sparse. It fails to specify return values, search behavior on directories, or performance impacts, and relies entirely on schema for operational details, which is insufficient for a search tool that downloads files.

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?

All 7 parameters have descriptions in the schema (100% coverage), so the baseline is 3. The tool description adds no additional parameter semantics beyond the schema, such as pattern syntax or how maxDepth/maxFiles interact, but the schema already provides adequate parameter-level guidance.

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 clearly states the tool's function: 'Search for text content within remote files' with a specific verb and resource. The parenthetical '(downloads and searches each file)' adds operational clarity, distinguishing it from file listing or reading tools like ftp_list and ftp_read.

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?

The description implies a content-search use case but does not explicitly state when to prefer this over siblings like ftp_find (filename search) or ftp_list. There is no mention of exclusions or alternative guidance, leaving usage context implied rather than explicit.

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