Skip to main content
Glama

ssh_log_search

Read-only

Search remote server log files by regex, returning matching lines and file paths. Handles unreadable files separately and can search inside containers by name.

Instructions

Greps log files on the server and returns the matching lines with their paths, or the paths alone when line bodies are not wanted. An empty answer means no match, never a failed search — files that could not be read are listed apart. For the tail of a file rather than a search through it, ssh_log_tail is cheaper. A container is searched by name instead of by path.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
fromNoWhich end maxMatches keeps: "end" newest (scans the whole file), "start" oldest (stops reading at the cap). Default: endend
pathNoOne path, a list, or a glob in the file name: "/var/log/*.log". Expanded by the server's find, not a shell — a name with a space or a newline stays one name. A glob in the directory part is refused.
sudoNoRead as root. Straight away for places a plain user cannot read (/root, /var/lib/docker); otherwise retry with true when the answer names what it could not read. Default: false
queryYesRegex, grep -E dialect.
sinceNoWindow: "today" | "2026-08-19" | "2h" | "3d", the day taken from the server. Skips files untouched in it (count reported). A window of a day or more then keeps only lines dated inside — 2026-08-19, Aug 19, 19/Aug/2026; a shorter one filters files and leaves their lines alone. Undated file: searched whole and named.
contextNoLines around each match, as grep -C. Excluded by namesOnly. Default: 0
profileYesMachine name.
timeoutNoMilliseconds per file, default 30000. Raise for multi-gigabyte files with from: "end".
containerNoRead this container's output instead of a file: docker is asked where it writes, and the answer names the file it read. Whatever cannot be read this way — a driver that keeps no file, an engine that is not docker, a name nothing answers to — comes back said aloud, naming ssh_exec as the way through. The file belongs to root, so sudo: true. Give this or path, never both.
namesOnlyNoAnswer = matching paths, no line bodies. One command for the whole list; maxMatches and context do not apply. Default: false
recursiveNoWalk the whole tree, not one level. With a glob: "/etc/nginx/*.conf" reaches those at any depth. Symlinked files are searched, symlinked dirs not descended. Default: false
maxMatchesNoCap per file; reaching it is reported. Default: 200
caseSensitiveNofalse = case ignored. Default: false

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
filesNoMatching file names, for namesOnly.
linesNoThe matching lines. context:true marks a neighbour shown alongside, not a match.
sourceNoNamed only when container was asked: the engine, the driver and the file the lines were read from.
limitedNomaxMatches was reached — more exist than are shown.
matchesNoLines in the answer — matches plus any context lines; with namesOnly, matching files.
truncatedNoOutput was cut mid-answer: incomplete, not empty.
files_skippedNoLeft unread by the since window.
files_undatedNoNo recognisable timestamp: searched whole, the window was not applied.
files_searchedNo
files_unreadableNoOpened with an error — not proof the text is absent.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed4 schema fields changedv2.3.3
    • addedInput schema / properties / container
      Added value: +{
      +  "description": "Read this container's output instead of a file: docker is asked where it writes, and the answer names the file it read. Whatever cannot be read this way — a driver that keeps no file, an engine that is not docker, a name nothing answers to — comes back said aloud, naming ssh_exec as the way through. The file belongs to root, so sudo: true. Give this or path, never both.",
      +  "type": "string"
      +}
    • changedInput schema / properties / since / description
      Previous value: -"Window: \"today\" | \"2026-08-19\" | \"2h\" | \"3d\", the day taken from the server. Skips files untouched in it (count reported), then keeps only lines dated inside — 2026-08-19, Aug 19, 19/Aug/2026. Undated file: searched whole and named. Under a day filters files, not lines."New value: +"Window: \"today\" | \"2026-08-19\" | \"2h\" | \"3d\", the day taken from the server. Skips files untouched in it (count reported). A window of a day or more then keeps only lines dated inside — 2026-08-19, Aug 19, 19/Aug/2026; a shorter one filters files and leaves their lines alone. Undated file: searched whole and named."
    • changedInput schema / required
      Previous value: -[
      -  "profile",
      -  "path",
      -  "query"
      -]New value: +[
      +  "profile",
      +  "query"
      +]
    • addedOutput schema / properties / source
      Added value: +{
      +  "description": "Named only when container was asked: the engine, the driver and the file the lines were read from.",
      +  "type": "string"
      +}
  2. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

The description adds significant behavioral clarity beyond the readOnlyHint annotation: an empty answer means no match, never a failed search, and unreadable files are listed apart. This prevents an agent from misinterpreting an empty result as an error. The readOnly annotation already covers mutation safety, so the added semantics are above baseline.

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 two dense sentences with no wasted words. The core purpose, output distinction, no-match semantics, failure handling, sibling alternative, and container usage are all packed in efficiently.

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?

With a full input schema and an output schema present, the description covers the non-obvious behavioral gotchas an agent needs: empty-result semantics, unreadable-file reporting, and the tail alternative. It could have mentioned the output structure explicitly, but the output schema already supplies that.

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 schema already documents every parameter thoroughly. The description reinforces the container-by-name notion and the line-bodies-versus-paths choice, but it does not add meaning beyond what the parameter descriptions already supply. Baseline 3 is appropriate.

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 opens with a precise verb and object: 'Greps log files on the server and returns the matching lines with their paths.' It also distinguishes the paths-only mode and immediately contrasts itself with ssh_log_tail, so an agent can disambiguate it from the closest sibling without inspecting 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?

It explicitly names when a sibling is cheaper: 'For the tail of a file rather than a search through it, ssh_log_tail is cheaper.' It also conveys the container-vs-path usage pattern. It does not enumerate all alternatives among the many siblings, but the relevant distinction is covered.

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

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/hypnosis/ssh-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server