How do I use digital-fireplace-mcp?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@digital-fireplace-mcp recommend a fireplace for a cozy winter night" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

digital-fireplace-mcp

by mhoydich

Overview Schema Related Servers Score Discussions

Hybrid

digital-fireplace-mcp

Brought to you by Good Feels · shop.getgoodfeels.com

An MCP server (and a self-hosted gallery) for 34 embeddable pixel-art digital fireplaces.

Each fireplace is a single-file HTML page that renders a tiny living scene — a stone hearth, a CRT yule log, a sparkler, a slow-burning joint, a phoenix egg, a plasma reactor — and pins a small Good Feels attribution to the bottom-right. Embed any of them with one <iframe> snippet, anywhere.

classic-hearth   wood-stove       campfire         joint-tray
yule-log         crystal-cave     space-stove      tiki-torch
lava-lamp        cabin-window     mystic-brazier   jack-o-lantern
menorah          birthday-candle  sparkler         new-years
bonfire-beach    forge-anvil      sun-disc         volcano
aurora           dragon-mouth     phoenix-egg      lightsaber
solar-flare      welding-arc      gas-stove        furnace-coal
tea-light        match-strike     cigar-ashtray    incense
bong-cherry      firefly-jar

CC0. Take it, fork it, theme it, ship it.

What's in the box

