Skip to main content
Glama

Book Cover Generator

Create a book cover

create_cover
Read-only

Draw a book cover. Answers with the picture, links to the image (SVG and PNG) and to edit it in the app, and the style, palette and seed it used.

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": {
      "title": "<title>"
    },
    "name": "create_cover"
  }
}

Input Schema

NameRequiredDescriptionDefault
svgNoAlso answer with the SVG markup (large).
caseNoThe title in capitals, or as typed.
fontNoThe title's font instead of the style's: serif, didone, garamond, sans, geometric, humanist, condensed, display, mono.
langNoThe text's language, a tag such as tr or zh-Hant, for its capitals (Turkish İ) and letterforms. Default: from the text.
seedNoEvery random choice comes from it: the same seed draws the same cover; another, a variation.
badgeNoA seal in a corner, such as "Winner of the Hugo Award".
genreNoWith no style, pick one that suits a genre: literary (Literary), thriller (Thriller & crime), horror (Horror), romance (Romance), fantasy (Fantasy & sci-fi), children (Children’s), nonfiction (Non-fiction).
styleNoA style, by id or name (see list_styles), or "random" (the default: the seed picks one).
titleYesThe book's title. A line break (\n) breaks its line on the cover.
authorNoThe author's name.
colorsNoYour own colours instead of a palette, as hex.
creditNoA credit under the subtitle, such as "Translated by Ann Lee".
formatNopaperback, ebook, square, or a size in px such as 1600x2560 (Kindle). Default: paperback (2:3).
seriesNoA series line above the title, such as "Book Two of the Ember Cycle".
paletteNoA palette, by id or name (see list_palettes), or "auto" (the default: the seed picks one).
textureNoA fine film grain.
subtitleNoA subtitle or tagline.
variantsNoChoices a style lets you pin, as list_styles shows them, such as { "scene": "forest" }.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.8/5.0
Behavior4/5

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

Annotations cover the safety profile (readOnlyHint=true, openWorldHint=false), and the description adds genuinely useful behavior: it returns the rendered image, links to SVG/PNG, an in-app edit link, and the style/palette/seed used — the latter enabling reproducible iteration. It omits generation latency and any note on where the artifact persists.

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?

Two short sentences, zero filler, with the action front-loaded and the return contract immediately after. Every clause carries information an agent needs.

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 an 18-parameter, nested-object generative tool with no output schema, the description gives a compact but sufficient account of both action and response. The main gap is that return details (image delivery, link lifetime, whether the seed round-trips for re-renders) are only summarized in one clause.

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 18 parameters are already well documented in the schema. The description adds only indirect hints ("the style, palette and seed it used") and no new semantics for options like variants, format, or colors, so baseline 3 applies.

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?

"Draw a book cover" names a specific verb and resource, and the second sentence lists exactly what comes back (picture, SVG/PNG links, edit link, style/palette/seed). It is clearly a generative image tool rather than a palette/style lister, though it never explicitly contrasts itself with create_mockup.

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 rather than stated: an agent can infer this is the tool for producing a cover, but there is no when-to-use/when-not guidance and no routing to create_mockup or to list_styles/list_palettes for discovery (those are only referenced inside schema properties).

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.