Encryptor MCP

read_file

Read-only

Read text files from an unlocked Cryptomator vault, retrieve long files in parts with offset and max character limits, and log the reason for access. Binary files are not returned as text.

Instructions

Read a text file from an open vault. purpose: a few words on why (kept in the log). offset and max_chars read a long file in parts. Pictures and other binary files aren't returned as text.

Input Schema

TableJSON Schema

Name	Required	Description
`path`	Yes	A path inside the vault, from its top, for example 'Taxes/2025/receipts.md'.
`vault`	Yes	The vault's name, as listed by the vaults tool, for example 'Taxes'.
`offset`	No	Where to start reading, in characters from the start of the file. Use it to read a long file in parts.
`purpose`	Yes	A few words on why, shown to the user or kept in the vault's change log.
`max_chars`	No	The most characters to return at once.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.1.4Oct 21, 2026

addedInput schema / properties / max_chars / description

Added value: +"The most characters to return at once."

addedInput schema / properties / offset / description

Added value: +"Where to start reading, in characters from the start of the file. Use it to read a long file in parts."

addedInput schema / properties / path / description

Added value: +"A path inside the vault, from its top, for example 'Taxes/2025/receipts.md'."

addedInput schema / properties / purpose / description

Added value: +"A few words on why, shown to the user or kept in the vault's change log."

addedInput schema / properties / vault / description

Added value: +"The vault's name, as listed by the vaults tool, for example 'Taxes'."

First observedv0.1.3Oct 20, 2026

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile, but the description adds meaningful context: the purpose string is logged, and pictures/binary files are not returned as text. These are behavioral facts not present in the structured fields.

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?

Compact and front-loaded, leading with the core action before caveats. The compressed phrasing is efficient, though the fragmentary style ('purpose: a few words on why') is slightly terse.

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?

With an output schema present, return values need no explanation, and the description still covers the key caveat (binary files excluded) and the part-reading mechanism. It omits prerequisites like the vault needing to be unlocked, but 'open vault' hints at this.

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 the schema already documents all five parameters thoroughly. The description reinforces offset/max_chars for part-wise reading and purpose for logging, but adds no syntax or format details beyond the schema. Baseline 3 applies when the schema carries the load.

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 a text file from an open vault') and adds a scope boundary by excluding binary files. It does not explicitly distinguish itself from siblings like file_info or find, but the verb+resource is unambiguous.

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?

It implies usage by noting offset and max_chars let you 'read a long file in parts,' which is a real when-to-use cue. However, it never names alternatives (e.g., use file_info for metadata, find to locate a path) or states when-not to use it, leaving routing to inference.

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

Deploy Server