Epublys

edit_epub_metadata

Edit metadata fields in an EPUB file (title, author, language, publisher, description, series, cover image, etc.). Returns the modified EPUB.

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": {
      "file": "<file>"
    },
    "name": "edit_epub_metadata"
  }
}

Input Schema

Name	Required	Description
`date`	No
`file`	Yes	Base64-encoded EPUB file content
`isbn`	No
`name`	No	Original filename — the output is named after its stem (e.g. "Book.epub" gives "Book (compressed).epub"); without it the output keeps a fixed name
`cover`	No	Base64-encoded cover image (JPEG or PNG, max 5MB)
`title`	No
`author`	No
`series`	No
`authors`	No	Comma-separated list of authors
`language`	No
`subjects`	No	Comma-separated list of subjects/tags
`publisher`	No
`description`	No
`seriesPosition`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

B3.4/5.0

Behavior4/5

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

With no annotations present, the description carries the behavioral burden and does disclose real constraints: file-size caps per tier, daily/rate limits, branding in free-tier output, and the escalation path on refusal. It omits what happens to metadata fields not supplied (preserved vs cleared) and whether cover replacement has side effects.

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?

The purpose and return value are front-loaded in one sentence, followed by a compact limits block and a single escalation line. The pricing-tier paragraph is somewhat boilerplate-heavy for an invocation guide, but each sentence serves the freemium workflow.

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 14-parameter mutation tool with no annotations and no output schema, the definition covers purpose, return value, limits, and error routing adequately. It leaves significant gaps around partial-update semantics and the author/authors and series/seriesPosition relationships, which are exactly what an agent needs to call it correctly.

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

Parameters2/5

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

Schema coverage is only 36%, so the description should compensate, but its parenthetical field list largely repeats names already visible in the schema. It gives no help on the ambiguous pairs (author vs authors, series vs seriesPosition) or on formats for date and isbn, which are undocumented in both places.

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 ("Edit metadata fields in an EPUB file") and enumerates the editable fields, plus notes it returns the modified EPUB. It does not distinguish itself from the sibling read_epub_metadata, so an agent must infer read-vs-write from the verb alone.

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?

Usage is implied by the verb, and there is one genuinely useful routing rule: on daily_limited or Pro-only errors, call upgrade_to_pro with a checkout link. However, nothing tells the agent to inspect metadata first via read_epub_metadata, nor whether partial field updates are allowed.

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

All Epublys tools Inspect

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.