Skip to main content
Glama
Sign In
Lizard MCP

Lizard MCP

Official
by lizard-build
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Read sandbox text file

sandbox_read_file
Read-onlyIdempotent

Reads up to 64 KiB of UTF-8 text from a specified Lizard sandbox, resolving relative paths from /workspace so agents can inspect remote files without using the MCP server's filesystem.

Instructions

Read up to 64 KiB of UTF-8 text from a sandbox. Relative paths start at /workspace. Paths refer to the remote sandbox, never the MCP server's files. Uses the Lizard API; docs: https://lizard.build/docs/.

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": {
      "sandboxId": "<sandboxId>",
      "path": "<path>"
    },
    "name": "sandbox_read_file"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYes
sandboxIdYesExact sandbox ID from sandbox_create or sandbox_list

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.2

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the description correctly focuses on what annotations cannot express: the 64 KiB read cap, UTF-8-only constraint, and relative-path resolution against /workspace. It stops short of stating what happens on truncation or non-UTF-8 input (error vs partial content).

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?

Three short sentences, front-loaded with the core action and cap, followed by path resolution and the remote/local distinction. The docs URL is the only debatable element and is cheap. Nothing is redundant.

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 a read-only annotation profile and no output schema, the description covers the key risks (remote vs local, size cap, encoding). The one gap is that it never describes the return payload shape or truncation signalling, which the absent output schema leaves unstated.

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 50%: sandboxId is documented in the schema but path is not. The description compensates by defining path semantics (relative paths start at /workspace, remote resolution), which is exactly the gap the schema leaves. It adds no detail beyond the schema for sandboxId, but that field is already covered.

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 and resource ('Read up to 64 KiB of UTF-8 text from a sandbox') with scope qualifiers (size cap, encoding). The sentence clarifying that paths refer to the remote sandbox, never the MCP server's files, separates it from repo_read_file and from any local-file interpretation.

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?

Usage is implied by the remote-sandbox scoping, but there is no explicit routing guidance such as 'use sandbox_list_files to discover paths first' or 'use repo_read_file for repo contents'. The agent must infer when this beats sandbox_exec or sandbox_list_files.

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