Skip to main content
Glama
Sign In

Epublys

by com.epublys
OverviewDiscussionsAdmin

markdown_to_epub

Build a valid EPUB3 ebook from Markdown files — one file per chapter, in array order. Understands YAML frontmatter (title/author) and Obsidian [[wikilinks]]; cross-file .md links are rewritten to chapter links inside the book. No Pandoc required.

Free tier: 5MB/file (10MB for pdf-to-epub, 15MB for split), 3 operations/day, 15 req/min, output includes Epublys branding. Pro ($9/mo): 30MB per operation, unlimited daily operations, 60 req/min, no branding.

When a call is refused with daily_limited or a Pro-only error, call the upgrade_to_pro tool — it returns a checkout link to hand the user. Details: https://epublys.com/pricing

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": {
      "files": "<files>"
    },
    "name": "markdown_to_epub"
  }
}

Input Schema

NameRequiredDescriptionDefault
filesYesMarkdown files, one per chapter, in reading order
titleNoBook title (defaults to frontmatter or first heading)
authorNoAuthor (defaults to frontmatter)
languageNoen

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does real work: per-file and per-operation size caps, daily operation quota, rate limit, and the fact that free-tier output carries Epublys branding. A 'No Pandoc required' note also sets expectations about dependencies. What it omits is the return shape — whether the EPUB comes back as base64, a URL, or a file handle — which matters for a binary-producing tool.

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 capability and its mechanics in two dense sentences, then a clearly separated tier/quota block. The pricing block is longer than ideal for a tool description, but it directly supports the documented refusal path to upgrade_to_pro, so it earns most of its space.

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 tool with no output schema and no annotations, it covers quotas, size ceilings, input conventions, and the escalation path — enough to call it correctly and predict failure modes. The one real gap is the return value: an agent still does not know the form of the produced EPUB.

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 75% and the schema already documents name/content, the frontmatter defaults for title/author, and the 300-char caps. The description reinforces the meaningful semantic ('one file per chapter, in array order') but adds little syntax or format detail beyond the structured fields, so it sits at the baseline for high-coverage schemas.

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 ('Build a valid EPUB3 ebook from Markdown files') and immediately narrows scope: one file per chapter, array order, YAML frontmatter and wikilink handling, link rewriting. That set of details cleanly separates it from docx_to_epub and pdf_to_epub without needing to name them.

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?

The input contract makes the use case clear (Markdown input, one file per chapter), and it explicitly routes a refusal case: on daily_limited or a Pro-only error, call upgrade_to_pro with a checkout link. It stops short of an explicit 'use this instead of docx_to_epub/pdf_to_epub when your source is Markdown' statement, so the sibling discrimination is implied rather than stated.

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

All Epublys toolsInspect
Try in Browser
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources