How do I use xkcd-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., "@xkcd-mcp get the latest xkcd comic" 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.

xkcd-mcp

by sandraschi

Overview Schema Related Servers Score Discussions

Remote

xkcd-mcp

📖 Installation Guide — quick start, manual setup, and troubleshooting

MODEL CONTEXT PROTOCOL fine print sold separately

The part humans read first

xkcd-mcp Comics for your LLM. Official JSON API (/info.0.json), unofficial amount of stick-figure drama.

You get a small Vite dashboard with a comic-panel hero: stick people, a speech bubble that says MCP, explain this, and a box labeled JSON that definitely understands your feelings. The README cant draw SVG, so imagine it badlysame energy as the web app.

Alt text (this repo): A README receives a pull request titled make it whimsical. The CI passes. The narrator questions whether that was ever in scope.

Alt text (the app): A tiny server labeled JSON gets enthusiastic waves while someone negotiates with the universe. Hover tooltips not included; thats what the comic alt is for.

No scraping. No Explainxkcd body fetch. Were not here to parse HTML like its 2003.

Repo: github.com/sandraschi/xkcd-mcp

Quick Start

git clone https://github.com/sandraschi/xkcd-mcp
cd xkcd-mcp
just

This opens an interactive dashboard showing all available commands. Run just bootstrap to install dependencies, then just serve or just dev to start.

Manual Setup

If you don't have just installed:

Related MCP server: Tavily Web Search MCP Server

Technical details

What it is

MCP server + HTTP API exposing xkcd metadata and image URLs via the official API and explainxkcd semantic search.
Web UI calls POST /api/comic with the same operations as the tool (latest, random, by_number, search).

MCP tools

Tool	Description	Arguments
`xkcd_latest`	Fetch the most recent comic.	None
`xkcd_get`	Fetch a specific comic by number.	`comic_number` (int)
`xkcd_random`	Fetch a random surprise comic.	None
`xkcd_search`	Search comics by topic (aliens, climate).	`query` (str)
`xkcd_help`	Display usage guide and system info.	None

Prefab UI (Rich In-Chat Comics)

When installed with the apps extra and used in a compatible client (Claude Desktop, Antigravity), these tools render a rich PrefabApp card containing:

The comic image (high-resolution, base64-encoded).
The comic title and number.
The alt text directly below the image for context.
A link to the original xkcd page.

This provides a seamless, visual way to consume comics without leaving the chat interface.

Install

To get started, clone the repository and sync dependencies:

git clone https://github.com/sandraschi/xkcd-mcp.git
Set-Location xkcd-mcp

# Sync all dependencies (v0.2.0)
uv sync

# RECOMMENDED: FastMCP 3.2 Prefab UI support (rich in-chat comics)
uv sync --extra apps

MCP Configuration (Claude / Antigravity)

Add the following to your mcp_config.json (Antigravity) or claude_desktop_config.json (Claude):

{
  "mcpServers": {
    "xkcd": {
      "command": "uv",
      "args": ["--directory", "D:/Dev/repos/xkcd-mcp", "run", "xkcd-mcp"],
      "env": {
        "XKCD_PREFAB_APPS": "1"
      }
    }
  }
}

TIP

Ensure theargs path matches your actual disk location. Using uv run is the most reliable way to ensure the correct environment and apps extra are loaded.

Run Manual Start

uv run xkcd-mcp --serve

Item	Value
HTTP	`http://127.0.0.1:10778` `/health`, `/docs`
MCP	`http://127.0.0.1:10778/mcp`
Env	`XKCD_MCP_HOST`, `XKCD_MCP_PORT` (default 10778), `XKCD_MCP_HTTP_PATH` (default `/mcp`)

Run web UI (SPA)

.\web_sota\start.ps1

Or double-click web_sota\start.bat (launches the same script).

http://127.0.0.1:10779/ (same repo root as install)

Fleet docs (LLM index)

llms.txt short index; llms-full.txt tools, env, ports, troubleshooting.

🛡️ Industrial Quality Stack

This project adheres to SOTA 14.1 industrial standards for high-fidelity agentic orchestration:

Python (Core): Ruff for linting and formatting. Zero-tolerance for print statements in core handlers (T201).
Webapp (UI): Biome for sub-millisecond linting. Strict noConsoleLog enforcement.
Protocol Compliance: Hardened stdout/stderr isolation to ensure crash-resistant JSON-RPC communication.
Automation: Justfile recipes for all fleet operations (just lint, just fix, just dev).
Security: Automated audits via bandit and safety.

