What can you do with this server?

This MCP server generates ASCII art banners from text strings using various pyfiglet fonts. * List available fonts (get_fonts): Retrieve a complete list of all available pyfiglet font names (e.g., 'slant', 'standard', 'block', 'bubble', 'big') to discover options before generating banners. * Generate ASCII art banners (generate_banner): Convert any text string into a multi-line ASCII art banner, with an optional font name (defaults to 'standard').

ASCII Banner MCP Server

by guilyx

Overview Schema Source Related Servers Discussions Admin

Python

ASCII Banner MCP Server

A classical Model Context Protocol (MCP) server that generates ASCII art banners from any string using pyfiglet.

Features

get_fonts — List all available pyfiglet font names (via FigletFont.getFonts()).
generate_banner — Render a string as ASCII art with a chosen font (via figlet_format(text, font=...)).

Related MCP server: whereami-mcp

Requirements

Python ≥ 3.10
mcp, pyfiglet

Installation

From the project root:

pip install -e .

For development (tests):

pip install -e ".[dev]"

Usage

Run the server (stdio)

MCP clients typically run the server as a subprocess and talk over stdio:

python -m ascii_banner_mcp.server

Or after install:

ascii-banner-mcp

Config example

Copy and adjust one of the examples in config/:

stdio (local): config/mcp-config.example.json — command + args for Cursor, Claude Desktop, etc.
streamable-http (e.g. Docker): config/mcp-config-streamable-http.example.json — url: "http://localhost:8000/mcp" when the server runs over HTTP.

Configure your MCP client

Add the server to your MCP client config (e.g. Cursor, Claude Desktop). Example (stdio):

{
  "mcpServers": {
    "ascii-banner": {
      "command": "python",
      "args": ["-m", "ascii_banner_mcp.server"]
    }
  }
}

If you use a virtualenv, use the full path to that Python:

{
  "mcpServers": {
    "ascii-banner": {
      "command": "/path/to/venv/bin/python",
      "args": ["-m", "ascii_banner_mcp.server"]
    }
  }
}

Tools

Tool	Description
`get_fonts`	Returns a list of available font names. Use this to discover fonts for `generate_banner`.
`generate_banner`	Renders `text` as ASCII art. Parameters: `text` (required), `font` (optional, default `"standard"`). Use fonts from `get_fonts()` (e.g. `"slant"`, `"block"`, `"big"`).

Example (equivalent to your snippet):

from pyfiglet import figlet_format
print(figlet_format("Hello", font="slant"))

Via this MCP server: call generate_banner with text="Hello" and font="slant".

MCP Inspector

Use MCP Inspector to test and debug the server.

Option 1 — stdio (local process)

Run the Inspector: npx @modelcontextprotocol/inspector
In the UI, add a server with Stdio transport.
Set Command to python (or full path to your Python/venv).
Set Args to -m, ascii_banner_mcp.server.
Ensure the project is installed (pip install -e .) or set cwd to the project root and use python -m ascii_banner_mcp.server.

Option 2 — streamable-http (Docker or local)

