Skip to main content
Glama
Sign In
raspberry-pi-connect-mcp

raspberry-pi-connect-mcp

by kritzerenkrieg
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

read_screen

Capture the current terminal screen and recent scrollback from a Raspberry Pi shell to inspect command output, prompts, or interactive program state.

Instructions

Read the current terminal screen (plus a little scrollback) of a device shell.

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": {
      "device": "<device>"
    },
    "name": "read_screen"
  }
}

Input Schema

NameRequiredDescriptionDefault
linesNoLast N lines (0 = screen + 20 lines)
deviceYesDevice name (or unique substring of it) or device UUID, as shown by list_devices

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.6/5.0
Behavior3/5

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

No annotations exist, so the description carries the full burden. It discloses that output includes 'a little scrollback' beyond the visible screen, which is meaningful behavioral context, and 'Read' implies a non-mutating operation. However, it does not state whether an active session is required, what happens if the device is unknown, or any capture limitations — gaps that matter for an unannotated tool.

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?

A single front-loaded sentence with zero filler. The scope qualifier and the scrollback note are packed in without any redundant restatement of the name or title.

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?

For a two-parameter read tool with no output schema and full schema coverage, the description covers what is read and from where, which is enough to call it correctly. Minor omissions — session preconditions and whether output is truncated — keep it from being complete.

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 both the device identifier and the lines/scrollback parameter are already documented in the schema. The description's mention of 'a little scrollback' loosely reinforces the lines default but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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 — 'Read the current terminal screen' — scoped to 'a device shell', which is clearly distinguishable from sibling write-oriented tools like run_command and send_keys. It stops short of naming any sibling or contrasting explicitly, so it lands at 4 rather than 5.

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?

There is no explicit statement of when to use this versus alternatives, nor any exclusions. Usage is only implied: an agent infers this is for inspecting terminal output before or after issuing commands. Adequate but leaves routing to the agent.

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

Deploy Server

Other Tools