MCP Server Icon: Where to Find and Use It
Key takeaways
- Download the MCP server icon from the official modelcontextprotocol GitHub organization and commit it to your repo rather than scraping directory listings or hotlinking.
- Treat SVG as the master file and export fixed-size PNGs at 16, 32, 128, and 512 pixels for favicons, registry cards, and social previews.
- Use a <picture> element with prefers-color-scheme media queries in your README so the correct light or dark icon variant renders in every theme.
- Use the icon only to signal protocol compatibility with wording like "built on MCP"; never imply official status or endorsement.
- Bake static icon references and tool lists into your package, because many directories read published source instead of running your server.
The official mcp server icon lives in the modelcontextprotocol GitHub organization, and you can drop it into your README, npm package, and directory listings in about ten minutes. The catch is that most registries read the icon from different sources: some from package.json, some from repo files, some from the registry record itself. Getting it wrong cost us three releases in four days. This guide shows where to download it, which sizes and formats to ship, and the exact snippets for light and dark UIs so it renders correctly the first time.
Where can I download the official MCP server icon?
Get it from the source, not a mirror. The modelcontextprotocol GitHub org hosts the official brand assets, including the logo files you need for READMEs, registry listings, and npm packages. Download the SVG or PNG directly, commit it to your repo, and reference it locally.
The canonical repo and what's in it
The org's repositories include brand and logo assets in vector and raster formats, so you can scale for favicon sizes or hero banners without redrawing anything. Grab the file once, vendor it into your project, and you control rendering in both light and dark themes. We ship the MCP mark alongside our own icon on our decision-layer MCP server listing this way: files committed locally, no runtime fetches.
Why not to grab it from a directory listing
Directory sites compress, crop, or re-encode logos to fit their UI, so what you scrape may be a blurry PNG on a baked-in background. Hotlinking is worse: the URL can change without notice, and your README shows a broken image. Third-party listings also render on unknown backgrounds, so their version often has the wrong transparency for your page. Pull from the GitHub org, commit the file, done.
What file formats and sizes does the MCP server icon come in?
Treat SVG as the master file. It scales from a 16px favicon to a full-width README banner from one source, and registries that accept vector art will render it crisply in both light and dark themes. Keep the SVG in your repo root even if you never ship it, so every PNG export traces back to the same geometry.
SVG first, PNG as fallback
Some contexts can't render SVG: npm package cards in certain views, some directory listings, email clients, and older markdown renderers. Export PNGs at fixed sizes rather than scaling one bitmap up. A practical set:
| 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 |
Favicon and 16px legibility testing
The 16px export is where most server icons fail. 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. Our own ChargingNear MCP server (https://scriptmasterlabs.com/chargingnear-mcp-server) needed two rounds of this before the bolt stayed readable at favicon scale.
How do I use the MCP server icon in light and dark UI themes?
The MCP brand kit ships both light and dark variants of the logo, and the official brand guidelines specify using the version with adequate contrast for your background. Pick the variant per context, not one file everywhere: dark-on-light for docs pages, light-on-dark for terminal screenshots and dark-mode registries.
Markdown snippet with <picture>
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 same pattern we use on our own listing at ScriptMasterLabs Anrok MCP server, where the icon must read correctly in both GitHub themes and registry previews without a designer on call. The reason to bother: registries and directories each render your listing on their own background, and they never all use the same theme. mcprush reads your published source rather than a running server, so whatever icon and README markup you commit is what every directory sees, in whatever theme that directory ships. If you hardcode a light-theme icon and a dark-theme registry renders it, a dark mark on a dark background vanishes. One <picture> block costs you 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.
CSS approach for docs sites
On your own docs, use CSS instead:
.theme-dark .mcp-icon { content: url("/icons/mcp-icon-dark.svg"); }
Or swap src with a prefers-color-scheme media query in an <img> wrapper if your framework supports it.
Testing in GitHub dark mode
Check both modes before shipping: GitHub settings → Appearance → pick dark, then view your README. Also preview in one registry UI and one terminal tool, since those are where x402 buyers first see your server.
What are the brand guidelines for displaying the MCP server icon?
Treat the icon as a fixed mark: use it at its supplied aspect ratio, don't stretch, rotate, recolor, or add shadows and outlines. Keep the original colors, or fall back to a single-color version only where the theme forces it.
Clear space and minimum size
Leave a margin around the icon at least equal to the height of one glyph inside the mark itself. Nothing else, including text, badges, or your own logo, sits inside that margin. Don't scale it below the size where its internal details stay legible in a registry listing; if it turns to mush at 16px, use a simplified variant rather than shrinking further.
Pairing the icon with your own server logo
The icon signals the protocol, not your product. Place it beside your own mark with a separator or clear gap, sized so neither dominates. What implies endorsement is suggesting the MCP team built or approved your server: words like "official," "certified," or the icon alone standing in for your product name cross that line. Say "built on MCP" or "MCP-compatible" instead. Our own AdForm MCP server listing follows this pattern: the MCP icon marks the protocol, the product name carries the branding.
How do I add the MCP server icon to my server's README or listing?
Put the icon in your badge row, one line under the title. GitHub Markdown supports {height=24} style sizing via HTML, and a picture element with prefers-color-scheme media queries swaps icons for dark and light themes, as documented in GitHub's README image syntax guide. Keep the badge row to five items or it wraps on mobile.
Registry and package metadata
npm reads package.json fields; registries read their own records. Set description, keywords, and repository in package.json, and mirror the icon URL in any registry profile that accepts one. If your icon only exists in the repo, point at the raw URL so the registry can fetch it.
Directories read different sources: our three-release lesson
We shipped four x402 MCP servers and learned this the hard way, documented in our gotchas write-up: most directories never run your server. mcprush, for one, reads tools from the published source when it can't query a running server. Our first two versions built tool lists from a live fetch at startup, so there was nothing for directories to read. Three releases in four days fixed it: bake static tool lists and icon references into the package, accept that a new service needs a release, and your listing renders correctly everywhere on the first try.
Is the MCP server icon free to use commercially?
The MCP logo is a project mark, not a product you buy, so using it to indicate that your server speaks the Model Context Protocol is fine for commercial offerings. What you cannot do is imply endorsement: a badge that says "built on MCP" is accurate, one that reads "official MCP server" is not, unless Anthropic says otherwise in its brand policy.
Practically, keep the icon in README badges, registry listings, and npm package metadata rather than in your product name or logo lockup. In your package.json, point homepage and repository at real URLs so directories that read published metadata (instead of running your server) resolve the links correctly, per the npm package.json fields documentation. We ship our own x402 MCP servers this way: icon in the README, protocol reference in text, no claim of official status.
How do I make my own server icon sit next to the MCP icon without clutter?
Sizing and radius rules
Match the two icons at equal height: if the MCP icon renders at 24px, your server icon renders at 24px. Keep the ratio 1:1 rather than letting your brand mark run larger, which reads as a claim of hierarchy. Match corner radius to the MCP mark's squircle shape rather than using a sharp square or a full circle, and leave at least half the icon's height as clear space between the two marks. Export both as SVG with identical viewBox padding so they align in any registry UI.
Worked example: a paid MCP server header
A paid x402 server listing might render as:
[](https://modelcontextprotocol.io) **ScriptMasterLabs Trust Check** — $0.01/call, USDC on Base
Both icons sit at 24px, same radius, 12px gap, on one line with the price. The MCP icon signals protocol compatibility; your icon carries only your brand, not decoration.
FAQ
Can I put the MCP logo on my product's landing page if my server isn't open source?
Yes. Open source status doesn't matter; what matters is what the logo communicates. Use it to signal that your server speaks MCP, with wording like "built on MCP" or "MCP-compatible." Keep it out of your product name and logo lockup, and never label your server "official" or "certified," which implies endorsement you don't have.
Why does my MCP icon look wrong in the directory listing but fine in my README?
Registries render your listing on their own backgrounds and themes, and they never all match yours. A light-theme icon on a dark registry card vanishes. Some directories also read the icon from a different source than your README, such as a registry record instead of a repo file, so an outdated or missing reference renders the wrong asset.
Do I need to ask permission to use the MCP server icon in a paid product?
No. The logo is a project mark, and using it to indicate protocol compatibility in a commercial offering is acceptable. The line is endorsement: badges saying "official MCP server," the icon standing in for your product name, or any suggestion the MCP team approved your server cross it. Say "built on MCP" instead and keep the icon in badges and metadata.
What size should the MCP icon be in a GitHub social preview image?
Export from the SVG master rather than scaling a bitmap up. A 512×512 PNG export traces cleanly to the same geometry as your favicon, so place that on the social preview canvas with clear space around the mark at least equal to one internal glyph height. Check the result at small thumbnail size; if details turn to mush, use a simplified variant.