Skip to main content
Glama
MortalPastry

wyrd-mcp

by MortalPastry

Read a file from the granted folder

read

Read files from a granted local folder in byte-bounded slices; follow next_offset to retrieve truncated content and get clear refusals for out-of-folder paths.

Instructions

Read a byte-bounded slice of one file from the single folder this server was granted.

Paths are relative to the granted folder, for example Mage/projects/legend.md. Absolute paths, Windows drive-relative paths such as C:notes, and any path that climbs out with .. are refused.

Reads are byte-oriented, never character-oriented. offset and limit are byte counts into the file's UTF-8 encoding. A returned slice may be up to 3 bytes shorter than limit so that it ends on a whole codepoint.

If the file is longer than the slice, the response says truncated: true and gives next_offset. Call again with that offset to continue; following next_offset to exhaustion reconstructs the UTF-8 text byte for byte. This server never returns a silently shortened file — if content is missing, the response says so.

Every path is validated against the granted folder before anything is opened, and a refusal names the rule that fired rather than pretending the file is absent.

WHAT IS IN SCOPE, since the boundary is a folder and not a file type: EVERY file inside the granted folder can be requested, including hidden files and directories such as .git, .env and .ssh. There is no extension filter, no ignore-file support, and no cap on how much may be read in total. The granted folder is the whole of the restriction.

What comes BACK is text. A requested slice that is not valid UTF-8 is refused with NOT_TEXT rather than returned with substituted characters — a file that comes back altered but looks complete is worse than one that is refused. Note this is a property of the BYTES, not the file extension: a .bin whose contents happen to be valid UTF-8 is returned, and a .md saved in Latin-1 is refused. Nothing here is a filter on what may be reached.

KNOWN LIMITS of that restriction, stated because a containment claim without them would be false: a hard link created inside the folder can reach a file outside it; a folder or path component swapped after validation may be read instead of the one checked; and some filesystem reparse points are invisible to this runtime and are not detected at all — that last one needs no attacker and can occur in an ordinary cloud-synced folder. This list is what is known, not a proof that nothing else exists.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesPath to the file, relative to the granted folder. Forward or back slashes both work.
limitNoMaximum bytes to return. Defaults to 32768, capped at 262144.
offsetNoByte offset to start at. Defaults to 0. Use the `next_offset` from a truncated response.
Install Server

TDQS

A5/5.0
Behavior5/5

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

With no annotations, the description carries the full behavioral burden and does so thoroughly. It discloses byte-oriented reads, possible truncation with `next_offset`, refusal rules, the `NOT_TEXT` error for invalid UTF-8, and even known security limitations like hard links and reparse points. This is exemplary transparency beyond what the schema or annotations provide.

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 long, but every paragraph earns its place by adding operationally relevant detail. It is front-loaded with the core purpose, followed by path rules, byte semantics, scope, encoding behavior, and known limits, with clear section headers that make it easy for an agent to scan.

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?

Despite having no output schema, the description explains what the response will contain (`truncated: true`, `next_offset`, `NOT_TEXT` refusals) and covers all caller-relevant behavior. An agent has everything needed to use the tool correctly: path constraints, offset/limit semantics, continuation mechanism, edge cases, and security caveats.

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

Parameters5/5

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

Although the schema covers all three parameters, the description adds meaning beyond the schema by explaining that `offset` and `limit` are byte counts into UTF-8 encoding, that a slice may end up to 3 bytes shorter to preserve codepoints, and that callers should use `next_offset` from a truncated response. It also clarifies path semantics with concrete examples and refusal cases.

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 first sentence states a specific action and resource: 'Read a byte-bounded slice of one file from the single folder this server was granted.' It precisely defines scope and behavior, making it easy for an agent to know exactly what the tool does even without siblings to distinguish it from.

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?

The description gives explicit when-to-use and when-not-to-use guidance: every file inside the granted folder is in scope, absolute paths and `..` traversal are refused, and non-UTF-8 content is refused. The 'WHAT IS IN SCOPE' and 'KNOWN LIMITS' sections provide clear boundary conditions, which fully compensates for the absence of sibling tools.

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

Other Tools

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/MortalPastry/wyrd-mcp'

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