How do I use ascii-art-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., "@ascii-art-mcp Search for ASCII art tagged cat" 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.

de en es ja ko ru zh

ascii-art-mcp

by theduodecim

Overview Schema Source Related Servers Score Discussions Admin

Local

ascii-art-mcp

ascii-art-mcp is a Model Context Protocol (MCP) server built with Node.js and TypeScript that exposes tools for retrieving ASCII and Unicode art from a local database.

The server communicates using stdio transport, making it compatible with MCP clients such as:

Claude Desktop
Cursor
LM Studio
Open WebUI
Other MCP-compatible environments

https://theduodecim.github.io/ascii-art-mcp/

▶ Run this MCP

Just drop this link into any MCP-compatible AI chat:

https://github.com/theduodecim/ascii-art-mcp/tree/main

"Run this MCP"

The AI will clone the repo, build it, and run it automatically. No setup needed on your end.

📦 Installation

The package is available on npm:

https://www.npmjs.com/package/ascii-art-mcp

Install locally:

npm install ascii-art-mcp

Or run directly:

npx ascii-art-mcp

🌐 MCP Registry

This server is also published in the official Model Context Protocol Registry:

https://registry.modelcontextprotocol.io/?q=ascii-art

Server name:

io.github.theduodecim/ascii-art

This allows MCP-compatible tools to discover and install it automatically.

⚙️ Requirements

Node.js 20+
npm

🚀 Running the server manually

Development mode:

npm run dev

Build + production run:

npm run build
npm start

The server uses stdio transport and loads its data from:

db.json

located in the repository root.

🧰 Available MCP Tools

Related MCP server: Ascii Art AI MCP

get_ascii_art

Finds an art entry by exact nombre or by an exact value in aliases.

Input

Field	Type	Required
query	string	yes

Output

Returns the entry's art field as plain text.

search_ascii

Searches entries by categoria, tags, or both.

Input

Field	Type	Required
categoria	string	optional
tag	string	optional

At least one filter is required.

Output

Returns matching entries' art fields combined as text output.

random_ascii

Returns a random entry from the database.

Input

Field	Type	Required
tipo	ascii \| unicode	required

Output

Returns the selected entry's art field as plain text.

Lists all unique categories present in the database.

Input

None

Output

Category names as newline-separated text.

🗂 Data Model

Entries in db.json follow the AsciiArtEntry TypeScript interface:

src/types/asciiArt.ts

Each entry contains metadata such as:

name
category
tags
aliases
art content

🧪 Testing the MCP Server

A simple integration test was used to verify MCP communication using JSON-RPC over stdio.

Example test script (test.mjs):

import { spawn } from "child_process";

const proc = spawn("node", ["dist/server.js"], {
  stdio: ["pipe", "pipe", "pipe"]
});

proc.stderr.on("data", (d) => {
  console.log("LOG:", d.toString());
});

proc.stdout.on("data", (d) => {
  console.log("SERVER:", d.toString());
});

function send(msg) {
  const json = JSON.stringify(msg);
  const payload = `Content-Length: ${Buffer.byteLength(json)}\r\n\r\n${json}\r\n`;

  console.log("\nSENDING:\n", json, "\n");

  proc.stdin.write(payload);
}

setTimeout(() => {
  send({
    jsonrpc: "2.0",
    id: 1,
    method: "initialize",
    params: {
      protocolVersion: "2024-11-05",
      capabilities: {},
      clientInfo: {
        name: "tester",
        version: "1.0"
      }
    }
  });
}, 500);

setTimeout(() => {
  send({
    jsonrpc: "2.0",
    method: "initialized",
    params: {}
  });
}, 1000);

setTimeout(() => {
  send({
    jsonrpc: "2.0",
    id: 2,
    method: "tools/list"
  });
}, 1500);

setTimeout(() => {
  proc.kill();
  console.log("TEST FINISHED");
}, 4000);

🧠 Architecture

src/
  server.ts
  tools/
  types/

dist/

db.json

TypeScript MCP server
JSON database (db.json)
Zod validation for tool inputs
stdio transport

🎯 Purpose

