Skip to main content
Glama
cygnussystems

cygnus-ssh-mcp

Official

ssh_file_find_lines_with_pattern

Search a remote file for a text or regex pattern and return matching lines with line numbers. Use it to find exact lines before editing or viewing surrounding context.

Instructions

Search for a pattern in a remote file and return matching lines with their line numbers. Use this to find WHERE a pattern occurs before using ssh_file_get_context_around_line to see surrounding lines, or ssh_file_replace_line/ssh_file_delete_line_by_content to edit (those require an exact, unique line match - this tool helps you find that exact line first).

Regex flavor differs by platform when regex=True: POSIX extended regex (grep -E) on Linux/macOS - avoid PCRE-only syntax like \d, use [0-9] or [[:digit:]] instead; Python's re module on Windows (matched locally after an SFTP read, not via PowerShell - see below). When regex=False (default), the pattern is matched as a literal fixed string on every platform.

On Windows, this reads the whole file via SFTP and matches locally in Python, rather than shelling out to PowerShell/Select-String - matched line content could otherwise come back corrupted for non-ASCII text, since Windows' console encodes stdout in its OEM code page rather than UTF-8 (the same problem ssh_file_read's SFTP approach avoids).

Returns: {'total_matches': int, 'matches': [{'line_number': int, 'content': str}, ...]}. No matches is not an error - total_matches is 0 and matches is []. On failure (e.g. file not found, permission denied), an 'error' key is present instead.

Long-running calls: if this takes longer than the server's wait cap (default 50s), it
returns {"status": "in_progress", "handle_id": ...} instead of the result - the work keeps
running. Get the result by polling ssh_cmd_check_status(handle_id=...), which returns this
tool's normal response once finished. Do not call it again meanwhile. Only one such
operation runs at a time; another one started meanwhile fails with a 'busy' error.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
regexNoWhether to treat pattern as a regular expression
patternYesText or regex pattern to search for
use_sudoNoUse sudo for the operation
file_pathYesPath to the file to search

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.3.0

TDQS

A4.8/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden and does so richly: per-platform regex flavor (POSIX ERE on Linux/macOS vs Python re on Windows), the local-SFTP-read rationale on Windows, error-key semantics, and the long-running in_progress/handle_id polling contract via ssh_cmd_check_status with a 'busy' single-op constraint.

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 and sibling routing, then regex/Windows rationale, then returns, then long-running behavior. It is long, but nearly every sentence carries non-obvious operational value rather than restating structured fields.

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

Completeness5/5

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

For a search tool with an output schema already present, everything an agent needs is covered: return shape, no-match-is-not-an-error semantics, error key, and the async polling path. Nothing material is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3, but the description goes further by explaining regex semantics that the schema only gestures at: the exact regex dialect per platform and the PCRE-pitfall example (\d vs [0-9]/[[:digit:]]), plus that regex=False means a literal fixed-string match. use_sudo is left to the schema.

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 (search), resource (a remote file), and scope (return matching lines with line numbers). It is immediately distinguishable from siblings like ssh_file_read (whole file) and ssh_dir_search_files_content (directory-wide).

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?

Explicitly routes the agent: use this to find WHERE a pattern occurs, then ssh_file_get_context_around_line for surrounding lines, or ssh_file_replace_line/ssh_file_delete_line_by_content for editing. It even names the prerequisite those edit tools have (exact, unique line match) that this tool helps satisfy.

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