Skip to main content
Glama
sapn95

epost-mcp

by sapn95
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Local

epost_read_storage_document

Retrieve metadata for one stored ePost document—sender, subject, type, date, amount, folder—and optionally save it as PDF/EML. Classify archived letters when only "Gescannter Brief" is shown.

Instructions

Open one Storage document and report what the portal knows about it: the real sender/subject line, document type, date, amount and current folder. The card list only ever shows "Gescannter Brief", so this is the only way to classify an archived document. Pass output_dir to also save the document: the PDF, or the e-mail (.eml) for a letter that came through IncaMail. Over the API the document is resolved against a listing of at most limit — the reply says so when that window came back full.

Input Schema

NameRequiredDescriptionDefault
indexNo
limitNohow much of Storage to resolve against (API only, default 1000)
titleNo
folder_idNo
letter_idNo
output_dirNosave the document here as well (.pdf, or .eml for an e-mail)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.15.0
    • addedInput schema / properties / limit
      Added value: +{
+  "description": "how much of Storage to resolve against (API only, default 1000)",
+  "minimum": 1,
+  "type": "number"
+}
    • changedInput schema / properties / output_dir / description
      Previous value: -"save the PDF here as well"New value: +"save the document here as well (.pdf, or .eml for an e-mail)"
  2. First observedv0.11.0

TDQS

A4/5.0
Behavior4/5

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

There are no annotations, so the description carries the full burden, and it does disclose meaningful behavior beyond the schema: the write side effect of output_dir (PDF vs .eml for IncaMail), and critically that over the API the document is resolved against a listing bounded by `limit`, with the reply flagging when that window came back full. It omits auth/permission requirements and failure behavior, so it is good but not complete.

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?

Front-loaded with the action and return payload, then the routing rationale, then the optional save, then the API caveat. Roughly three sentences and all of them carry information, though the `limit`-window sentence is dense and arguably could be tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with no output schema and no annotations, the description usefully enumerates the returned fields and the save behavior. However, with four undocumented identifier parameters and no required parameters, an agent has no clear signal about how to target a specific document, which is a real completeness gap for a read tool.

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 coverage is only 33% (2 of 6 parameters described), so the description must compensate and it only partially does: it explains what output_dir does and elaborates on the `limit` resolution window and its truncation signal. The four identification parameters (index, title, folder_id, letter_id) remain unexplained, leaving an agent unsure which identifier to pass or how they interact.

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 concrete verb and resource ('Open one Storage document and report what the portal knows about it') and enumerates the returned facts (sender/subject, type, date, amount, folder). It also distinguishes itself from the list tools by explaining that the card list only shows 'Gescannter Brief', so an agent can tell this apart from epost_list_storage_documents without opening the schema.

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 a clear condition for use: it is 'the only way to classify an archived document' because the card list shows only a generic label. It also explains the optional save path via output_dir. It stops short of naming explicit alternatives (e.g., list_storage_documents vs get_letter for non-storage mail) or stating when not to use it, so it is not a full when/when-not block.

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