Start the server over HTTP:
- Docker: docker compose -f .docker/docker-compose.yml up --build (see Docker below).
- Local: MCP_TRANSPORT=streamable-http python -m ascii_banner_mcp.server (serves at http://127.0.0.1:8000/mcp).
Run the Inspector: npx @modelcontextprotocol/inspector
Add a server with Streamable HTTP (or URL) and set the URL to http://localhost:8000/mcp.

Custom ports (Inspector): CLIENT_PORT=8080 SERVER_PORT=9000 npx @modelcontextprotocol/inspector

Docker

Run the MCP server in a container. Use the .docker/ setup:

stdio (default) — client runs the container and talks via stdin/stdout:

docker build -f .docker/Dockerfile -t ascii-banner-mcp .
docker run -i --rm ascii-banner-mcp

streamable-http (for Inspector or URL-based clients):

docker compose -f .docker/docker-compose.yml up --build

Server is at http://localhost:8000/mcp. Use config/mcp-config-streamable-http.example.json or point MCP Inspector at that URL.

Development

Tests: pytest
Lint: ruff check src tests
Format: black src tests
Pre-commit: Black, Ruff, and conventional-commit message checks (e.g. feat:, fix:). Install: pip install -e ".[dev]" then pre-commit install and pre-commit install --hook-type commit-msg. Run manually: pre-commit run --all-files.

License

MIT

Available Tools

2 tools

generate_bannerA

Generate an ASCII art banner from the given string.

Args:
    text: The string to render as ASCII art (e.g. "Hello", "MCP").
    font: Name of the pyfiglet font. Use get_fonts() to list available fonts.
          Default is "standard". Common options: "slant", "block", "bubble", "big".

Returns:
    The ASCII art banner as a multi-line string.

ParametersJSON Schema

Name	Required	Description	Default
`text`	Yes
`font`	No		standard

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations provided, the description carries the full burden. It describes the core behavior (generating ASCII art) and mentions the return format, but doesn't cover potential limitations like text length constraints, error conditions, or performance characteristics that would be helpful for an agent.

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

Conciseness5/5

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

The description is well-structured with clear sections (Args, Returns), uses bullet-like formatting for font options, and every sentence adds value. It's appropriately sized for a 2-parameter tool with good information density.

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 tool's moderate complexity, no annotations, and the presence of an output schema (which handles return values), the description is mostly complete. It covers purpose, parameters, and basic usage, though could benefit from more behavioral context about limitations or edge cases.

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 description adds significant value beyond the input schema, which has 0% description coverage. It explains what 'text' represents with examples, describes the 'font' parameter with default value, common options, and how to discover available fonts using get_fonts(). This fully compensates for the schema's lack of descriptions.

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 purpose: 'Generate an ASCII art banner from the given string.' It specifies the verb ('Generate'), resource ('ASCII art banner'), and distinguishes from its sibling get_fonts by focusing on banner creation rather than font listing.

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

Usage Guidelines4/5

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

The description provides clear context for usage by mentioning the sibling tool get_fonts() to list available fonts, which helps guide when to use this tool. However, it doesn't explicitly state when not to use it or mention alternatives beyond the font listing reference.

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

get_fontsA

List all available pyfiglet font names.

Returns a list of font identifiers that can be used with generate_banner.
Use this to discover which fonts (e.g. 'slant', 'standard', 'block') are available.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.7/5.0

Behavior4/5

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

No annotations are provided, so the description carries full burden. It discloses the return type ('Returns a list of font identifiers') and the tool's purpose for discovery, which is adequate behavioral context for a read-only list operation. However, it doesn't mention potential limitations like rate limits or error conditions.

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

Conciseness5/5

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

Three sentences that are front-loaded with the core purpose, followed by usage guidance and examples. Every sentence earns its place with no wasted words, making it highly efficient and well-structured.

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

Completeness5/5

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

Given the tool's simplicity (0 parameters, no annotations, but has an output schema), the description is complete. It explains what the tool does, how to use it, and references the output format, which is sufficient since the output schema will detail the return values.

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

Parameters4/5

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

The tool has 0 parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't discuss parameters, focusing instead on the tool's purpose and output, which adds value beyond the empty 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 the specific verb ('List') and resource ('all available pyfiglet font names'), and distinguishes from its sibling tool generate_banner by explaining the relationship. It provides concrete examples of font identifiers like 'slant', 'standard', 'block'.

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

Usage Guidelines5/5

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

Explicitly states when to use this tool ('Use this to discover which fonts... are available') and provides a clear alternative ('that can be used with generate_banner'), giving complete guidance on tool selection versus its sibling.

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.

2 tool updatesv1.0.0Feb 2, 2026
- First observedgenerate_banner
- First observedget_fonts

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A4.2/5.0

Scored 2026-04-18 06:20 across 2 tools

Disambiguation5/5

The two tools have perfectly distinct purposes: generate_banner creates ASCII art from text, while get_fonts lists available fonts. There is no overlap or ambiguity between them; an agent can easily tell them apart based on their clear, complementary functions.

Naming Consistency5/5

Both tools follow a consistent verb_noun pattern: generate_banner and get_fonts. The naming is predictable and readable, with no deviations or mixed conventions, making it easy for an agent to understand and use them.

Tool Count2/5

With only 2 tools, this server feels thin for its apparent scope of ASCII banner generation. While the tools cover core functionality, the count is too low for a typical server, limiting flexibility and potentially requiring agents to work around missing operations like customization or management features.

Completeness3/5

The server covers basic ASCII banner generation with text input and font selection, but there are notable gaps. For example, it lacks tools for customizing banners (e.g., adjusting width, alignment, or colors) or managing generated banners, which could hinder more advanced agent workflows in this domain.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

Second server!
com.fenetresurciel.verylongmcp
A non functional MCP server (yet)
Developer Tools
2
smithery-ai-cookbook-python-quickstart
ai.smithery
A simple MCP server built with FastMCP and python
Developer Tools
213
asset-auto-generator
io.github.TranThienTrong
An MCP server that provides asset auto generator
Developer Tools App Automation
2
staging-mcpOAuth
dev.riskprofiler
An MCP server that provides a hello tool
Developer Tools
1

Related MCP Servers

mcp-server-commands
Shell Access Command Line OS Automation
g0t4
A
license
B
quality
C
maintenance
An MCP server to run commands.
Updated 6 days ago (2026-09-09 10:53 UTC)
1
337 npm
233
MIT
whereami-mcp
Location Services API Testing
kukapay
A
license
Not graded
quality
D
maintenance
A lightweight mcp server that tells you exactly where you are.
Updated a year ago (2025-03-27 23:15 UTC)
4
MIT
whoami-mcp
OS Automation Shell Access
kukapay
A
license
A
quality
D
maintenance
A lightweight MCP server that tells you exactly who you are.
Updated a year ago (2025-05-10 14:17 UTC)
1
1
MIT
Hello World MCP Server
Developer Tools
MauricioIPastora
F
license
A
quality
D
maintenance
A simple MCP server that provides greeting tools and server information.
Updated 8 months ago (2026-01-29 19:12 UTC)
1
-

ASCII Banner MCP Server

Features

Requirements

Installation

Usage

Run the server (stdio)

Config example

Configure your MCP client

Tools

MCP Inspector

Docker

Development

License

Available Tools

Output Schema

TDQS

Output Schema

TDQS

Tool Schema Changelog

TDQS

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

mcp-server-commands

whereami-mcp

whoami-mcp

Hello World MCP Server