Skip to main content
Glama
julianbei

ARNO

by julianbei
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Go
Local

arno.read_range

Read-only

Read a file verbatim, whole or by line range, replacing cat and sed -n. Batch several ranges across files in one call.

Instructions

Read a file verbatim, whole or by line range — the replacement for cat and sed -n. Omit both line numbers to read the whole file, which is how to read go.mod, a Makefile, or any JSON/YAML/TOML config that has no symbols to address. An end line past the end of the file reads to the end. A dependency's source reads as dep:/, read-only. Several ranges, in one file or many, go in one call: {"ranges": [{"path": "a.go", "lines": "280-400"}, {"path": "b.go", "lines": "700-760"}]}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathNoRepository-relative or workspace-relative file path.
rootNoWorktree for this call. Default: the one set with workspace, else the start tree.
linesNoLine range: "280-400", "280-" to the end, or "280". Omit to read the whole file.
budgetNoSize of the read in tokens (default 5000). Cut at whole lines; the rest is behind continue=<handle>.
rangesNoSeveral reads in one call, instead of path. A range that fails reports its error without failing the others.
continueNoHandle from a cut read: the rest of it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.0.17
    • changedInput schema / properties / root / description
      Previous value: -"Worktree of this repository to act in. Defaults to the session's workspace."New value: +"Worktree for this call. Default: the one set with workspace, else the start tree."
  2. Changed1 schema field changedv0.0.15
    • addedInput schema / properties / root
      Added value: +{
+  "description": "Worktree of this repository to act in. Defaults to the session's workspace.",
+  "type": "string"
+}
  3. Addedv0.0.12

TDQS

A4/5.0
Behavior4/5

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

readOnlyHint=true already establishes the safety profile, but the description adds real behavior beyond it: an end line past EOF reads to the end, dependency sources appear as dep:<name>/<path> read-only, and a failing range does not abort the others. It does not mention output format, which is acceptable given no output schema.

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?

Dense but front-loaded: the core verb/resource leads, followed by the whole-file rule, the EOF edge case, and finally the batching example. The inline JSON example is long but does genuine work by demonstrating the multi-range shape.

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 6-param read-only tool with no output schema, the description covers the operation, the two read modes, multi-range batching, error isolation, and the budget/continue mechanism. Nothing an agent needs to call it correctly appears missing, though the `root` semantics are left entirely to the schema.

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 the baseline is 3. The description still earns credit by explaining range edge-case semantics ('an end line past the end of the file reads to the end') and by showing a concrete multi-range payload that clarifies how `ranges` and `lines` interact.

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?

The opening states a specific verb and resource with scope: 'Read a file verbatim, whole or by line range,' and frames it via the familiar 'replacement for cat and sed -n'. It never names a sibling (e.g. arno.grep or arno.find) to draw the boundary, so differentiation is implied rather than explicit.

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?

Gives clear context for the whole-file mode ('how to read go.mod, a Makefile, or any JSON/YAML/TOML config that has no symbols to address') and demonstrates batched ranges. It stops short of an explicit when-not/use-instead rule against the symbol-oriented siblings.

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