Skip to main content
Glama

nanoodle

by io.github.nanoodlecom
OverviewDiscussionsAdmin

render-a-mockup

Turn a screen brief and visual style into a UI concept for design review. Qwen Image 3 Pro renders at 1K ($0.04/image); no prompt-writing call. Keep the combined brief and style under the model lim… text:Screen brief -> text:Visual style -> join -> image:Screen concept; returns image (qwen-image-3-pro, 1k) saved to disk (file path in result). Runs on NanoGPT — $0.20 deposit per call, paid in Nano (XNO) — settles at actual model cost + 20%, change returned; no account needed; last run $0.079, ~2m 16s. Example: Reviewed sample (https://nanoodle.com/examples/gallery/#render-a-mockup). A repair-shop dashboard concept with the requested navigation, date, three appointment rows, names, statuses and totals. This is a rendered screen concept; implementation and interaction are separate work.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
_payment_idNoPayment id from this tool's previous payment-required response. Phase 3 only: after /x402/watch closes with status paid, call again with the same arguments plus this id to open the RESULTS stream. Do not pass it while payment is still pending — monitor the watch SSE first.
Screen_briefNoText; default: "Repair shop dashboard, desktop screenshot. Navigation: Today, Repairs, Customers. Header: Tuesday, 8 September. Main ..."; optional
Visual_styleNoText; default: "Warm white background, charcoal text, gray dividers, forest-green primary button. Simple sans-serif, readable table r..."; optional

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changed
    • addedInput schema / properties / Screen_brief
      Added value: +{
+  "description": "Text; default: \"Repair shop dashboard, desktop screenshot. Navigation: Today, Repairs, Customers. Header: Tuesday, 8 September. Main ...\"; optional",
+  "type": "string"
+}
    • removedInput schema / properties / System_prompt
      Removed value: -{
-  "description": "System prompt; default: \"You write image prompts for UI mockups. Given a screen description and a style guide, reply with ONE detailed image p...\"; optional",
-  "type": "string"
-}
    • removedInput schema / properties / Text
      Removed value: -{
-  "description": "default: \"An underground dumpling cartel ops dashboard: live dumpling-shipment map across Taipei night markets, steam-timer hea...\"; optional",
-  "type": "string"
-}
    • removedInput schema / properties / Text_2
      Removed value: -{
-  "description": "Text; default: \"Style guide: premium, cinematic dark-mode product dashboard with an immediate wow factor, rendered as an exceptionall...\"; optional",
-  "type": "string"
-}
    • addedInput schema / properties / Visual_style
      Added value: +{
+  "description": "Text; default: \"Warm white background, charcoal text, gray dividers, forest-green primary button. Simple sans-serif, readable table r...\"; optional",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • changedInput schema / properties / Text / description
      Previous value: -"default: \"A habit-tracker web app dashboard: today's checklist, current streaks, a week-at-a-glance grid, and a quick-add button.\"; optional"New value: +"default: \"An underground dumpling cartel ops dashboard: live dumpling-shipment map across Taipei night markets, steam-timer hea...\"; optional"
  3. First observed

TDQS

A4.1/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 delivers: it discloses that output is saved to disk with a file path, specifies the model (Qwen Image 3 Pro) and resolution (1K), explains payment flow (no account, Nano deposit, cost settlement, last run cost and runtime), and clarifies the separation from implementation. This is comprehensive for a payment-required tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a long, unstructured paragraph mixing purpose, payment details, an example link, and separation notes. It front-loads the core purpose but then digresses into costs, runtime, and an example that are not essential for calling the tool. Better organization and trimming would improve readability.

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?

The description covers the essential outputs (image saved to disk, file path in result), the payment model, and the separation from implementation. It does not explicitly explain the payment phases (watch SSE, _payment_id) but these are detailed in the input schema. Given the tool's complexity, the description is nearly complete, though it could be more structured.

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 coverage is 100% with descriptive parameter names and defaults, so the baseline is 3. The description adds minimal extra value—only a vague hint about keeping the combined brief and style under a model limit. It does not clarify formatting or length constraints beyond the schema's default strings.

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 opening sentence clearly states the action ('Turn a screen brief and visual style into a UI concept') with a specific verb and resource. It distinguishes itself from image-generation siblings by focusing on UI design review, not generic image creation. The later mention of 'rendered screen concept' reinforces its unique role.

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 for when to use it ('for design review') and clarifies that it produces a static concept, not implementation. However, it does not explicitly name alternative tools or state conditions when NOT to use it. The sibling list includes other image tools, but no explicit routing is provided.

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

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