A
licenseA
qualityD
maintenanceAutomatically generates complete favicon sets from PNG images or URLs, creating multiple sizes, ICO files, Apple touch icons, and manifest.json for web applications.
2
34
MIT
Favicon & App Icons
Server Details
Check, generate, and troubleshoot complete favicon, Apple touch icon, PWA, and web app icon sets.
If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
- Status
- Healthy
- Uptime
- 100.0% over 23 days
- Last Tested
- Transport
- Streamable HTTP · MCP 2025-11-25
- URL
TDQS
A4.3/5.0
Scored across 3 tools
Disambiguation5/5
Each tool has a distinct purpose: check_favicon verifies existing icon installation without changes, generate_iconset creates or replaces hosted icon sets, and search_icons finds source icons. The boundary between checking and generating is explicit, and the cross-reference between search_icons and generate_iconset reinforces rather than blurs roles.
Naming Consistency5/5
All three tools follow a consistent verb_noun pattern: check_favicon, generate_iconset, search_icons. The minor variation between 'favicon' and 'iconset' reflects the specific resource each action targets and remains readable.
Tool Count5/5
Three tools is a tight, well-scoped set for a focused favicon and app icon service. Each tool earns its place by covering a core workflow: verification, generation, and source discovery.
Completeness4/5
The surface covers checking installed icons, generating icon sets, and searching for icon sources, which addresses the core domain. A minor gap is the absence of tools to manage or delete previously generated hosted output, though this may be outside the stated purpose.
Available Tools
3 toolscheck_faviconCheck a website's favicon and app iconsARead-onlyIdempotentInspect
Use this when someone asks whether a website favicon, Apple touch icon, app icons, manifest, or search-result icon is installed correctly. Reads a public website, verifies declared icon files, reports missing coverage, and can check search-engine favicon indexing. It never changes the website.
| Name | Required | Description | Default |
|---|---|---|---|
| url | Yes | Public website URL or domain to inspect, e.g. https://example.com. | |
| includeSearchIndexing | No | Also check Google/Bing/Yahoo favicon indexing plus robots.txt, llms.txt, and sitemap.xml. Defaults to true. |
Output Schema
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| found | Yes | |
| score | Yes | |
| missing | Yes | |
| indexing | Yes | |
| seoFiles | Yes | |
| foundCount | Yes | |
| nextAction | Yes | |
| logoOptions | Yes | |
| sourceImage | Yes | |
| missingCount | Yes |
TDQS
A4.1/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description still adds real context beyond that: it reads a public website, verifies declared icon files, reports missing coverage, optionally checks search-engine indexing, and explicitly reassures 'It never changes the website' (reinforcing the network-read nature of an openWorld tool).
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?
Three tight sentences, front-loaded with the usage trigger, then scope, then the no-mutation guarantee. Every sentence carries information and there is no 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?
With an output schema present, return values need no explanation, and the annotations fully cover the safety/idempotency profile. The description supplies the trigger, the scope of inspection, and the read-only guarantee, leaving nothing an agent needs before invoking the tool.
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%, so both parameters are already fully documented, and the schema for includeSearchIndexing even enumerates the extra files checked (robots.txt, llms.txt, sitemap.xml). The description's mention of 'can check search-engine favicon indexing' merely restates that parameter, adding no syntax or default beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb (checks/verifies) and resource (favicon, Apple touch icon, app icons, manifest, search-result icon) plus the scope (a public website). It is clearly distinct in spirit from generate_iconset and search_icons, but it never names or explicitly contrasts with those 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?
The opening 'Use this when someone asks whether...' gives a concrete triggering scenario, which is solid when-to-use guidance. It does not, however, state when NOT to use it or name an alternative (e.g. generate_iconset) for the cases this tool doesn't cover.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
generate_iconsetGenerate a favicon and app-icon setAInspect
Use this when someone asks to create, replace, or install favicons, website icons, Apple touch icons, PWA icons, or app icons. Generates favicon.ico, PNG sizes, Apple/Android icons, theme-aware icons, manifests, environment variants, downloadable URLs, and an install snippet from one image, URL, or Iconify name. This creates hosted output files but does not edit the caller's project. Call search_icons first if you need a source.
| Name | Required | Description | Default |
|---|---|---|---|
| apiKey | No | ft_… key from a previous call for a higher rate limit. | |
| source | Yes | Iconify name (prefix:name), an http(s) image URL, or a base64/data-URL image. | |
| customSizes | No | Extra exact PNG sizes a platform demands, e.g. [255] for Adobe's 255×255 or ['300x150']. Each becomes icon-WxH.png (16–4096px, max 12). Production only; not in the head snippet or manifest. | |
| docsVariant | No | Also emit the outlined docs-* tab-icon set + docs-manifest.json. | |
| variantType | No | ||
| primaryColor | No | Hex color, e.g. #61dafb. | |
| backgroundColor | No | none | white | black | #rrggbb | |
| backgroundShape | No | ||
| docsBorderColor | No | Docs ring colour: accent | contrast | white | #rrggbb. | |
| excludeFromGraph | No | When true, skip recording this generation to analytics. | |
| includeDevVariations | No | ||
| includeThemeAwareFavicon | No |
Output Schema
| Name | Required | Description |
|---|---|---|
| note | No | |
| files | Yes | |
| apiKey | No | |
| install | Yes | |
| manifest | Yes | |
| circleFit | No | |
| headSnippet | Yes | |
| safariPinnedTab | No | |
| excludedFromGraph | Yes | |
| appliedBackgroundShape | Yes |
TDQS
A4.5/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavioral context: output is hosted files rather than project edits, plus the install snippet and downloadable URLs. It stops short of stating persistence/expiry of hosted output or rate-limit behavior.
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?
Three sentences, front-loaded with the trigger condition, then the output inventory, then the scope caveat and alternative-tool pointer. No filler and nothing repeated from the schema.
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?
An output schema exists, so return values need no explanation, and the description nonetheless summarizes the deliverable set. Combined with annotations covering safety and world-openness, an agent has everything needed to select and call it.
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?
With 12 parameters and 67% schema description coverage, the schema carries most parameter meaning, and the description only restates the source types ('image, URL, or Iconify name') already documented in the schema. It adds no guidance on customSizes, variantType, backgroundShape, or theme-aware toggles.
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 concrete verb+resource ('Generates favicon.ico, PNG sizes, Apple/Android icons, theme-aware icons, manifests...') and explicitly enumerates the artifact set, which no sibling produces. It also differentiates itself from search_icons by routing source discovery there.
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 trigger phrasing ('when someone asks to create, replace, or install favicons...') and names the alternative tool plus the condition for using it ('Call search_icons first if you need a source'). It also carves out scope: it does not edit the caller's project.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_iconsSearch favicon and app iconsARead-onlyIdempotentInspect
Use this when someone needs an icon, emoji, or brand mark to use as a favicon or app icon. Searches Iconify and returns ready-to-use prefix:name values plus the generate_iconset options.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional search term to find Iconify icon/emoji names, e.g. 'fox', 'rocket', 'github'. |
Output Schema
| Name | Required | Description |
|---|---|---|
| tool | Yes | |
| guidance | Yes | |
| iconResults | Yes | |
| inputSchema | Yes |
TDQS
A4/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds real context beyond that: the backing source (Iconify) and that results are ready-to-use prefix:name values feeding generate_iconset options.
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?
Two sentences, zero filler: the usage trigger is front-loaded and the behavioral detail follows. Nothing is redundant with the title or annotations.
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?
With an output schema present, return values needn't be explained, and the description covers use case, source, and output type. The only gap is that it doesn't clarify its position relative to check_favicon, which an agent selecting among three icon tools would want.
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?
The single 'query' parameter is fully documented in the schema (100% coverage), and the description adds nothing about syntax, matching behavior, or what happens when query is omitted. Baseline 3 applies since the schema carries the load.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (searches) and resource (Iconify icon/emoji/brand-mark names), and even previews the return shape ('prefix:name values'). It implies a relationship to generate_iconset but never distinguishes itself from check_favicon, so sibling differentiation is incomplete.
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 opening clause gives a clear when-to-use trigger ('when someone needs an icon, emoji, or brand mark to use as a favicon or app icon'). It offers no when-not condition or explicit routing to check_favicon/generate_iconset as alternatives, so it stops short of full guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tool Schema Changelog
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
1 tool update
- Changed
generate_iconset1 field changed- added
Input schema / properties / customSizesAdded value: +{ + "description": "Extra exact PNG sizes a platform demands, e.g. [255] for Adobe's 255×255 or ['300x150']. Each becomes icon-WxH.png (16–4096px, max 12). Production only; not in the head snippet or manifest.", + "items": { + "anyOf": [ + { + "type": "integer" + }, + { + "type": "string" + }, + { + "additionalProperties": false, + "properties": { + "height": { + "type": "integer" + }, + "width": { + "type": "integer" + } + }, + "required": [ + "width", + "height" + ], + "type": "object" + } + ] + }, + "type": "array" +}
1 tool update
- Changed
generate_iconset5 fields changed- added
Input schema / properties / backgroundColor / anyOfAdded value: +[ + { + "enum": [ + "none", + "white", + "black" + ], + "type": "string" + }, + { + "pattern": "^#?([0-9a-fA-F]{3}|[0-9a-fA-F]{6})$", + "type": "string" + } +] - added
Input schema / properties / backgroundColor / descriptionAdded value: +"none | white | black | #rrggbb" - removed
Input schema / properties / backgroundColor / enumRemoved value: -[ - "none", - "white", - "black" -] - removed
Input schema / properties / backgroundColor / typeRemoved value: -"string" - added
Output schema / properties / safariPinnedTabAdded value: +{ + "additionalProperties": false, + "properties": { + "included": { + "type": "boolean" + }, + "reason": { + "type": "string" + } + }, + "required": [ + "included" + ], + "type": "object" +}
3 tool updates
- First observed
check_favicon - First observed
generate_iconset - First observed
search_icons
Related MCP Connectors
Generate favicons (ICO, SVG, Apple touch, PWA, manifest) from SVG, text or emoji; check any site.
Generate PWA icon sets and iOS splash screens from a text prompt or an existing image.
Image toolkit: resize, convert, compress, crop, metadata, hashes, favicons, OCR, QR codes, barcodes.
Search and fetch SVG icons from 250,000+ icons across 200+ open-source icon sets.
Related MCP Servers
- AlicenseNot gradedqualityCmaintenanceGenerates all required web app icons and manifest files from a single source image with framework auto-detection. Supports Next.js App Router, traditional web apps, and PWA standards with zero configuration.4 npmMIT
- AlicenseCqualityAmaintenanceGenerate deployment-ready PWA, iOS, and Android app icon sets from a text description. Produces all 27 required sizes, maskable icons, Xcode-ready iOS icons, Android mipmap folders, splash screens, and manifest.json packaged as a ZIP. Powered by Google Imagen 4.62MIT
- AlicenseAqualityDmaintenanceRoutes one brief to the right image model across 60+ (gpt-image-1.5, Ideogram 3, Recraft V4, Flux), validates the output, and fans out to iOS/Android/PWA/favicon/visionOS/Flutter bundles. Works without an API key via Pollinations, HF Inference, Stable Horde, or host-LLM inline SVG.2424MIT
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd
Glama MCP Gateway
Add one secure layer between your agents and this server.