roastify-mcp

Roastify Stash Design

roastify_stash_design

Store a Roastify design JSON in your library (a commit in your GitHub repo).

The browser courier reads a saved product's design and calls this to shuttle it up. On the way in, the design's fonts[] is REPAIRED — Roastify's own schema migration leaves a lossy fonts[] (a dropped family, a bad weight), so a stashed design would otherwise carry that damage; the repair rebuilds fonts[] from the families the text actually uses so it renders in its intended fonts. Only the load list changes; the text and its fonts are untouched. Inline images are de-duplicated. This does NOT touch Roastify.

Input Schema

TableJSON Schema

Name	Required	Description
`npub`	No	Required. Your Nostr public key (npub1...) for credit billing.
`label`	No	Your name for this design, e.g. "Ethiopian — light".
`design`	Yes	The full Roastify design JSON object (elements/faceBackgrounds…).
`design_id`	No	Optional explicit folder id. Omit and the id is the slug of the label, so re-stashing the same design commits a new version in place instead of creating a duplicate.
`dpop_token`	No
`product_id`	No	The Roastify product id it came from, for your reference.
`description`	No	The product's store-page description at stash time, versioned with the design so Fetch can re-apply it to a target product.
`version_tag`	No	The NEXT semver version (MAJOR.MINOR.PATCH like 1.2.3, no 'v'); check roastify_list_design_versions and increment. Required; reusing one is refused.
`source_title`	No	The product's title at stash time, for your reference.
`commit_message`	No	A specific description of WHAT changed and WHY — write a real commit message, not a placeholder like 'save this' or 'update'. Required.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedSep 1, 2026

TDQS

A4.7/5.0

Behavior5/5

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

With no annotations, the description carries the full burden, and it delivers: it discloses that fonts[] is repaired on the way in, inline images are de-duplicated, only the load list changes, text and fonts are untouched, and Roastify itself is not modified. This is unusually transparent about side effects and non-effects.

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?

The description is front-loaded with the core purpose and then uses each subsequent sentence to explain surprising, high-value behavior. Nothing is filler, and the prose is dense but digestible.

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?

Despite having no annotations, the description covers the important hidden transformations, the storage target, and what is not affected. The schema documents the many parameters, and an output schema exists, so return-value documentation is not the description's job. The overall definition gives an agent enough context to invoke this tool correctly.

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?

Schema coverage is high at 90%, so the baseline is 3, but the description adds meaningful semantics for the design parameter by explaining that the input design's fonts[] is repaired and inline images are deduplicated. This goes beyond the schema's generic 'full Roastify design JSON object' description.

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?

The description states a specific action and resource: 'Store a Roastify design JSON in your library (a commit in your GitHub repo).' It also distinguishes this tool from nearby siblings by explicitly noting it 'does NOT touch Roastify' and by framing the operation as stashing rather than fetching, deleting, or updating a design.

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 description gives clear context: the browser courier reads a saved product's design and calls this tool to 'shuttle it up,' and the version_tag parameter description tells the agent to check roastify_list_design_versions and increment. It does not explicitly name alternatives or state when not to use this tool, but the scenario is specific enough to guide correct usage.

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

All roastify-mcp 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.