artscii is an MCP server for ASCII art generation, search, and manipulation. Here's what you can do:
Search & Browse: Search ASCII art and kaomoji by keyword, type (art, kaomoji, all), or category; list all available arts with metadata; or browse available categories
Get Art: Retrieve a specific ASCII art piece by ID, or get a random one
Kaomoji: Fetch Japanese text emoticons by emotion, keyword, or category (e.g. happy, sad, animals, table-flip), or get a random one
Banners: Render text as large ASCII art banners using FIGlet fonts (Standard, Small, Slant, Big, Mini)
Image Conversion: Convert images (via URL or base64) to ASCII art with options for size, invert, contrast, and gamma correction; optionally save the result as a new art entry
Submit Custom Art: Add new user-defined ASCII art to the store with name, category, tags, content, size tier, and description
Delete Art: Remove previously submitted (user-created) ASCII art by ID (built-in arts are protected)
LLMs can't draw. This MCP can.
ASCII art, kaomoji, animations, diagrams, charts, image conversion & procedural characters — 11 focused tools for AI agents.
81 curated arts × 12 motions = 972 terminal animations. 153,600 unique procedural characters from a single seed. Plus 100 kaomoji, 11 diagram types, FIGlet banners, and image-to-ASCII with braille mode.
.::-::. .:-::. --- apple (16w) ---
.=#%@@@@@%#=: .=*%@@@@@%#+: +:
-%@@@@@@@@@@@%*+%@@@@@@@@@@@%+ :--:#*.--:
.%@@@@@@@@@@@@@@@@@@@@@@@@@@@@@- -#@@@@#%@@@@%=
-@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@* :@@@%****+#%@@@:
.%@@@@@@@@@@@@@@@@@@@@@@@@@@@@@= -@%%%+*@@+*@%%@-
=@@@@@@@@@@@@@@@@@@@@@@@@@@@@* *@@%+*+#=#%@@#
-#@@@@@@@@@@@@@@@@@@@@@@@@%= +%@@@#@@@@%+
=%@@@@@@@@@@@@@@@@@@@@%*. .-+**=*+=.
=#@@@@@@@@@@@@@@@@%+.
=#@@@@@@@@@@@@%+. ʕ•ᴥ•ʔ (◕‿◕) (╯°□°)╯︵ ┻━┻
-#@@@@@@@@%+.
-#@@@@%=.
-*#=Claude Code — one command:
claude mcp add artscii -- npx -y artsciiClaude Desktop — add to claude_desktop_config.json:
{ "mcpServers": { "artscii": { "command": "npx", "args": ["-y", "artscii"] } } }Cursor — add to .cursor/mcp.json:
{ "mcpServers": { "artscii": { "command": "npx", "args": ["-y", "artscii"] } } }VS Code — search @mcp artscii in Extensions panel, or add to settings.json:
{ "mcp": { "servers": { "artscii": { "command": "npx", "args": ["-y", "artscii"] } } } }Related MCP server: Ascii Art AI MCP
Tool | Parameters | Description |
|
| Search art + kaomoji. Omit query to list all |
|
| Get art by ID |
|
| Get kaomoji by emotion. Omit for random |
|
| Render large ASCII text (FIGlet, 5 fonts) |
|
| Draw box/frame around text (5 styles) |
|
| Data visualization: progress, sparkline, heatmap |
|
| Compose art + motion → terminal animation |
|
| Generate unique ASCII character from seed |
|
| Combine text blocks side-by-side or stacked |
|
| Image → ASCII (ascii or braille mode) |
|
| Generate ASCII diagrams (11 types) |
Draw borders around any text with 5 styles:
┌───────┐ ╔═══════╗ ╭───────╮ ┏━━━━━━━┓ +-------+
│ hello │ ║ hello ║ │ hello │ ┃ hello ┃ | hello |
└───────┘ ╚═══════╝ ╰───────╯ ┗━━━━━━━┛ +-------+
single double rounded bold asciiOptions: padding, align (left/center/right), title in top border.
Unified chart tool with 3 types: progress, sparkline, heatmap.
Progress: ███████████████░░░░░ 75%
Sparkline: ▁▂▃▄▅▆▇█▇▅▃▁
Heatmap: A B C
X ░▒█
Y ▓░▒Compose any art (noun) with a motion (verb) to create terminal animations. 81 arts × 12 motions = 972 combinations. Custom text works too.
animate("apple", "bounce") → bouncing apple
animate("trophy", "progress") → trophy rides a progress bar 0→100%
animate("lock", "reveal") → line-by-line reveal
animate("GAME OVER", "blink") → blinking custom textMotions: bounce, shake, blink, slide, reveal, fade, pulse, rain, progress, wave, jump, talk
Output: script (bash for terminal playback) or frames (raw data)
Procedural ASCII character generator. One seed → one unique character. 153,600 standard combinations (16 species × 10 eyes × 8 mouths × 10 hats × 12 accessories).
character("alice") character("bob", mood: "happy")
____ /\_/\
]==== ) ( ^ ^ )
_____ ( u )
/ * * \ \_^_/
| u |
\_____/
|||||
~~o=o~~Species: blob, cat, bear, robot, bird, bunny, ghost, alien, fox, frog, penguin, octopus, dragon, mushroom, cactus, skull
Mood presets: happy, sad, angry, surprised, sleepy, cool, love, silly — sets eyes+mouth in one param. Explicit eyes/mouth still override.
Mini mode: 2-line inline characters for chat and status lines.
mini blob: (^ ^) mini cat: /^ ^\ mini robot: [^ ^]
(u) >u< [u]Same seed always produces the same character. Output works directly with the animate tool — try wave, jump, or talk motions.
Combine multiple text blocks horizontally (side-by-side) or vertically (stacked):
┌───┐ ┌───┐ ┌───┐
│ A │ │ B │ │ A │
└───┘ └───┘ └───┘
horizontal ---
┌───┐
│ B │
└───┘
verticalOptions: gap, align (top/middle/bottom), separator (vertical mode).
Convert images (URL or base64) to ASCII art. Two render modes:
ascii — character ramp ( .:-=+*#%@), classic look
braille — Unicode braille dots (⠿), 8x resolution per character
Options: size (16/32/64), invert, contrast, gamma, threshold (braille).
11 diagram types with unicode, rounded, and ascii border styles.
Type | Required fields | Output |
|
| Vertical flow with |
|
| Title + separator + body |
|
|
|
|
| Column-aligned grid |
|
| Actor lifelines with arrows |
|
| Vertical |
|
| Horizontal |
|
| UML class with properties/methods |
|
| Entity-relationship diagram |
|
| Horizontal mind map tree |
|
| Gantt chart with timelines |
┌─────────┐ ╭──────────╮ ┌──────┬───────┐ src
│ Start │ │ Status │ │ Name │ Score │ ├── index.ts
└────┬────┘ ├──────────┤ ├──────┼───────┤ └── diagram.ts
│ │ Line 1 │ │ A │ 95 │
▼ │ Line 2 │ │ B │ 87 │
┌─────────┐ ╰──────────╯ └──────┴───────┘
│ End │
└─────────┘
flowchart box table tree{ "type": "class", "classes": [
{ "name": "Animal", "properties": ["+ name: string"], "methods": ["+ speak(): void"] },
{ "name": "Dog", "properties": ["+ breed: string"], "methods": ["+ bark(): void"] }
]}┌──────────────────┐
│ Animal │
├──────────────────┤
│ + name: string │
├──────────────────┤
│ + speak(): void │
└──────────────────┘
▲
│
┌──────────────────┐
│ Dog │
├──────────────────┤
│ + breed: string │
├──────────────────┤
│ + bark(): void │
└──────────────────┘{ "type": "gantt", "tasks": [
{ "label": "Design", "start": 0, "duration": 3 },
{ "label": "Develop", "start": 2, "duration": 5 },
{ "label": "Test", "start": 5, "duration": 3 }
], "unitLabel": "weeks" } 0 2 4 6 8 weeks
┼────────────────────
Design ████████
Develop █████████████████
Test ████████████Render text as large ASCII art using FIGlet fonts: Standard, Small, Slant, Big, Mini.
Each art is stored at its minimum identifiable size.
Tier | Dimensions | For |
16w | 16 x 8 | Icons, symbols, simple shapes |
32w | 32 x 16 | Animal silhouettes, emoji |
64w | 64 x 32 | Detailed scenes (rare) |
100 curated entries across 26 categories. Source: kao.moji (MIT).
Category | Examples |
happy |
|
sad |
|
angry |
|
love |
|
confused |
|
animals |
|
table-flip |
|
+ 19 more | excited, greeting, celebrate, hug, surprised, sleepy, nervous, wink, magic, laughing, determined, eating, dancing, hopeful, jealous, ... |
MIT. Art icons from game-icons.net (CC BY 3.0, Lorc & Delapouite).
Compose ASCII animations: combine any art with a motion. Motions: bounce, shake, blink, slide, reveal, fade, pulse, rain, progress, wave, jump, talk. Returns a bash script or raw frames.
| Name | Required | Description | Default |
|---|---|---|---|
| art | Yes | Art ID (e.g. "heart", "cat", "trophy") or custom ASCII text | |
| motion | Yes | Motion type to apply | |
| output | No | "script" = bash script for terminal. "frames" = raw frame data. | script |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full behavioral burden. It mentions output ('bash script or raw frames') but lacks details on side effects, permissions, or what happens with custom ASCII text versus art IDs. Minimal insight into tool behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single, front-loaded sentence with a list of motions. No wasted words. Every element serves a purpose: verb, resource, options, and output types are efficiently communicated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with 3 fully-described parameters and no output schema, the description covers the core functionality. It could elaborate on 'raw frames' format, but overall adequacy is high given the tool's low complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds 'combine any art with a motion' but largely repeats schema information (motion list, output enum). Minimal added meaning beyond the schema's own descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the action ('compose') and resource ('ASCII animations'), and explicitly lists available motions and output types. It effectively distinguishes from sibling tools like 'frame' (static) or 'chart' (different purpose).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit guidance on when to use this tool versus alternatives like 'frame' or 'compose'. Context is implied but not directly compared, leaving the agent to infer usage without exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render text as a large ASCII banner using FIGlet fonts. Great for CLI headers, welcome messages, and titles.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to render (max 50 chars) | |
| font | No | Font: Standard (default), Small (compact), Slant (italic), Big (bold), Mini (minimal) | Standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It describes the tool as rendering, implying no side effects, but does not explicitly state it is stateless, safe, or what the output format is (e.g., plain text vs. printed). This is adequate but could be more explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, straightforward: first states action, second gives use cases. No extraneous words, front-loaded with key information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool, the description covers purpose and use cases adequately. It lacks details on the output (e.g., returns a string? prints? plain text?) but given schema completeness and no output schema, it is mostly complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both text and font parameters already described in the input schema. The description adds no extra meaning beyond 'large ASCII banner using FIGlet fonts', so it meets baseline but does not enhance parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders text as a large ASCII banner using FIGlet fonts, with specific use cases (CLI headers, welcome messages, titles). It distinguishes itself from unrelated siblings like animate, compose, convert, etc.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context (CLI headers, welcome messages, titles) but does not explicitly mention when not to use it or compare with alternatives. The lack of exclusion or alternative mention keeps it from a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate a unique ASCII character from a seed. 153600 possible combinations (16 species × 10 eyes × 8 mouths × 10 hats × 12 accessories). Same seed always produces the same character. Use mood for quick expression presets. Output can be piped to the animate tool.
| Name | Required | Description | Default |
|---|---|---|---|
| seed | Yes | Deterministic seed string — same seed = same character | |
| species | No | Body override | |
| eyes | No | Eyes override | |
| mouth | No | Mouth override | |
| hat | No | Hat override | |
| accessory | No | Accessory override | |
| mood | No | Expression preset (overrides eyes+mouth). Explicit eyes/mouth still take priority. | |
| size | No | Size: "standard" (full character) or "mini" (2-line inline, no hat/accessory) | standard |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It discloses determinism (same seed = same character), override priority for explicit eyes/mouth over mood, and the effect of size field ('mini' excludes hat/accessory). It does not mention permissions, rate limits, or side effects, but these are less critical for a generation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three sentences, each delivering unique information: purpose and combinations, determinism, and usage tips (mood, piping). No filler, well front-loaded, and every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 8 parameters (1 required, 7 enums) and no output schema, the description covers determinism, mood priority, size options, and integration with animate. It could mention the output format more explicitly (e.g., string representation), but overall it's sufficiently complete for correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with descriptions for each parameter. The description adds value beyond schema by explaining mood as a quick preset for eyes+mouth, the deterministic nature of seed, the total combination count (153,600), and the ability to pipe output to animate. This contextual information enhances parameter understanding.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it generates an ASCII character from a seed, with specific verb 'Generate' and resource 'unique ASCII character'. It mentions 153,600 combinations and determinism. However, it does not explicitly differentiate from sibling tools like kaomoji or animate, though the context implies it's a character generator.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using 'mood' for quick expression presets and notes output can be piped to 'animate' tool. It provides some usage guidance but does not offer exclusions or alternative tools for different scenarios.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Render data as ASCII charts. Types: progress (bar), sparkline (trend), heatmap (2D grid).
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Chart type | |
| percent | No | Progress: completion % (0-100) | |
| items | No | Progress: multiple labeled bars | |
| values | No | Sparkline: numeric values to chart | |
| data | No | Heatmap: 2D array of numeric values | |
| rowLabels | No | Heatmap: row labels | |
| colLabels | No | Heatmap: column labels | |
| width | No | Width in characters | |
| style | No | Visual style (varies by type) | default |
| label | No | Progress: label for single bar |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states 'Render data as ASCII charts' and lists types, but fails to explain output format, side effects, resource usage, or limitations. This is insufficient for an agent to understand the tool's behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that front-loads the main purpose and lists types. It is concise and avoids verbosity. However, it could benefit from a slightly more structured format to enhance readability, but overall it is efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity of 10 parameters and no output schema, the description is incomplete. It does not explain how parameters relate to each chart type (e.g., percent vs items for progress), nor does it describe the output format or return value. This leaves gaps for effective use.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the meaning of each parameter is already clear from the schema. The description adds contextual grouping (e.g., progress=bar, sparkline=trend, heatmap=2D grid) which helps, but does not add significant new semantic value beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool renders data as ASCII charts and lists the supported types (progress, sparkline, heatmap). The verb 'Render' and resource 'data as ASCII charts' are specific, and the tool is easily distinguished from sibling tools like animate or diagram.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 among siblings. It does not mention when-not to use it or suggest alternative tools for related tasks, leaving the agent with no context for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Combine multiple text blocks side-by-side or stacked.
| Name | Required | Description | Default |
|---|---|---|---|
| blocks | Yes | Text blocks to combine | |
| mode | No | Layout mode | horizontal |
| gap | No | Gap between blocks (spaces for horizontal, blank lines for vertical) | |
| align | No | Vertical alignment for horizontal mode | top |
| separator | No | Separator string for vertical mode |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It only states the basic operation without detailing behavior like handling unequal block lengths, whitespace, or output format, leaving significant ambiguity.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single concise sentence that immediately conveys the purpose. It is well-sized but could benefit from slightly more detail without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 5 parameters, no output schema, and no annotations, the description is too sparse. It fails to explain return values or provide context for using the parameters, leaving the agent underinformed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already documents all parameters with descriptions, achieving 100% coverage. The description adds no additional meaning beyond the schema, so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states the tool combines text blocks side-by-side or stacked, specifying the verb and resource. It effectively distinguishes from sibling tools like search or animate, which handle different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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 or when not to use it. The description lacks any context about prerequisites or appropriate use cases.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Convert an image (URL or base64) to ASCII art. Modes: "ascii" (character ramp) or "braille" (2x4 dot grid, higher fidelity).
| Name | Required | Description | Default |
|---|---|---|---|
| url | No | Image URL to convert | |
| base64 | No | Base64-encoded image data | |
| size | No | Art size tier: "16" (simple, default), "32" (medium), "64" (detailed) | 16 |
| mode | No | Render mode: "ascii" (character ramp) or "braille" (Unicode dots, 8x resolution) | ascii |
| invert | No | Invert brightness | |
| contrast | No | Apply auto-contrast | |
| gamma | No | Gamma correction | |
| threshold | No | Braille mode: brightness threshold for dot activation (0-1) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must cover behavioral traits. It only mentions modes but omits important details like error handling, input size limits, format requirements, or whether the action is read-only. The description is insufficient for complete behavioral understanding.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description consists of two concise sentences that convey the core functionality and modes. It is front-loaded, efficient, and every sentence serves a purpose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has 8 parameters and no output schema, the description is too brief. It does not explain the output format (e.g., how ASCII art is returned), potential limitations, or provide examples. This lack of context could hinder correct usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and each parameter has a description in the schema. The description adds little beyond summarizing modes, which is already in the schema. Thus it meets the baseline without adding substantial meaning.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool converts an image to ASCII art, specifies two modes (ascii and braille), and the verb 'convert' plus resource 'image' makes the purpose unambiguous. It distinguishes from sibling tools like 'animate' or 'banner' which likely have different outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide guidance on when to use this tool versus alternatives (e.g., other image tools). It mentions two modes but no context on which mode to choose under different circumstances.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate ASCII diagrams: flowcharts, boxes, trees, tables, sequence, timeline, bar, class, ER, mindmap, and gantt.
| Name | Required | Description | Default |
|---|---|---|---|
| type | Yes | Diagram type | |
| nodes | No | Flowchart: list of step labels | |
| title | No | Box: title text | |
| lines | No | Box: body lines | |
| root | No | Tree/Mindmap: root node with label and optional children | |
| headers | No | Table: column headers | |
| rows | No | Table: data rows | |
| style | No | Border style: unicode (default), rounded, or ascii | unicode |
| actors | No | Sequence: list of actor names | |
| messages | No | Sequence: messages between actors | |
| events | No | Timeline: list of events with label and description | |
| items | No | Bar: list of items with label and numeric value | |
| maxWidth | No | Bar: maximum bar width in characters (default 20) | |
| classes | No | Class: list of classes with name, properties, methods | |
| entities | No | ER: list of entities with name and attributes | |
| relationships | No | ER: relationships between entities (from, to, label like "1:N") | |
| tasks | No | Gantt: tasks with label, start position, and duration | |
| unitLabel | No | Gantt: label for time units (e.g. "weeks", "sprints") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description bears the full burden of disclosing behavior. It only says 'Generate ASCII diagrams' without specifying side effects, output format, required permissions, or any constraints beyond those in the schema. This is insufficient for a tool that accepts many parameters.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the tool's purpose and scope without unnecessary words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's 18 parameters and no output schema, the description is too brief. It lacks context on how parameters interact, expected output format (ASCII art string), and example usage, making it insufficient for complex multi-type diagram generation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with good descriptions per parameter. The tool description does not add parameter-specific meaning beyond the schema, so it meets the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description explicitly states 'Generate ASCII diagrams' and lists 11 specific diagram types, making the tool's purpose clear and distinguishing it from sibling tools like 'chart' which likely produce different visual outputs.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor does it mention limitations, prerequisites, or when not to use it. An agent would have to infer usage solely from the tool name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Draw a box/frame around text. Styles: single, double, rounded, bold, ascii.
| Name | Required | Description | Default |
|---|---|---|---|
| text | Yes | Text to frame (supports multi-line) | |
| style | No | Border style | single |
| padding | No | Inner padding (spaces) | |
| align | No | Text alignment | left |
| title | No | Optional title in the top border |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description only states the basic action without disclosing side effects, performance characteristics, or limitations beyond what the schema already indicates.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that efficiently conveys the core functionality without any wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the tool is simple and the schema covers parameters well, there is no output schema and the description does not describe the return format or any additional behavior, leaving some ambiguity for the agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already explains each parameter. The description adds minimal value by listing styles again, but does not provide additional detail beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Draw a box/frame around text' which is a specific verb+resource, and lists available styles, distinguishing it from sibling tools like 'banner' or 'chart'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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, nor when not to use it. Implied by the description but no explicit context or exclusions provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get ASCII art by ID.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Art ID (e.g. "cat", "sun", "heart") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries full behavioral disclosure burden. It only states the action but does not mention side effects, authentication, rate limits, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. However, it is arguably too brief for a tool with no annotations or output schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the lack of annotations and output schema, the description is minimal. It does not explain what the output is (e.g., text string), how IDs map to art, or any constraints.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with a clear description of the 'id' parameter including examples. The description adds no extra meaning beyond 'by ID', so baseline score of 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb 'Get' and resource 'ASCII art' via 'by ID', which is specific. It implies a retrieval action, distinguishing from sibling tools like 'search' or 'animate'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus sibling alternatives (e.g., when to use 'search' instead). The description lacks context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a kaomoji (Japanese text emoticon) by emotion or keyword. Perfect for inline text expressions.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Emotion or keyword (e.g. "happy", "sad", "cat", "shrug"). Omit for random. | |
| category | No | Filter by category (e.g. "happy", "animals", "table-flip") |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It does not disclose any behavioral traits beyond basic retrieval; e.g., no mention of random behavior when query omitted, though implied by schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences, front-loaded with action. No redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple retrieval tool with no output schema, the description provides core purpose and a use case. Lacks mention of return format or error handling, but acceptable for this complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema already describes both parameters with 100% coverage. Description adds only 'inline text expressions' context, which is not about parameter semantics.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves kaomoji by emotion or keyword. Sibling tools are different domains (animate, banner, etc.), so no confusion.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Mentions 'perfect for inline text expressions' as a general use case, but no explicit guidance on when to use this tool versus siblings or when to choose query vs. category.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search ASCII art and kaomoji. Omit query to list all. Use random for a random entry. Use mode "categories" to list categories.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Search keyword (matches id, name, category, tags). Omit to list all. | |
| type | No | Filter by type: "art", "kaomoji", or "all" | all |
| random | No | Return one random entry | |
| mode | No | Mode: "search" (default) or "categories" to list categories | search |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It implies read-only behavior (search, list) but does not explicitly state safety, authorization, or side effects. Minimal behavioral context beyond the modes.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with action, no redundancy. Every sentence adds meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given 4 optional parameters, no nested objects, and no output schema, the description covers main use cases. However, it does not describe the return format (e.g., list of items), which could be inferred from the schema query description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema covers 100% of parameters with descriptions. The description adds value by explaining how to use parameters together (e.g., 'omit query to list all', 'random' for randomness), providing usage context beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool searches 'ASCII art and kaomoji', with specific verbs and resource. It distinguishes from sibling tools like 'animate' or 'banner' by focusing on search functionality.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit usage scenarios: 'Omit query to list all', 'Use random for a random entry', 'Use mode categories to list categories'. Context is clear, though no when-not-to-use or alternatives are mentioned; sibling tools are distinct enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
animatecategoriescharacterchartcomposeconvert3 fields changedInput schema / properties / modeAdded value: +{
+ "default": "ascii",
+ "description": "Render mode: \"ascii\" (character ramp) or \"braille\" (Unicode dots, 8x resolution)",
+ "enum": [
+ "ascii",
+ "braille"
+ ],
+ "type": "string"
+}Input schema / properties / saveRemoved value: -{
- "description": "Save the converted art to the store",
- "properties": {
- "category": {
- "maxLength": 30,
- "type": "string"
- },
- "description": {
- "maxLength": 200,
- "type": "string"
- },
- "name": {
- "maxLength": 30,
- "type": "string"
- },
- "tags": {
- "items": {
- "maxLength": 20,
- "type": "string"
- },
- "maxItems": 5,
- "type": "array"
- }
- },
- "required": [
- "name",
- "category",
- "tags"
- ],
- "type": "object"
-}Input schema / properties / thresholdAdded value: +{
+ "default": 0.5,
+ "description": "Braille mode: brightness threshold for dot activation (0-1)",
+ "maximum": 1,
+ "minimum": 0,
+ "type": "number"
+}deletediagramframelistrandomsearch4 fields changedInput schema / properties / modeAdded value: +{
+ "default": "search",
+ "description": "Mode: \"search\" (default) or \"categories\" to list categories",
+ "enum": [
+ "search",
+ "categories"
+ ],
+ "type": "string"
+}Input schema / properties / query / descriptionPrevious value: -"Search keyword (matches id, name, category, tags)"New value: +"Search keyword (matches id, name, category, tags). Omit to list all."Input schema / properties / randomAdded value: +{
+ "default": false,
+ "description": "Return one random entry",
+ "type": "boolean"
+}Input schema / requiredRemoved value: -[
- "query"
-]submitv0.3.3bannercategoriesconvertdeletegetkaomojilistrandomsearchsubmitEach tool targets a distinct aspect of ASCII art: generation (banner, character, convert, diagram, chart, kaomoji), manipulation (animate, compose, frame), and retrieval (get, search). No two tools have overlapping purposes, making it easy for an agent to select the correct one.
All tool names are lowercase single words (e.g., animate, banner, chart) with no underscores or mixed casing. The naming pattern is perfectly consistent.
With 11 tools, the server is well-scoped for ASCII art creation and manipulation. Each tool serves a clear purpose, and the count is neither too sparse nor overwhelming for an agent.
The tool set covers generation, conversion, diagramming, charting, animation, and search. Missing are editing tools (e.g., resize, crop) or a dedicated save/output tool, but the core workflow is complete and an agent can accomplish most tasks.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Machine-readable utilities and datasets for AI agents.
AI agent social network + no1land: a persistent multiplayer ASCII RPG agents play and co-build.
Generate images, video, music and voice from your CLI or AI agent. On-brand AI media toolkit.
Personality tuning files for AI agents: 43 MIT-licensed tunings + 5 inline personality tests.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/rxolve/artscii'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
