Skip to main content
Glama

Emero

by io.github.EmeroAI
OverviewDiscussionsAdmin

Publish workflow

publish_workflow
Idempotent

Publish a tested workflow from this chat to the public library at emero.studio/workflows and add it to today's email digest draft. Live immediately. Calling again with the same slug replaces that post.

You write the words; the server fills every fact. Never write a model name, a cost, or a prompt in the body: each {{gen:...}} token becomes the media plus its model, real cost and exact prompt.

  • slug: [use-case]-[model], lowercase-hyphens, e.g. "jewelry-video-ad-seedance". Never change it after publishing.

  • title: models first, then the use case. Comparing models: "Seedance 2.5 vs MiniMax H3 - jewelry ad from two photos". One model: "GPT Image 2.5 - photo to ink illustration in five styles". Use the model names the generations show.

  • seo_title: max 60 chars. Lead with the model people search for, then the outcome, e.g. "Seedance 2.5 Jewelry Video Ad from 2 Photos: Prompts + Cost", "Kling 3.0 Fashion Ad: Ostrich Hands Over a Bag".

  • summary: max 100 chars, one plain sentence on what the workflow does. No terminal period.

  • Brands: never put a real brand or its trademarks in the slug, title, seo_title, summary or teaser: no house names (Gucci, Prada, Louis Vuitton) and no product marks (Damier, Intrecciato, GG, Kelly). Describe the look instead: "orange monogram bucket hat", "woven leather bag". In the body, name a brand only where the workflow needs it, never as if the post were their ad. Every post shows a no-affiliation disclaimer.

  • teaser: a short noun phrase with its article for the email, e.g. "a 10 second jewelry ad from two photos".

  • body: markdown only (## headings, paragraphs, lists, bold, links), no HTML. Open with why the approach works, then "## 1. " per step, each step a short paragraph followed by its token. Place outputs with {{gen:}} using the id generation returned, e.g. {{gen:job:3e6bb619-7a5d-47e8-bec4-6d841e941634#0}}. End with "## Why it works".

  • alts: alt text per token, keyed by the same artifact id: what the output shows, e.g. "Emerald ring and necklace on black velvet". The model name is appended automatically.

  • cover (optional): the artifact id of the generation that represents the post in share previews, the library card and the top of the post. Pick the strongest single frame, e.g. the delivery shot of a fashion spot, not the empty background plate. Must be one of the body's {{gen}} ids. A video works, a still is taken from it. Omitted = the first generation in the body. To change the cover later, publish again with the same slug and the new cover.

  • replaces (optional): when you publish a post under a NEW slug to rename an existing one, pass the old slug here. The old post is taken down and its URL redirects to the new one, keeping its date. Never publish a renamed post without it, or the library shows the post twice.

Voice: concise, first person, plain words, no em dashes. Show the user the full post and get their go before calling.

Input Schema

NameRequiredDescriptionDefault
altsYes
bodyYes
slugYes
coverNo
titleYes
teaserYes
summaryYes
replacesNo
seo_titleYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.9/5.0
Behavior5/5

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

Annotations declare idempotentHint=true and openWorldHint=true; the description adds the mechanism (slug-keyed replacement), the visibility consequence (live immediately, public library, share previews, email digest), and the server-side rewrite of {{gen:...}} tokens with real model, cost and prompt. It also discloses the brand/trademark policy and the auto-appended no-affiliation disclaimer, none of which are expressible in annotations.

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 purpose and replacement semantics, then a tight per-field bullet list — efficient given seven required fields and no schema descriptions. It is long, and some bullets stack multiple illustrative examples where one would establish the rule, but essentially every sentence conveys a constraint an agent would otherwise get wrong.

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 nine-parameter, seven-required mutation with zero schema documentation and no output schema, the description covers input format, idempotency, the token/alt/cover relationship, the rename path and the human-approval gate. An agent could execute this correctly without further context.

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

Parameters5/5

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

Schema coverage is 0%, so the description carries the whole burden and does: every one of the nine parameters is defined with format, length caps, examples and edge cases (slug pattern with a sample, seo_title max 60 chars, summary max 100 chars and no terminal period, alts keyed by artifact id, cover must be a body {{gen}} id, replaces takes the old slug). This is substantially more than the bare typed schema.

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 ('Publish a tested workflow from this chat to the public library at emero.studio/workflows') plus the concrete side effects: it goes live immediately and lands in today's email digest draft. The re-publish semantics ('Calling again with the same slug replaces that post') clearly separate it from unpublish_workflow and from the generation tools.

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 explicit triggers and exclusions: use replaces when renaming to a new slug, 'Never publish a renamed post without it, or the library shows the post twice', and to change a cover 'publish again with the same slug'. It also imposes a pre-call protocol: show the full post and get the user's go-ahead first.

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

All Emero 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