Skip to main content
Glama
Sign In
freeicon-mcp

freeicon-mcp

by Bencibr
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

i_site_icon

Extract a website's icon or logo from a URL by checking declared icons, inline SVG logos, and a Google favicon fallback, returning all candidates found.

Instructions

Extract a website’s icon or logo from its URL. Three tiers: 1) declared icons ( / apple-touch-icon) — SVG returns as text, raster as data URI; 2) inline logos in the page markup — 1:1 vector restoration (style context carried); 3) Google favicon service fallback. Also lists every candidate found.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "i_site_icon"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesWebsite URL, e.g. "https://www.apple.com/" or "apple.com" (https:// auto-prepended)
sizeNoPreferred icon size in px (default 256)
sourceNo"auto" = declared icons, then inline SVG logos, then Google service; "link" / "inline" / "google" = restrict to one tierauto

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.4
    • removedInput schema / properties / fallback
      Removed value: -{
-  "default": "auto",
-  "description": "\"auto\" = page icons first, Google favicon service as fallback; \"page-only\" = no fallback; \"google\" = skip page parsing",
-  "enum": [
-    "auto",
-    "page-only",
-    "google"
-  ],
-  "type": "string"
-}
    • changedInput schema / properties / size / description
      Previous value: -"Preferred icon size in px for the fallback service and candidate ranking (default 256)"New value: +"Preferred icon size in px (default 256)"
    • addedInput schema / properties / source
      Added value: +{
+  "default": "auto",
+  "description": "\"auto\" = declared icons, then inline SVG logos, then Google service; \"link\" / \"inline\" / \"google\" = restrict to one tier",
+  "enum": [
+    "auto",
+    "link",
+    "inline",
+    "google"
+  ],
+  "type": "string"
+}
  2. Addedv0.1.2

TDQS

A4/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does well: it discloses the fallback order, that SVG comes back as text versus raster as a data URI, that inline SVG keeps style context, and that all candidates are listed. It omits failure modes, network/timeout behavior, and whether the call is read-only or cached.

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?

Purpose is front-loaded in the first clause, the tier list is numbered and compact, and the closing sentence adds a distinct output note. No sentence is redundant.

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?

No output schema exists, so the description must cover returns, and it does specify the text/data-URI forms and the candidate listing. It is nearly complete for a simple three-parameter extraction tool, with only error and fallback-failure behavior left implicit.

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%, including the source enum, so the schema already documents all three parameters. The description reinforces the tier semantics corresponding to the source parameter but adds little format or sizing detail beyond what the schema states.

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 definition opens with a specific verb and resource ('Extract a website's icon or logo from its URL'), which is immediately distinguishable from siblings like i_bitmap_to_svg or i_download_svg. It does not explicitly name a sibling or state which alternative to pick, so it falls just short of a 5.

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 three-tier enumeration gives clear context for what happens on a call, and the 'auto vs restrict to one tier' behavior tells the agent how to steer results. There is no explicit when-not-to-use guidance or named alternative tool for cases where extraction fails.

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

Deploy Server

Other Tools