Skip to main content
Glama

GO AI Tools

Generate a favicon and web-app-manifest set

generate_favicon_set
Read-onlyIdempotent

Turns one source image into a complete favicon set: favicon.ico (a real multi-resolution ICO container holding 16, 32 and 48px PNG-encoded entries -- not a single-size file with an .ico extension), favicon-96x96.png, apple-touch-icon.png (180px, flattened onto backgroundColor because iOS paints transparency black there), web-app-manifest-192x192.png and web-app-manifest-512x512.png (optionally padded to Android's maskable safe zone -- the artwork shrunk to a centred 80%-width square on the background colour, reproducing the source tool's square padding rather than clipping to the actual inscribed-circle safe area), site.webmanifest, and the exact 5-line HTML snippet (favicon.ico link, favicon-96x96.png link, apple-touch-icon link, apple-mobile-web-app-title meta, manifest link) ready to paste. A non-square source is centred on a transparent square canvas first, so nothing is stretched. Ported from GO AI's browser-based favicon tool, run server-side with @napi-rs/canvas instead of a DOM . Every PNG and the .ico are small (a few KB to worst-case a couple hundred KB), so all six files are returned individually rather than zipped -- each name matters (favicon.ico and site.webmanifest belong at the site root) and there is no batching benefit to a ZIP at this size. The JSON result carries the manifest JSON text, the HTML snippet text, a per-file table of what each output is for, and a warning when the source is smaller than 512px on its longer side (the 512 icon will be upscaled). Fails with a clear message rather than throwing if the input cannot be decoded as an image.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
siteNameNoFull site name, used as the manifest's "name" field and as the fallback for short_name / the apple-mobile-web-app-title meta tag when shortName is empty.My site
shortNameNoShort name for a home-screen label (roughly 12 characters fit). Used as the manifest's "short_name" and in the apple-mobile-web-app-title meta tag; falls back to siteName when empty.
themeColorNoHex colour (# optional, 3- or 6-digit) written to the manifest's theme_color field. Purely metadata -- never painted onto any icon.#0a0a0c
imageBase64YesSource image, base64-encoded. Any raster/SVG format @napi-rs/canvas can decode (PNG, JPEG, WebP, GIF, SVG). May be non-square and may carry transparency -- it is centred on a square canvas before anything else happens to it. Capped by this server's per-input byte limit.
backgroundColorNoHex colour (# optional, 3- or 6-digit) used three ways: the manifest's background_color field, the flatten colour behind the apple-touch-icon (iOS does not honour alpha there), and the padding colour around the maskable-cropped manifest icons.#ffffff
maskablePaddingNoWhen true (default), the 192x192 and 512x512 manifest icons are padded: the artwork is shrunk to a centred 80%-width square on the background colour, matching Android's maskable-icon safe zone, and the manifest icons' "purpose" is set to "maskable". When false, those two icons are the plain resized artwork with "purpose": "any".

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
tableYesEvery generated file and what it is for, so the set can be checked without unzipping it.
snippetYesThe <link> and <meta> tags to paste into the page head, matching the files that were generated.
warningYesA quality caution about the source image, chiefly that it was not square or too small. Null when there is nothing to flag.
manifestYesA complete web app manifest as JSON text, ready to serve as site.webmanifest.
themeColorYesTheme colour written into the manifest and meta tags.
sourceWidthYesSource image width in px.
squaredSideYesSide length of the square canvas the source was fitted onto, in px.
sourceHeightYesSource image height in px.
backgroundColorYesBackground colour written into the manifest.
maskablePaddingYesWhether the maskable icon was padded to survive Android's safe-zone crop.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": false,
      +  "properties": {
      +    "backgroundColor": {
      +      "description": "Background colour written into the manifest.",
      +      "type": "string"
      +    },
      +    "manifest": {
      +      "description": "A complete web app manifest as JSON text, ready to serve as site.webmanifest.",
      +      "type": "string"
      +    },
      +    "maskablePadding": {
      +      "description": "Whether the maskable icon was padded to survive Android's safe-zone crop.",
      +      "type": "boolean"
      +    },
      +    "snippet": {
      +      "description": "The <link> and <meta> tags to paste into the page head, matching the files that were generated.",
      +      "type": "string"
      +    },
      +    "sourceHeight": {
      +      "description": "Source image height in px.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "sourceWidth": {
      +      "description": "Source image width in px.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "squaredSide": {
      +      "description": "Side length of the square canvas the source was fitted onto, in px.",
      +      "maximum": 9007199254740991,
      +      "minimum": -9007199254740991,
      +      "type": "integer"
      +    },
      +    "table": {
      +      "description": "Every generated file and what it is for, so the set can be checked without unzipping it.",
      +      "items": {
      +        "additionalProperties": false,
      +        "properties": {
      +          "file": {
      +            "description": "Generated filename.",
      +            "type": "string"
      +          },
      +          "sizes": {
      +            "description": "Pixel dimensions the file covers.",
      +            "type": "string"
      +          },
      +          "usedFor": {
      +            "description": "Which browser, platform or surface asks for this file.",
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "file",
      +          "sizes",
      +          "usedFor"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "themeColor": {
      +      "description": "Theme colour written into the manifest and meta tags.",
      +      "type": "string"
      +    },
      +    "warning": {
      +      "description": "A quality caution about the source image, chiefly that it was not square or too small. Null when there is nothing to flag.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "required": [
      +    "manifest",
      +    "snippet",
      +    "table",
      +    "sourceWidth",
      +    "sourceHeight",
      +    "squaredSide",
      +    "maskablePadding",
      +    "themeColor",
      +    "backgroundColor",
      +    "warning"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.2/5.0
Behavior5/5

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

Even with annotations already declaring readOnly, idempotent, and non-destructive hints, the description adds critical behavioral detail: real multi-resolution ICO structure, iOS apple-touch-icon flattening on backgroundColor, maskable safe-zone padding, an upscaling warning for sources under 512px, and graceful failure on undecodable input. These go well beyond the structured 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?

The description is a dense single paragraph, but each parenthetical earns its place: ICO structure, iOS transparency, maskable padding, warning, and failure mode. It is front-loaded with the output list. Slight structure improvements with bullets could help readability, but nothing is filler.

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 6-parameter tool with an output schema, the description is fully complete: it covers the complete output set, source-image centering behavior, iOS flattening, Android maskable padding, the 512px upscaling warning, and error handling. Nothing an agent needs to invoke it correctly is missing.

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 description coverage is 100% and every parameter has a detailed schema description, including defaults and use cases. The tool description adds little parameter-level meaning beyond the schema; its mentions of backgroundColor and maskablePadding behaviors are already covered in the input 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?

The description opens with a specific verb and resource — "Turns one source image into a complete favicon set" — then enumerates every output file and the HTML snippet. This clearly distinguishes it from the sibling generate_app_icon_set, which targets a different resource.

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

Usage Guidelines3/5

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

The description states what the tool does but never explicitly says when to use it over alternatives or names exclusions. The purpose is evident, so usage is implied, but an agent comparing it to generate_app_icon_set has to infer the distinction from the title and output list rather than being guided.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources