Post Kit

Make a layered post cover

make_cover

Read-onlyIdempotent

Use this when the user wants a cover image for a post, article, note or product, such as "make a cover for my post about X". Pass idea, title (up to 8 words; write from the idea if omitted), subject (one concrete object to picture; write from the idea), and optionally subtitle, byline, reader, kind (article, note, ecommerce, product), style and formats. Returns the cover spec JSON with layers in occlusion order (background, subject, then title, subtitle and byline as live text), pixel positions per format (default Instagram 1080x1350 and X 1600x900), GPT image prompts, an SVG per format and a canvas link to move the title, scale the subject and export PNGs without remaking the picture. Draws no picture itself, publishes nothing and stores nothing.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`idea`	Yes	The post idea the cover is for, in one or two sentences
`kind`	No	article: Article or blog cover: a strong headline beside one clear picture; note: Note cover (Instagram or Xiaohongshu style): a large headline over a close, friendly picture; ecommerce: Shop poster: the product large in the middle, the offer in words; product: Product design shot: the object as a hero on a clean set, the name below	article
`split`	No	separate: two pictures, a background plate and a subject cutout; segment: one scene per size that a segmentation model cuts	separate
`style`	No	An account style preset, or your own style so every cover of one account looks alike	openkrill
`title`	Yes	The cover title, at most about 8 words; it stays live text
`byline`	No	Account or author name, for example @openkrill
`reader`	No	Who the post is for, for example 'founders who run AI agents'
`formats`	No	Sizes to lay out; the first is the size the pictures are made at
`subject`	No	One concrete object the picture shows, such as 'a glass jar of folded paper notes'; write one from the idea when the user gave none, since an idea alone gives a vague picture
`subtitle`	No	One short line under the title
`subject_url`	No	Your subject cutout, once made from the prompt
`background_url`	No	Your background picture, once made from the prompt

Output Schema

TableJSON Schema

Name	Required	Description
`svg`	Yes	The cover per format as SVG, the title as live SVG text
`spec`	Yes	The cover spec JSON: idea, style, layers in occlusion order, pixel positions per format and the image prompts
`status`	Yes
`summary`	Yes
`canvas_url`	Yes	Opens this cover on the canvas to move the title, scale the subject and export PNG files
`next_steps`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 23, 2026

addedInput schema / examples

Added value: +[
+  {
+    "byline": "tools.openkrill.app",
+    "idea": "A plain SQLite table with a status column is enough job queue for most small apps, no Redis needed.",
+    "subtitle": "One table, one status column, no Redis",
+    "title": "SQLite is your job queue"
+  }
+]

AddedOct 18, 2026

TDQS

A4.6/5.0

Behavior4/5

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

Goes well beyond the annotations by disclosing the return shape (layered spec in occlusion order, per-format pixel positions, GPT image prompts, SVG per format, a canvas link) and confirming the operation is non-publishing and non-storing, which is consistent with readOnlyHint/idempotentHint. It stops short of stating whether calls are rate-limited or what happens when idea and subject conflict, but with annotations covering the safety profile this is solid added context.

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 trigger and efficient throughout, but the second half is one very long run-on sentence that enumerates return artifacts already documented by the output schema. Trimming the return-value recital would make it sharper without losing information.

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

Completeness5/5

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

For a 12-parameter tool with an output schema, the definition covers the trigger, the required inputs, the defaults, the derived-input policy, and the side-effect profile, which is everything an agent needs to call it correctly. The return artifacts are over-explained rather than under-explained.

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

Parameters4/5

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

Adds real meaning beyond the 100%-covered schema: format defaults are spelled out in the description (Instagram 1080x1350 and X 1600x900), and the agent is told to synthesize subject and title from the idea when the user gives none. One flaw: it says title may be omitted ("write from the idea if omitted") while the schema marks title as required, which could cause a malformed call.

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?

Opens with a concrete trigger ("Use this when the user wants a cover image for a post, article, note or product") plus a literal example utterance, so the verb and resource are unambiguous. It then distinguishes itself from any draw/publish tool by stating "Draws no picture itself, publishes nothing and stores nothing" — an agent can separate it from draft_posts and draft_tiktok_slides without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Gives an explicit when-to-use condition with a sample user phrasing, and a clear when-not boundary set (no picture drawn, nothing published, nothing stored). It also names the required input combination (idea + title) up front, so the invocation condition is stated rather than inferred.

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

All Post Kit 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.