License

MIT

Available Tools

6 tools

show_comic_prefab_cardA

Show a rich prefab card for an xkcd comic. Fetches random if no number given.

This tool renders an interactive UI in the chat. Prefer it over text output when displaying data from other xkcd-mcp tools.

ParametersJSON Schema

Name	Required	Description	Default
`comic_number`	No

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description discloses key behaviors: it renders an interactive UI, fetches random if no number given. Adequate disclosure for a read-only display 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 concise sentences, front-loaded with purpose, followed by key behavior and usage guidance. No unnecessary words.

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 tool with one optional parameter and no output schema, the description covers core functionality, usage context, and default behavior. Could mention UI specifics but not essential.

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 0%, but description adds meaning by explaining that omitting the comic_number fetches a random comic. Does not elaborate on the parameter's format or constraints.

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 shows a 'rich prefab card' for an xkcd comic, and distinguishes from sibling tools by emphasizing its interactive UI and preference over text output.

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 explicit guidance to prefer this tool over text output when displaying data from other xkcd-mcp tools, and explains the random fetch behavior when no number is given. Lacks explicit when-not-to-use but context suffices.

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

xkcd_getA

Fetch a specific xkcd comic by its number.

ParametersJSON Schema

Name	Required	Description	Default
`comic_number`	Yes

TDQS

A3.5/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It accurately indicates a read operation (fetch), and for a simple comic retrieval, the behavior is transparent. However, no details on error handling or response format are given.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one sentence with no unnecessary words, making it concise. It could include more detail, but for a simple tool, this is acceptable.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has low complexity (1 param, no output schema). The description covers the basic purpose but omits details like what is returned (e.g., comic image, metadata) or error handling. It is minimally complete.

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

Parameters2/5

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

Schema description coverage is 0%, so the description must compensate. The parameter 'comic_number' is self-explanatory, but the description does not add any additional semantics (e.g., valid range, required format).

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 action ('Fetch') and the resource ('specific xkcd comic'), and uniquely identifies it by number, which distinguishes it from sibling tools like xkcd_latest or xkcd_random.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives (e.g., xkcd_search, xkcd_random), nor any conditions or prerequisites. It only states what it does.

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

xkcd_helpA

Get help and usage information for xkcd-mcp tools and configuration.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.1/5.0

Behavior3/5

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

No annotations are provided, and the description is minimal. However, the tool has no parameters and appears purely informative, so the description adequately covers its 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?

The description is a single, efficient sentence with no superfluous words, perfectly sized for its purpose.

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?

Given the tool has no parameters and no output schema, the description is complete and sufficient for an agent to understand its purpose.

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?

There are zero parameters, so the description does not need to add meaning beyond the empty schema. Baseline 4 is appropriate.

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 'Get help and usage information for xkcd-mcp tools and configuration' uses a specific verb ('Get') and resource ('help and usage information'), clearly distinguishing it from sibling tools that fetch comics.

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 obtaining help but does not explicitly state when to use this tool vs alternatives or provide any exclusions. No guidance on context is given.

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

xkcd_latestA

Fetch the latest comic from xkcd.com.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.5/5.0

Behavior2/5

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

With no annotations, the description only says 'Fetch the latest comic', which lacks details on side effects, authentication needs, rate limits, or return format. Minimal behavioral disclosure.

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 sentence, no wasted words, and directly conveys the tool's purpose. Perfectly concise for its simplicity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema and no annotations, the description provides basic purpose but omits what the tool returns (e.g., comic data, image URL). Slightly incomplete for an agent to fully anticipate behavior.

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, and schema coverage is 100%. The description adds no parameter info, but baseline for zero parameters is 4. It effectively states the tool's action without redundant details.

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?

Clearly states the tool fetches the latest comic from xkcd.com. The verb 'Fetch' and resource 'latest comic' are specific, and it is distinguished from siblings like xkcd_get (specific comic) and xkcd_random.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool vs. alternatives like xkcd_random or xkcd_get. The description does not mention when not to use or provide any contextual hints for selection.

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

xkcd_randomA

Fetch a random comic from the entire xkcd collection.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, the description carries full burden. It accurately describes a read-only operation (fetching a random comic) with no destructive behavior. The phrase 'from the entire xkcd collection' clarifies scope. 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?