This project demonstrates how to build a simple MCP tool server that:

runs locally
requires no API keys
exposes structured tools
serves static data through MCP

📜 License

MIT

Available Tools

4 tools

get_ascii_artA

Search an ASCII/Unicode art entry by nombre or aliases and return the art text.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes

TDQS

A3.5/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the behavioral burden. It reliably conveys a read/search operation and that the art text is returned, but it does not disclose behavior for edge cases such as no match, multiple matches, or case sensitivity. The core behavior is communicated, but not deeply.

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, front-loaded sentence that uses an active verb and provides both search scope and result. There is no filler or unnecessary repetition.

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 tool with one parameter, no nested objects, and a clear text return, the description is largely complete. It states both what is being searched and what is returned. It could mention empty/error behavior, but the simplicity of the tool limits the need.

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 schema only describes 'query' as a string with minLength 1; it gives no semantic meaning. The description compensates by explaining that the query is matched against 'nombre or aliases', which effectively defines the parameter's purpose. It could add more nuance about matching, but it is sufficient for a single-parameter tool.

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 verb 'search', the resource 'ASCII/Unicode art entry', and the lookup criteria 'by nombre or aliases'. This makes it distinct from random_ascii and list_categories, though the overlap with sibling search_ascii is not fully clarified.

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?

There is no explicit guidance on when to use this tool instead of alternatives. The description implies it is for finding an entry by known name/alias, but it does not mention exclusions or direct the agent to search_ascii for broader text search.

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

list_categoriesA

List all unique categories available in the database.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.8/5.0

Behavior2/5

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

No annotations exist, and the description does not explicitly state that the operation is read-only or safe. While 'list' implies no side effects, the absence of any safety or side-effect disclosure leaves some ambiguity.

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, concise sentence with no extraneous words. It is appropriately sized and front-loaded with the core action.

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 listing operation with no parameters and no output schema, the description fully explains what the tool does. It is complete for the tool's scope, and no additional information appears necessary.

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

Parameters5/5

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

The tool has zero parameters, so there are no parameter details to convey. The description does not need to add anything beyond the schema, and nothing is missing.

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 explicitly states the tool lists all unique categories from the database, leaving no ambiguity about its function. The verb 'list' and the object 'all unique categories' provide clear intent.

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 does not mention when to use this tool versus alternatives like get_ascii_art or search_ascii. It lacks explicit context for choosing this tool over others, though the purpose alone might imply use when category listing is needed.

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

random_asciiA

Return a random ASCII/Unicode art entry, optionally filtered by tipo.

ParametersJSON Schema

Name	Required	Description	Default
`tipo`	No

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 carries full behavioral disclosure burden. It only states what it returns, not any side effects (though likely read-only), determinism, or failure modes. It doesn't mention if the result could be empty, or whether the filter restricts the random pool. Minimal behavioral insight beyond the immediate action.

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. It packs the core information (random + optional filter) without wasted words. Perfectly sized for a simple tool.

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 the tool's low complexity (1 optional param, no output schema, no annotations), the description is minimally complete. It states what it returns and how to filter. However, it lacks context on when to use this vs siblings, and does not indicate if the selection is truly uniform or if there are any edge cases (e.g., empty category). For a straightforward read-only tool, it's adequate but not thorough.

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 schema defines 'tipo' as an enum (ascii/unicode), so baseline is 3 due to schema coverage. The description adds the meaning that it acts as a filter ('optionally filtered by tipo'), which is useful. However, it doesn't elaborate beyond that—no format details or examples, so it neither fully compensates for the 0% schema description coverage nor adds substantial extra meaning.

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's action (return a random art entry) and identifies the resource (ASCII/Unicode art) with an optional filter. It inherently distinguishes from siblings like get_ascii_art (specific retrieval) and search_ascii (filtered search) by emphasizing randomness. The verb 'Return' is explicit and the scope is well-defined.

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 a random art entry, but does not explicitly compare to alternatives or state when not to use it. There is no mention of when to prefer this over search_ascii or get_ascii_art. It provides a clear context (random selection) but no exclusions or contrast with sibling tools.

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

