ScriptMasterLabs runs 24 MCP servers with 182 tools — 120 free, 52 paid per call over x402, 10 on special terms — listed across the Official MCP Registry, Glama, Smithery, the CDP Bazaar, and our own hub at scriptmasterlabs.com/muse-connect. At that scale, the MCP server icon stops being a cosmetic detail. It becomes listing integrity, because of the single most important fact we have measured about this ecosystem:
Most directories never run your server. They read your package, your repo, or your registry record. Whatever icon, tool list, and metadata you baked into the published source is what the world sees — in whatever theme each directory happens to render. Get the icon wrong and it fails silently, 24 listings at a time. This is the guide we run our own fleet by: where the official icon lives, which sizes to ship, the light/dark pattern that survives every registry theme, and the listing lessons we paid for in re-releases.
Where can I download the official MCP server icon?
From the source, not a mirror. The modelcontextprotocol GitHub organization hosts the official brand assets — the logo files you need for READMEs, registry listings, and package metadata. Download the SVG or PNG, commit it to your repo, and reference it locally.
Never scrape it from a directory listing and never hotlink it. Directory sites compress, crop, and re-encode logos to fit their UI; a scraped copy may be a blurry PNG on a baked-in background, and a hotlinked URL can change without notice and leave your README showing a broken image. Across 24 servers we vendor the mark into each package the same way: files committed locally, zero runtime fetches.
What formats and sizes does the icon come in?
Treat SVG as the master file. It scales from a 16px favicon to a full-width banner from one source, and vector-friendly registries render it crisply in both themes. Keep the SVG in your repo even if you never ship it directly, so every PNG export traces back to the same geometry.
Some contexts can't render SVG — certain package cards, some directory listings, email clients, older markdown renderers. Export fixed-size PNGs rather than scaling one bitmap:
| Asset | Size | Use |
|---|---|---|
| favicon-16.png | 16×16 | Browser tab, tight UI rows |
| favicon-32.png | 32×32 | Bookmarks, small badges |
| icon-128.png | 128×128 | Registry cards, README inline |
| icon-512.png | 512×512 | Open graph, store listings |
The 16px export is where server icons go to die. Shrink yours and check it against a white background, a dark editor theme, and a mid-grey registry card. If the mark turns to mush, simplify: fewer shapes, thicker strokes, no fine text. When you maintain two dozen listings, this test is not optional polish — it is the difference between a fleet that reads as one brand and a grid of grey smudges.
How do I use the icon in light and dark UI themes?
The brand kit ships light and dark variants, and the guidelines are simple: use the version with adequate contrast for the background — dark-on-light for docs pages, light-on-dark for terminal screenshots and dark-mode registries. Pick per context, not one file everywhere.
GitHub READMEs don't run your CSS, but they honor <picture> media queries. Host both SVGs and let the browser choose:
<picture>
<source media="(prefers-color-scheme: dark)" srcset="assets/mcp-icon-dark.svg">
<img src="assets/mcp-icon-light.svg" width="120" alt="MCP server icon">
</picture>
This is the pattern we use across the SML fleet, and the reason is the finding above: registries and directories each render your listing on their own background, and they never all use the same theme. Hardcode a light-theme icon and a dark-theme registry renders a dark mark on a dark background — your server vanishes. One <picture> block costs thirty seconds and removes that failure mode for every consumer of your repo, because the browser resolves the variant at render time instead of you guessing at commit time.
On your own docs site, the CSS equivalent works:
.theme-dark .mcp-icon { content: url("/icons/mcp-icon-dark.svg"); }
Before shipping, check both modes: GitHub settings → Appearance → dark, view your README, then preview in one registry UI. That is where x402 buyers first see your server.
What are the brand guidelines?
Treat the icon as a fixed mark: supplied aspect ratio, no stretching, rotating, recoloring, or shadows. Keep clear space around it at least equal to the height of one glyph inside the mark; nothing — text, badges, your own logo — sits inside that margin.
The icon signals the protocol, not your product. Pair it with your own mark at equal height (24px next to 24px), same corner radius, at least half the icon's height as clear space between them. What crosses the line is endorsement: "official," "certified," or the icon standing in for your product name. Say "built on MCP" or "MCP-compatible" instead.
A paid x402 server header, done right:
[](https://modelcontextprotocol.io) **ScriptMasterLabs Trust Check** — $0.01/call, USDC on Base
Both icons at 24px, same radius, a clear gap, price on the same line. The MCP icon signals compatibility; our icon carries only our brand. Trust Check is a real SML endpoint — a $0.01/call trust read, settled in USDC on Base — and its listing follows exactly this pattern.
Bake it into the package: what 24 listings taught us
The icon is one asset in a larger discipline: bake static icon references and tool lists into your package, because the record is the product as far as directories are concerned. Our evidence, all of it verified from outside reads:
- Registry records drift from live servers. Our 402Proof record on the Official MCP Registry claimed 11 tools; the live server serves 12. We republished it as v1.0.2 with the true 12-tool inventory. Quant Terminal's record listed 4 tools against 5 live; republished as v1.1.3. Both fixes were confirmed by fresh reads of the registry API afterward — a commit is not proof; a read-back is.
- Some directories cannot be fixed in place at all. Smithery still shows stale tool counts for SML servers because Smithery removed in-site updating; the correction path was a support follow-up, sent November 1, 2026. When a venue can't be edited, the package and registry record are the only surfaces you control — another reason they have to be right.
- Claim and verify, on a cadence. Our Verdict Protocol and OMNIGATE listings on Glama are claimed and read Healthy. OMNIGATE's own index reads back 129 SML resources, and a five-surface verification on November 3, 2026 counted 177 strict SML rows in the CDP Bazaar. Listings rot; we re-probe them like endpoints.
- Own a hub you control. Every SML server — all 24, with endpoints and copyable install prompts — lives at scriptmasterlabs.com/muse-connect, and the full catalog at scriptmasterlabs.com/sml-products. Directories are rented land; the hub is ours.
We learned the static-record lesson the expensive way: as we wrote in our earlier account of this fleet's launch, three releases in four days were spent fixing listings that rendered wrong because the assets directories needed weren't in the published source. Bake them in, and a new service renders correctly everywhere on the first try.
Is the icon free to use commercially?
Yes — the MCP logo is a project mark, and using it to indicate your server speaks the Model Context Protocol is fine for commercial offerings, including paid x402 servers like ours. What you cannot do is imply endorsement: no "official MCP server," no icon-as-product-name, no suggestion the MCP team approved your server. Keep it in README badges, registry listings, and package metadata, and point your package's homepage and repository fields at real URLs so directories that read published metadata resolve them correctly.
FAQ
Can I put the MCP logo on my landing page if my server isn't open source?
Yes. Open-source status doesn't matter; what matters is what the logo communicates. Signal protocol compatibility — "built on MCP," "MCP-compatible" — and keep it out of your product name and logo lockup.
Why does my icon look wrong in a directory but fine in my README?
Because the directory isn't rendering your README — it's rendering its own record, on its own background. A light-theme icon on a dark registry card vanishes, and a stale record reference renders a stale asset. Fix the record, ship both theme variants.
Do I need permission to use the icon in a paid product?
No. Indicating compatibility in a commercial offering is acceptable; claiming official status is not. Our own paid listings — Trust Check at $0.01/call, Verdict Protocol at $0.25 USDC per decision on Base — carry the mark exactly this way.
The short version
Download the icon from the modelcontextprotocol GitHub org. Ship the SVG master plus 16/32/128/512 PNGs. Use the <picture> pattern so the right variant renders in every theme. Say "built on MCP," never "official." And bake the icon and your tool list into the published package — because at fleet scale, the record is what the world reads.
The fleet behind this guide: 24 MCP servers, 182 tools, every listing verified from outside. Browse them at scriptmasterlabs.com/muse-connect and the full ScriptMasterLabs catalog at scriptmasterlabs.com/sml-products.
ScriptMasterLabs is a service-disabled veteran-owned software lab (SDVOSB) building payment and decision infrastructure for AI agents.
Top comments (0)