public/fireplaces/*.html — 34 self-contained fireplace pages
public/lib/fire.js — the shared fire engine (Doom 1993 fire algorithm + 7 swappable palettes + a FireCrackle WebAudio synth)
public/lib/chrome.js — shared sponsor footer + tap-to-start audio gate
public/index.html — "The Hearth Picker" gallery, a live grid of all 34 with embed code modal
public/server.js — minimal Node static server (no framework deps)
src/index.ts — MCP server exposing 7 tools

Related MCP server: aseprite-mcp

Quick start

# Install + build
npm install
npm run build

# Run the static gallery on http://127.0.0.1:4700
npm run serve

# Run the MCP server (stdio)
npm start

Open http://127.0.0.1:4700 to browse the picker. Click any tile's embed button to get a turnkey iframe snippet for your own site.

Embed anywhere

<iframe
  src="https://your-host/fireplaces/joint-tray.html"
  width="800" height="500"
  frameborder="0"
  allow="autoplay"
  title="Good Feels · digital fireplace"
  style="border:none;"
></iframe>
<!-- brought to you by Good Feels · shop.getgoodfeels.com -->

MCP tools

Wire into your Claude Code, Cursor, or any MCP-compatible client by adding to its mcpServers config:

"digital-fireplace": {
  "command": "node",
  "args": ["/absolute/path/to/digital-fireplace-mcp/dist/index.js"],
  "type": "stdio",
  "env": { "FIREPLACE_SERVER_URL": "http://127.0.0.1:4700" }
}

Tool	What it does
`fireplace_list_styles`	Catalog of all 34 fireplaces with mood, palette, tags, URL
`fireplace_get_html`	Raw HTML for one fireplace (optionally bundled with `fire.js` / `chrome.js` for self-hosting)
`fireplace_get_embed_code`	Turnkey `<iframe>` snippet with sponsor comment
`fireplace_get_url`	Live URL for a specific fireplace
`fireplace_random`	Surprise pick
`fireplace_get_gallery_url`	URL of the picker grid
`fireplace_recommend`	Free-form vibe → top-3 matches by tag scoring

Example: "recommend a fireplace for a winter night sci-fi stream" → crystal-cave, space-stove, aurora.

How the fire engine works

The shared PixelFire class implements the classic Doom 1993 fire algorithm. For every pixel from bottom row to top, it copies from the row below with a small random horizontal offset and decays the palette index by 0–3. The hot source row at the bottom plus randomized decay produces a beautiful living flame that costs almost nothing to render.

Each fireplace picks a palette and (optionally) a mask + custom source row to shape the fire. Crystal Cave uses a cool blue palette. Plasma Reactor masks the fire to a circle. Gas Stove punches 12 hot zones into the source row to make discrete jets. Sun Disc and Solar Flare use a mostly-white solar palette.

Some fireplaces (lava-lamp, aurora, lightsaber, firefly-jar, joint-tray, bong-cherry, incense, match-strike, birthday-candle, new-years) use entirely custom CSS / canvas particle systems instead — picked when the Doom-fire approach didn't fit the subject.

Palettes

hearth · crystal · ember · mystic · plasma · tiki · lava · forge · gas · saber · solar · aurora

Add your own to public/lib/fire.js. Each is just an array of [r, g, b] triples ordered cold→hot.

Every fireplace renders a small fixed-position attribution linking to https://shop.getgoodfeels.com. The gallery hub also has a banner sponsor button. Both are baked into the chrome and present on every page.

If you fork this and want to remove or replace the sponsor with your own, edit public/lib/chrome.js (one file, ~120 lines).

License

CC0 1.0 Universal — public domain. See LICENSE. The fire algorithm itself was published by Fabien Sanglard / id Software in 1993 and is also widely-shared.

Credits

Built by @mhoydich · sponsored by Good Feels.

Doom-fire algorithm (1993) — Fabien Sanglard's reverse-engineering writeup is the canonical reference.

Available Tools

7 tools

fireplace_get_embed_codeGet Fireplace Embed CodeA

Read-onlyIdempotent

Return a turnkey HTML snippet for embedding a fireplace on any page. The iframe points to the locally running Digital Fireplace server (default http://127.0.0.1:4700) — set FIREPLACE_SERVER_URL on the MCP server to change it for production. Always includes a Good Feels sponsor attribution comment.

Args:

slug: fireplace slug
width: iframe width in px (default 800)
height: iframe height in px (default 500)
host: override host URL (e.g. https://fireplaces.example.com)

ParametersJSON Schema

Name	Required	Description
`slug`	Yes	Fireplace slug — see fireplace_list_styles for options
`width`	No
`height`	No
`host`	No	Override the host base URL

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint, destructiveHint, idempotentHint. The description adds valuable context: the iframe points to a local server (configurable via FIREPLACE_SERVER_URL) and always includes a sponsor attribution comment. No contradictions.

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?

The description is concise and well-structured: a single clear sentence about purpose, followed by key behavioral notes and a bullet list of arguments. Every sentence earns its place with no fluff.

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?

Given 4 parameters, no output schema, and annotations, the description is nearly complete. It explains the return format (iframe snippet), server URL configuration, and the sponsor attribution. It lacks details about error handling or edge cases, but covers the main behavioral expectations.

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 input schema covers 2 of 4 parameters with descriptions (slug and host). The description lists all parameters with brief explanations (e.g., width in px, default values) but adds no new semantic information beyond what the schema already provides. With 50% schema coverage, the description compensates only minimally.

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 clearly states the verb 'return' and the resource 'HTML <iframe> snippet for embedding a fireplace on any page'. It distinguishes this tool from siblings like fireplace_get_html or fireplace_get_url by specifying it returns a turnkey embed snippet.

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 description provides context for usage (embedding on any page) and mentions server URL configuration, but does not explicitly compare with sibling tools like fireplace_get_html or fireplace_get_url to guide when to choose this tool over alternatives.

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

fireplace_get_gallery_urlGet Fireplace Gallery URLA

Read-onlyIdempotent

Return the URL of the gallery picker page — a live grid showing all 34 fireplaces in animated thumbnails so you can pick visually.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already declare readOnlyHint, destructiveHint, idempotentHint, and openWorldHint. The description adds valuable behavioral context about the gallery page's content (live grid with animated thumbnails of 34 fireplaces). No contradictions.

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?

Single, well-structured sentence that front-loads the key information (returns URL) and adds explanatory detail. No filler words.

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 zero-parameter tool with no output schema but strong annotations, the description fully explains the purpose and what the URL provides. No missing information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has no parameters, so baseline is 4. The description adds no parameter-specific information, which is appropriate since schema coverage is 100% and parameters are zero.

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 clearly states the verb (Return), the resource (URL of the gallery picker page), and provides specific details (live grid, 34 fireplaces, animated thumbnails). This distinguishes it from sibling tools like fireplace_get_url or fireplace_get_html.

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 implies usage for visual selection ('so you can pick visually') but provides no explicit guidance on when to use this tool versus alternatives, nor when not to use it.

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

fireplace_get_htmlGet Fireplace HTMLA

Read-onlyIdempotent

Return the full self-contained HTML source for a fireplace. The HTML imports two small ES modules (/lib/fire.js and /lib/chrome.js) relative to the same origin where you're hosting it. To use this for embedding into your own site, use fireplace_get_embed_code instead — it returns a turnkey iframe snippet.

Args:

slug: fireplace slug (see fireplace_list_styles)
include_lib: if true, also returns the source of /lib/fire.js and /lib/chrome.js so the page can be self-hosted without dependencies on this server

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Fireplace slug — see fireplace_list_styles for options
`include_lib`	No	If true, include the fire.js/chrome.js dependencies in the response

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds behavioral context: returns self-contained HTML, modules loaded relative to origin, and optional inclusion of library source for self-hosting. No contradictions.

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?

The description is well-structured: a main sentence, a comparative sentence, and a clear argument list. Every sentence adds value without redundancy.

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?

For a simple read-only tool with good annotations, the description explains the return type (self-contained HTML), dependencies, and embedding alternative. It doesn't specify response format but that's acceptable given no output schema; the information provided is sufficient.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions. The description adds value by explaining the `include_lib` purpose (self-hosting without dependencies) and clarifies that `slug` options come from `fireplace_list_styles`. This goes beyond the schema alone.

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 clearly states it returns the full self-contained HTML source for a fireplace, specifies the included ES modules, and distinguishes from the sibling `fireplace_get_embed_code` which provides an iframe snippet for embedding.

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?

Explicitly tells when to use this tool vs. `fireplace_get_embed_code` for embedding, and mentions the `include_lib` parameter for self-hosting. Could be more comprehensive about all siblings but effectively guides the most common alternative.

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

fireplace_get_urlGet Fireplace URLA

Read-onlyIdempotent

Return the live URL of a fireplace on the local Digital Fireplace server. Use this if you just want to open the fireplace in a browser tab.

Args:

slug: fireplace slug

ParametersJSON Schema

Name	Required	Description	Default
`slug`	Yes	Fireplace slug — see fireplace_list_styles for options

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare readOnly and idempotent behavior. Description adds no extra behavioral context beyond stating the return type. No contradictions.

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?

Extremely concise: two sentences and a one-line args list. Front-loaded with purpose. No fluff.

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?

Given the simplicity of the tool (single required param, no output schema, full annotations), the description adequately covers purpose and usage. Could mention output format but not necessary.

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 describes the slug parameter with enum options and a description. The description merely repeats 'fireplace slug' without adding new semantic value. Baseline 3.

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 clearly states it returns a live URL and specifies the use case (opening in a browser tab). It distinguishes from sibling tools like get_embed_code and get_gallery_url.

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?

Provides a clear usage condition ('if you just want to open the fireplace in a browser tab'), implying when to use. Does not explicitly list alternatives but context suffices.

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

fireplace_list_stylesList Digital Fireplace StylesA

Read-onlyIdempotent

List all 34 available pixel-art digital fireplaces. Each has a slug, display name, mood description, color palette, audio support, and a list of tags. Use this to discover what's available, then pass the slug to fireplace_get_html or fireplace_get_embed_code.

Brought to you by Good Feels · shop.getgoodfeels.com.

Args:

response_format: 'markdown' or 'json'

ParametersJSON Schema

Name	Required	Description	Default
`response_format`	No	'markdown' or 'json'	markdown

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already provide readOnlyHint and idempotentHint. The description adds value by detailing the response fields (slug, display name, mood, etc.) and the response_format parameter, going beyond what annotations convey.

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?

The description is two concise paragraphs with no wasted words. It efficiently conveys purpose, usage, and response structure, including attribution.

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 simple list tool with one parameter, full schema coverage, and annotations, the description is complete. It explains the output and how to use the results with sibling tools.

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 only parameter is 'response_format' with enum and description in the schema. The description merely restates it without adding additional meaning or context. With 100% schema coverage, baseline is 3.

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 clearly states the verb 'list' and the resource 'digital fireplaces', specifying there are 34 available. It distinguishes from siblings by noting the output can be used with fireplace_get_html or fireplace_get_embed_code.

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 description explicitly says 'Use this to discover what's available, then pass the slug to fireplace_get_html or fireplace_get_embed_code', providing clear context and alternatives. It does not explicitly state when not to use, but the guidance is still strong.

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

fireplace_randomPick a Random FireplaceA

Read-only

Pick a random fireplace from the catalog. Useful when you want a surprise. Returns slug, name, mood, and the live URL.

Args: (none)

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds return fields (slug, name, mood, live URL) but no additional behavioral context beyond that.

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 short sentences, front-loaded with purpose, no wasted words.

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 zero-parameter random selection tool with clear annotations, the description covers purpose, usage hint, and return values adequately.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so baseline is 4. The description correctly notes 'Args: (none)', and no further parameter info is needed.

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 clearly states the verb 'pick' and resource 'random fireplace from the catalog', and distinguishes from siblings by implying randomness vs. specific or list operations.

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?

Explicitly states 'Useful when you want a surprise', providing clear context for when to use, but does not explicitly mention when not to use or alternatives.

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

fireplace_recommendRecommend a Fireplace for a VibeA

Read-onlyIdempotent

Suggest a fireplace based on a vibe, mood, or use case described in plain English. Matches against tags, mood text, and palette. Returns the top 3 recommendations.

Args:

vibe: free-form description of what you want (e.g. "winter evening, cozy", "sci-fi stream backdrop", "summer night with friends")

ParametersJSON Schema

Name	Required	Description	Default
`vibe`	Yes	Free-form vibe description

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already indicate readOnlyHint=true, destructiveHint=false, idempotentHint=true. The description adds that it returns top 3 recommendations and matches on tags, mood text, palette, providing useful behavioral context beyond annotations.

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?

The description is concise, front-loading the action and purpose. It includes example args and lists matching criteria in two sentences, with no redundancy or fluff.

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?

The tool has one parameter and no output schema. The description covers input purpose and what to expect (top 3 recommendations). It does not detail the output format (e.g., list of IDs or objects), but it is largely complete for the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With 100% schema description coverage, the schema already defines the 'vibe' parameter. The description adds value by providing concrete examples and explaining how the vibe is matched (against tags, mood text, palette), enriching the parameter's semantics.

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 clearly states the tool suggests a fireplace based on a vibe/mood/use case, matching against tags, mood text, and palette, and returns top 3 recommendations. This distinguishes it from sibling tools that retrieve specific fireplace details or list styles.

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 description implies usage when a free-form vibe description is available. It doesn't explicitly exclude alternatives, but the sibling tool names (e.g., fireplace_get_embed_code) indicate different purposes. The context is clear enough for an agent to decide.

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

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.4/5.0

Disambiguation5/5

Each tool has a distinct purpose: retrieving fireplaces via different formats (URL, HTML, embed, gallery), listing all styles, random selection, and vibe-based recommendation. No two tools overlap in functionality.

Naming Consistency5/5

All tools follow the consistent pattern 'fireplace_verb_noun' (e.g., fireplace_get_url, fireplace_list_styles). The naming is uniform, descriptive, and easy to understand.

Tool Count5/5

With 7 tools, the scope is well-matched to the domain of a digital fireplace server. It provides essential operations (listing, retrieval, random, recommendation) without being too many or too few.

Completeness5/5

The tool surface covers the full consumption lifecycle: discover (list, random, recommend), retrieve (URL, HTML, embed code, gallery). There are no obvious gaps for a read-only fireplace catalog.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp-flux-pro
io.github.AceDataCloud
MCP server for Flux AI image generation
Image & Video Processing Multimedia Processing
23
Retro Diffusion Pixel Art A
ai.retrodiffusion
Generate authentic pixel art - sprites, animations, and tilesets - from any MCP client
Image & Video Processing AI & Machine Learning
2022
MCP Registry Server A
ai.com.mcp
Publish and discover MCP servers via the official MCP Registry. Powered by HAPI MCP server.
Developer Tools Search
336,314
mcp AOAuth
com.mux
The official MCP Server for the Mux API
Multimedia Processing Entertainment & Media API Testing
22168

Related MCP Servers

ls-apis-mcp
Search Open Data
koalyptus
A
license
A
quality
A
maintenance
MCP server for searching and discovering 4,000+ public APIs
Updated 4 days ago (2026-08-29 12:20 UTC)
3
MIT
aseprite-mcp
Image & Video Processing Multimedia Processing
ilhamdoanggg
A
license
Not graded
quality
D
maintenance
MCP server for programmatically creating and editing Aseprite sprites, enabling AI agents to draw, manage layers and frames, and iterate until the desired result is achieved.
Updated 3 months ago (2026-06-10 11:27 UTC)
MIT
PixelLabRat
Image & Video Processing AI & Machine Learning
DasDarki
A
license
Not graded
quality
C
maintenance
MCP server for generating style-consistent pixel art assets from PixelLab API, with project management, asset review, and an embedded Claude assistant.
Updated 3 months ago (2026-06-13 11:52 UTC)
MIT
PixelLab Forge MCP
Image & Video Processing AI & Machine Learning Design Tools
rabbitcannon
A
license
B
quality
A
maintenance
An MCP server that connects AI assistants to the PixelLab pixel art generation API. Generate sprites, tilesets, characters, animations, and more directly from Claude, Cursor, or any MCP-compatible client.
Updated 19 days ago (2026-08-15 00:24 UTC)
89
55
1
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/mhoydich/digital-fireplace-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

digital-fireplace-mcp

What's in the box

Quick start

Embed anywhere

MCP tools

How the fire engine works

Palettes

Sponsor

License

Credits

Available Tools

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API