Skip to main content
Glama
MortalPastry

wyrd-mcp

by MortalPastry
OverviewSchemaRelated ServersScoreDiscussions
JavaScript
Local

wyrd

An MCP server that exposes one folder of Markdown to an AI client, read-only.

Point Claude Code, Codex, Cursor, ChatGPT or Claude Desktop at a folder of notes and let it read them. Wyrd serves exactly the folder you grant and refuses everything else, and it tells you plainly what that means before you grant anything.

If the folder happens to be a Mage vault — one organised into Arc/ and Mage/ layers — wyrd notices and says which layers it found. If it is an ordinary folder of notes, it works the same way; vault structure is a detected bonus, never a requirement.

Install

npm install -g wyrd-mcp

Node 20 or newer.

Related MCP server: Obsidian MCP Tools

Use

Wyrd refuses to start until you grant it a folder. Grant one on the command line or in the environment:

wyrd-mcp --grant /absolute/path/to/notes
WYRD_GRANT=/absolute/path/to/notes wyrd-mcp

Claude Code — save as wyrd.mcp.json and pass --mcp-config wyrd.mcp.json:

{
  "mcpServers": {
    "wyrd": {
      "command": "wyrd-mcp",
      "args": ["--grant", "/absolute/path/to/notes"]
    }
  }
}

Codex — MCP servers arrive as config overrides:

codex exec -c 'mcp_servers.wyrd.command="wyrd-mcp"' \
           -c 'mcp_servers.wyrd.args=["--grant","/absolute/path/to/notes"]' "..."

Other clients take a command and args in their own MCP configuration; the shape is the same.

What it can reach — read this before granting

Wyrd serves the folder you name, read-only. It does not serve anything above it.

⚠ EVERY file inside that folder can be read, of any type, including hidden files and directories such as .git, .env and .ssh. There is no extension filter and no ignore-file support. Grant a subfolder containing only what you mean to share.

A path that resolves outside the granted folder is refused, and the refusal names the rule that fired rather than pretending the file is absent.

Known limits, stated before you grant rather than after

A containment claim without its limits would be false, so:

  • A hard link created inside the granted folder can reach a file outside it.

  • A path component swapped between validation and opening may be read instead of the one checked. Both of these need write access to the granted folder.

  • Some filesystem reparse points are invisible to this runtime and are not detected at all — not partially. ⚠ This one needs no attacker: an ordinary cloud-synced or WSL-mounted folder can contain one in normal use.

  • A refusal distinguishes "outside the grant" from "does not exist", which tells a caller one bit about whether a file outside the folder exists.

This list is what is known, not a proof that nothing else exists. The limits were measured on Windows; behaviour on macOS and Linux is reasoned but unmeasured, and the package declares no OS restriction.

What leaves your machine

Nothing, by wyrd. It is a local stdio server: it reads files and hands them to the client that launched it. It opens no network connection and phones nothing home.

⚠ What your AI client does with the content is between you and that client. Wyrd cannot see or control that, and no server on this side of the protocol can.

Tests

npm test              # the full battery
npm run test:portable # the arms that need no symlink privilege

⚠ npm test needs the Windows symlink privilege (Developer Mode, or an elevated shell) because most fence arms build link fixtures. Without it the suite refuses to run rather than skipping, so a green never means "the arms that could run, ran."

npm run test:portable runs the arms that need no privilege and states its own denominator — how many ran, how many were held back, and which. A green there is not a green fence; it is a partial run that says so.

Licence

MIT. See LICENSE.

wyrd — Old English, "that which has become": the accumulated weight of what has already happened, constraining what can happen next.

Available Tools

1 tool
readRead a file from the granted folderA

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.

ParametersJSON 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.

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.

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.7/5.0
Disambiguation5/5

Only a single tool exists, so there is no possibility of confusing it with another. The tool's purpose is singular and precisely described.

Naming Consistency5/5

The lone tool name 'read' is a clear, conventional verb that directly matches its action. There are no conflicting naming styles to evaluate.

Tool Count3/5

One tool is at the thin end of the range, but it serves a narrow, well-defined purpose (bounded reads from a single folder). The server is not bloated, yet it feels minimal.

Completeness3/5

The read operation itself is thoroughly implemented with offset pagination and encoding safeguards, but there is no way to list or stat files in the folder, forcing agents to know exact paths in advance.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • Obsidian MCP Tools

    dp-veritas
    A
    license
    Not graded
    quality
    D
    maintenance
    A read-only toolkit for searching and analyzing Markdown note directories and Obsidian vaults through AI clients. It enables metadata extraction, full-text search, and natural language querying of note content, tags, and backlinks.
    23
    4
    AGPL 3.0

  • mor

    laat
    A
    license
    Not graded
    quality
    A
    maintenance
    Enables AI assistants to search, read, create, update, and remove personal markdown notes stored locally, providing persistent memory across sessions.
    95
    2
    MIT

  • MCP Notes Server

    revanthpp
    A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to interact with a local folder of Markdown notes, supporting listing, reading, searching, creating, and appending to notes with strict security boundaries.
    5
    MIT

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