A single, concise sentence that fully captures the tool's function without any extraneous words. Perfectly front-loaded.

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 no parameters, no output schema, and no annotations, the description is adequate. However, it could be slightly improved by hinting at the return type (e.g., 'Fetch a random comic object from the entire xkcd collection').

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 zero parameters and 100% schema coverage (empty schema). No parameter semantics are needed, and the description does not add param information, which is appropriate.

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 'Fetch' and the resource 'a random comic from the entire xkcd collection', making its purpose unambiguous and distinct from sibling tools like xkcd_latest and xkcd_get.

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 the tool is used when a random comic is desired, and the tool name reinforces this. No explicit when-not or alternatives are given, but the sibling names provide implicit guidance.

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

xkcd_searchB

Search for xkcd comics by topic (e.g., 'aliens', 'global warming'). Uses explainxkcd semantic indexing to find relevant comic numbers.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

TDQS

B3.4/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It mentions using 'explainxkcd semantic indexing', adding some transparency, but does not disclose error handling, empty results, or output format. Adequate but not thorough.

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, no fluff. Information is front-loaded and every word is useful. Highly concise.

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 simple structure (1 param, no output schema), the description covers the core functionality. It lacks details on return values (implied comic numbers) and limits, but is mostly complete for a search 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 coverage is 0%, so description must compensate. It implies the 'query' parameter is a topic and gives two examples, but does not specify allowed formats or lengths. Adds meaning but does not fully describe the parameter.

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 clearly states the tool searches for xkcd comics by topic, with concrete examples ('aliens', 'global warming'). It does not differentiate from sibling tools like xkcd_latest or xkcd_random, but its purpose is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives (e.g., xkcd_get for a specific comic, xkcd_random for a random comic). The description only explains what it does, not when it's appropriate.

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

A3.8/5.0

Disambiguation4/5

Most tools have distinct purposes: get by number, latest, random, search, help. However, 'show_comic_prefab_card' can fetch random if no number given, overlapping with 'xkcd_random', which could cause confusion for an agent.

Naming Consistency3/5

Five tools use the 'xkcd_' prefix (underscore style), but 'show_comic_prefab_card' breaks the pattern with a different verb and style, mixing conventions. Considering the small set, the inconsistency is noticeable.

Tool Count5/5

With 6 tools covering retrieval, search, help, and UI rendering, the count is well-scoped for a domain-specific xkcd server. Each tool serves a clear purpose without excessive overlap.

Completeness4/5

Core operations are covered: get by number, latest, random, search. A minor gap is the lack of a 'list all' or pagination tool, but search compensates for topic-based discovery. Help tool adds guidance.

Maintenance

ActivityMaintained

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

xkcd A
io.github.pipeworx-io
XKCD MCP — wraps xkcd.com JSON API (free, no auth)
Art & Culture Search Open Data
342
xkcd Comic Suggester A
io.github.papjuli
Suggests a relevant xkcd comic during a conversation, via semantic search over every comic.
Search Entertainment & Media
12
mcpOAuth
com.bullpenstrategygroup.rotunda
An MCP server that provides congressional transcripts
Government Data Search Open Data
2
RiverScript A
com.riverscript
MCP server for RiverScript, an AI transcription platform - fetches transcripts shared via a link.
Audio Processing AI & Machine Learning
11

Related MCP Servers

SearXNG Server
Search Browser Automation Web Scraping
ihor-sokoliuk
A
license
A
quality
A
maintenance
An MCP server implementation that integrates the SearxNG API, providing web search capabilities.
Updated 3 days ago (2026-09-01 11:52 UTC)
2
14,640
1,189
MIT
Tavily Web Search MCP Server
Search RAG Systems
IamKavy47
F
license
Not graded
quality
C
maintenance
An experimental MCP server that provides web search capabilities using the Tavily API. Still in progress, not production-ready.
Updated 2 months ago (2026-07-12 15:03 UTC)
yt-media-info-mcp
Multimedia Processing Search
bartivs
A
license
A
quality
A
maintenance
An MCP server that extracts rich metadata (title, description, duration, chapters, subtitles, statistics, etc.) from media URLs across thousands of sites using yt-dlp, and also provides transcript fetching and search capabilities.
Updated 2 months ago (2026-07-14 20:40 UTC)
3
MIT
scrapesearch-mcp
tonmoy-dhroubo
F
license
Not graded
quality
D
maintenance
MCP server that provides web search scraping from DuckDuckGo (with Mojeek fallback) and URL content fetching as markdown/text or raw HTML.
Updated 7 months ago (2026-01-25 21:53 UTC)
1

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/sandraschi/xkcd-mcp'

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