Skip to main content
Glama

nanoodle

by io.github.nanoodlecom
OverviewDiscussionsAdmin

favicon

Turn a brand brief into a square favicon concept. GLM Flash condenses the brief; Muse renders one image (image step $0.01, plus text). Inspect at 16px; export or convert to favicon sizes separately. text:Brand -> llm:Icon prompt -> image:Favicon; returns image (muse-image/text-to-image, 1:1) saved to disk (file path in result). Runs on NanoGPT — $0.03 deposit per call, paid in Nano (XNO) — settles at actual model cost + 20%, change returned; no account needed; last run $0.01, ~40s. Example: Reviewed sample (https://nanoodle.com/examples/gallery/#favicon). A lighthouse-inspired icon for a pocket weather radio. The output is a raster concept; creating an ICO or SVG requires a separate step.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
BrandNoText; default: "Lumen — pocket weather radio. One lighthouse beam as a chevron. Deep navy field, single warm-gold mark. No letters."; optional
Icon_promptNoSystem prompt; default: "Write one concise image prompt for a favicon concept from the brand brief. Preserve the requested symbol and colors. ..."; optional
_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.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • addedInput schema / properties / Icon_prompt
      Added value: +{
+  "description": "System prompt; default: \"Write one concise image prompt for a favicon concept from the brand brief. Preserve the requested symbol and colors. ...\"; optional",
+  "type": "string"
+}
    • removedInput schema / properties / Text
      Removed value: -{
-  "description": "default: \"You design one favicon. From the brand name/description, write ONE image prompt for a square app icon: a single bold ...\"; optional",
-  "type": "string"
-}
    • removedInput schema / properties / Text_2
      Removed value: -{
-  "description": "Text; default: \"style guide:\\n- Reduce the brand to its most distinctive visual idea; prefer a simple metaphor over a literal product ...\"; optional",
-  "type": "string"
-}
  2. Changed2 schema fields changed
    • changedInput schema / properties / Brand / description
      Previous value: -"* required; Text"New value: +"Text; default: \"Lumen — pocket weather radio. One lighthouse beam as a chevron. Deep navy field, single warm-gold mark. No letters.\"; optional"
    • removedInput schema / required
      Removed value: -[
-  "Brand"
-]
  3. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Since no annotations are provided, the description fully carries the burden. It discloses that the tool renders exactly one image, mentions cost ($0.01), settlement details (20% markup), deposit requirement, payment flow including phases, and that output is saved to disk with file path returned. It also mentions runtime (~40s) and points to a gallery example. This is comprehensive.

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?

Description is a wall of text with many interleaved details (pipeline, costs, payment, example, output format). It front-loads the core purpose but then jumps between technical flow, payment details, and an example link, which is hard to scan. Could be broken into short bullet points for clarity.

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?

Despite its structure, it covers essential operational details: payment, output, cost, and example. Missing explicit mention of error handling or state (like what happens if raster conversion is needed), but given the complexity and no output schema, the description covers most needed context.

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 100%, so parameters are already documented. Description adds value by explaining the pipeline roles: Brand brief feeding into Icon_prompt, which generates the image prompt. It also clarifies the _payment_id usage across phases, which is not fully in schema. Slight redundancy but generally adds context.

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?

Description clearly states the tool's purpose: turning a brand brief into a square favicon concept, with a specific pipeline (text -> llm:Icon prompt -> image:Favicon). It mentions the output type (raster concept) and the need for a separate step for ICO/SVG, which helps distinguish from siblings.

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?

Provides context on when to use (for favicon concepts) but doesn't explicitly contrast with sibling tools like 'character-sprites' or 'render-a-mockup'. It does mention the separate step needed for ICO/SVG, which implies when not to use for final formats. No explicit alternative routing, but clear enough.

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