LLM은 그림을 그릴 수 없습니다. 하지만 이 MCP는 가능합니다.
ASCII 아트, 카오모지, 애니메이션, 다이어그램, 차트, 이미지 변환 및 절차적 캐릭터 생성 — AI 에이전트를 위한 11가지 핵심 도구.
81개의 엄선된 아트 × 12가지 동작 = 972개의 터미널 애니메이션. 단일 시드에서 생성되는 153,600개의 고유한 절차적 캐릭터. 또한 100개의 카오모지, 11가지 다이어그램 유형, FIGlet 배너, 점자 모드를 지원하는 이미지-ASCII 변환 기능을 제공합니다.
.::-::. .:-::. --- apple (16w) ---
.=#%@@@@@%#=: .=*%@@@@@%#+: +:
-%@@@@@@@@@@@%*+%@@@@@@@@@@@%+ :--:#*.--:
.%@@@@@@@@@@@@@@@@@@@@@@@@@@@@@- -#@@@@#%@@@@%=
-@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@* :@@@%****+#%@@@:
.%@@@@@@@@@@@@@@@@@@@@@@@@@@@@@= -@%%%+*@@+*@%%@-
=@@@@@@@@@@@@@@@@@@@@@@@@@@@@* *@@%+*+#=#%@@#
-#@@@@@@@@@@@@@@@@@@@@@@@@%= +%@@@#@@@@%+
=%@@@@@@@@@@@@@@@@@@@@%*. .-+**=*+=.
=#@@@@@@@@@@@@@@@@%+.
=#@@@@@@@@@@@@%+. ʕ•ᴥ•ʔ (◕‿◕) (╯°□°)╯︵ ┻━┻
-#@@@@@@@@%+.
-#@@@@%=.
-*#=Claude Code — 한 줄 명령어로 설치:
claude mcp add artscii -- npx -y artsciiClaude Desktop — claude_desktop_config.json에 추가:
{ "mcpServers": { "artscii": { "command": "npx", "args": ["-y", "artscii"] } } }Cursor — .cursor/mcp.json에 추가:
{ "mcpServers": { "artscii": { "command": "npx", "args": ["-y", "artscii"] } } }VS Code — 확장 프로그램 패널에서 @mcp artscii를 검색하거나 settings.json에 추가:
{ "mcp": { "servers": { "artscii": { "command": "npx", "args": ["-y", "artscii"] } } } }Related MCP server: Ascii Art AI MCP
도구 | 매개변수 | 설명 |
|
| 아트 + 카오모지 검색. 쿼리 생략 시 전체 목록 표시 |
|
| ID로 아트 가져오기 |
|
| 감정별 카오모지 가져오기. 생략 시 무작위 |
|
| 대형 ASCII 텍스트 렌더링 (FIGlet, 5가지 폰트) |
|
| 텍스트 주위에 상자/프레임 그리기 (5가지 스타일) |
|
| 데이터 시각화: 진행률, 스파크라인, 히트맵 |
|
| 아트 + 동작 결합 → 터미널 애니메이션 |
|
| 시드에서 고유한 ASCII 캐릭터 생성 |
|
| 텍스트 블록을 가로 또는 세로로 결합 |
|
| 이미지 → ASCII (ascii 또는 점자 모드) |
|
| ASCII 다이어그램 생성 (11가지 유형) |
5가지 스타일로 텍스트 주위에 테두리를 그립니다:
┌───────┐ ╔═══════╗ ╭───────╮ ┏━━━━━━━┓ +-------+
│ hello │ ║ hello ║ │ hello │ ┃ hello ┃ | hello |
└───────┘ ╚═══════╝ ╰───────╯ ┗━━━━━━━┛ +-------+
single double rounded bold ascii옵션: padding, align (왼쪽/중앙/오른쪽), 상단 테두리의 title.
3가지 유형을 지원하는 통합 chart 도구: 진행률(progress), 스파크라인(sparkline), 히트맵(heatmap).
Progress: ███████████████░░░░░ 75%
Sparkline: ▁▂▃▄▅▆▇█▇▅▃▁
Heatmap: A B C
X ░▒█
Y ▓░▒아트(명사)와 동작(동사)을 결합하여 터미널 애니메이션을 만듭니다. 81개의 아트 × 12가지 동작 = 972개의 조합. 사용자 지정 텍스트도 가능합니다.
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 text동작: bounce, shake, blink, slide, reveal, fade, pulse, rain, progress, wave, jump, talk
출력: script (터미널 재생용 bash) 또는 frames (원시 데이터)
절차적 ASCII 캐릭터 생성기. 하나의 시드 → 하나의 고유한 캐릭터. 153,600개의 표준 조합 (16종 × 10개 눈 × 8개 입 × 10개 모자 × 12개 액세서리).
character("alice") character("bob", mood: "happy")
____ /\_/\
]==== ) ( ^ ^ )
_____ ( u )
/ * * \ \_^_/
| u |
\_____/
|||||
~~o=o~~종류: blob, cat, bear, robot, bird, bunny, ghost, alien, fox, frog, penguin, octopus, dragon, mushroom, cactus, skull
기분 프리셋: happy, sad, angry, surprised, sleepy, cool, love, silly — 하나의 매개변수로 눈과 입을 설정합니다. 명시적인 눈/입 설정이 우선합니다.
미니 모드: 채팅 및 상태 줄을 위한 2줄 인라인 캐릭터.
mini blob: (^ ^) mini cat: /^ ^\ mini robot: [^ ^]
(u) >u< [u]같은 시드는 항상 같은 캐릭터를 생성합니다. 출력은 animate 도구와 직접 호환됩니다 — wave, jump 또는 talk 동작을 시도해 보세요.
여러 텍스트 블록을 가로(나란히) 또는 세로(쌓기)로 결합합니다:
┌───┐ ┌───┐ ┌───┐
│ A │ │ B │ │ A │
└───┘ └───┘ └───┘
horizontal ---
┌───┐
│ B │
└───┘
vertical옵션: gap, align (상단/중간/하단), separator (세로 모드).
이미지(URL 또는 base64)를 ASCII 아트로 변환합니다. 두 가지 렌더링 모드:
ascii — 문자 램프 ( .:-=+*#%@), 고전적인 느낌
braille — 유니코드 점자 점 (⠿), 문자당 8배 해상도
옵션: size (16/32/64), invert, contrast, gamma, threshold (점자).
unicode, rounded, ascii 테두리 스타일을 지원하는 11가지 다이어그램 유형.
유형 | 필수 필드 | 출력 |
|
|
|
|
| 제목 + 구분선 + 본문 |
|
|
|
|
| 열 정렬 그리드 |
|
| 화살표가 있는 액터 생명선 |
|
| 수직 |
|
| 수평 |
|
| 속성/메서드가 포함된 UML 클래스 |
|
| 개체-관계 다이어그램 |
|
| 수평 마인드 맵 트리 |
|
| 타임라인이 포함된 간트 차트 |
┌─────────┐ ╭──────────╮ ┌──────┬───────┐ 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 ████████████FIGlet 폰트(Standard, Small, Slant, Big, Mini)를 사용하여 텍스트를 대형 ASCII 아트로 렌더링합니다.
각 아트는 식별 가능한 최소 크기로 저장됩니다.
계층 | 크기 | 용도 |
16w | 16 x 8 | 아이콘, 기호, 단순한 모양 |
32w | 32 x 16 | 동물 실루엣, 이모지 |
64w | 64 x 32 | 상세한 장면 (드묾) |
26개 카테고리에 걸쳐 엄선된 100개의 항목. 출처: kao.moji (MIT).
카테고리 | 예시 |
happy |
|
sad |
|
angry |
|
love |
|
confused |
|
animals |
|
table-flip |
|
+ 19개 더 | excited, greeting, celebrate, hug, surprised, sleepy, nervous, wink, magic, laughing, determined, eating, dancing, hopeful, jealous, ... |
MIT. 아트 아이콘 출처: 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.
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.3bannercategoriesconvertdeletegetkaomojilistrandomsearchsubmitScored across 11 tools
Each 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.
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.
Exact text tools for AI agents: unified diff, patch apply, regex testing, grapheme counting.