search_asciiA

Search entries by categoria or tags and return matching art texts.

ParametersJSON Schema

Name	Required	Description	Default
`tag`	No
`categoria`	No

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 transparency burden. It states the action ('search') and outcome ('return matching art texts'), which implies a read-only operation. It does not explicitly mention side effects, but the nature of search suggests no state changes, so it is reasonably transparent.

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, concise sentence with no superfluous information. It directly communicates the tool's purpose 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?

Given the simple context and the existence of sibling tools, the description adequately covers the essential information. It does not explain return format or edge cases, but the lack of an output schema makes that less critical. Overall, it provides enough context for a basic understanding.

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 provides no descriptions, but the description mentions 'categoria or tags', giving some meaning to the parameters. However, it does not clarify whether both are optional, how they combine, or acceptable formats, so it adds partial value beyond the schema.

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 that the tool searches entries by categoria or tags and returns matching art texts. It uses a specific verb ('search') and resource ('entries'), and it is distinct from sibling tools like get_ascii_art, random_ascii, and list_categories.

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 searching, but it does not explicitly contrast with alternatives or explain when this tool should be preferred over others. It lacks guidance on context, such as whether to use it when looking for specific art texts.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

4 tool updatesv0.1.1Aug 20, 2026
- First observedget_ascii_art
- First observedlist_categories
- First observedrandom_ascii
- First observedsearch_ascii

Install Server

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

TDQS

A3.9/5.0

Scored 2026-08-20 15:00 across 4 tools

Disambiguation4/5

get_ascii_art and search_ascii both return matching art texts, which could cause some confusion, but they are distinguished by query type (name/aliases vs. category/tags). random_ascii and list_categories are clearly distinct.

Naming Consistency4/5

Three tools follow a clear verb_noun pattern (get_ascii_art, search_ascii, list_categories), and random_ascii is still readable and consistent in snake_case despite lacking a typical verb prefix.

Tool Count5/5

With only 4 tools, the server is tightly scoped to ASCII art retrieval and discovery. Every tool serves a useful purpose and the count feels appropriate for the niche domain.

Completeness5/5

The server covers the core read-only workflows: finding by name, browsing by category/tag, getting random art, and listing available categories. There are no obvious missing operations for an ASCII art lookup service.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

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

Context Awesome A
io.github.bh-rat
MCP server for accessing curated awesome list documentation
Documentation Access Research & Data
2259
mcp A
ai.llmse
Public MCP server for the LLM Search Engine
Search RAG Systems Developer Tools
102
podcasts A
com.petabloom
An MCP server that provides tools to discover and retrieve podcast episodes transcripts.
Entertainment & Media Search
52
asset-auto-generator
io.github.TranThienTrong
An MCP server that provides asset auto generator
Developer Tools App Automation
2

Related MCP Servers

ASCII Banner MCP Server
Developer Tools Shell Access
guilyx
A
license
A
quality
D
maintenance
An MCP server for getting ASCII banners
Updated 7 months ago (2026-02-02 06:38 UTC)
2
MIT
Ascii Art AI MCP
Image & Video Processing AI & Machine Learning
CSOAI-ORG
A
license
Not graded
quality
B
maintenance
Ascii Art AI - MCP server providing AI-powered tools and automation by MEOK AI Labs
Updated 5 days ago (2026-09-04 12:35 UTC)
8
MIT
MusicBrainz MCP Server
Search Entertainment & Media Open Data
usercourses63
A
license
Not graded
quality
C
maintenance
A comprehensive MCP server for querying the MusicBrainz database, providing tools to search for artists, releases, recordings, and browse music metadata.
Updated a year ago (2025-09-15 08:44 UTC)
4
MIT
monosketch-mcp
Software Architecture Design Tools
supersterling
F
license
Not graded
quality
D
maintenance
An MCP server that enables AI agents to create beautiful ASCII diagrams using Unicode box-drawing characters, with support for stateful canvas operations, multiple shape types, and style customization.
Updated 7 months ago (2026-02-13 21:45 UTC)
2
-

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/theduodecim/ascii-art-mcp'

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