Skip to main content
Glama
frizzy

display-image-mcp

by frizzy
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
DISPLAY_MCP_DATANoDirectory for storing rendered images../data
DISPLAY_MCP_FONTNoFont used for rendering text.Pillow's built-in vector font
DISPLAY_MCP_TOKENNoIf set, the MCP endpoint requires Authorization: Bearer <token> (streamable-http only).
DISPLAY_MCP_BASE_URLNoBase URL used in returned image URLs. Set this to the address your displays can reach.http://<http-host>:<http-port>
DISPLAY_MCP_MCP_HOSTNoHost for the MCP endpoint.127.0.0.1
DISPLAY_MCP_MCP_PORTNoPort for the MCP endpoint.8767
DISPLAY_MCP_PROFILESNoPath to a TOML file defining custom display profiles.
DISPLAY_MCP_HTTP_HOSTNoHost for the image HTTP server.0.0.0.0
DISPLAY_MCP_HTTP_PORTNoPort for the image HTTP server.8099
DISPLAY_MCP_TRANSPORTNoMCP transport to use, e.g. stdio or streamable-http.stdio

Instructions

Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.

This server publishes no instructions, or was last inspected before Glama recorded them.

Capabilities

Features and capabilities supported by this server

Protocol revision2025-11-25

CapabilityDetails
tools
{
  "listChanged": false
}
prompts
{
  "listChanged": false
}
resources
{
  "subscribe": false,
  "listChanged": false
}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_profilesA

List display profiles (resolution, colour mode, output format).

render_cardA

Render a simple card (header bar, body lines, footer) and store it as (profile, label).

Text that is too long is truncated with an ellipsis and extra lines beyond what fits are dropped, so keep it short. Returns the image URL, its sha256 and changed (false when the pixels are identical to what was already stored, so a caller can skip a display refresh).

render_imageB

Render a custom layout from drawing elements and store it as (profile, label).

Origin (0,0) is top-left; sizes are in pixels. Colours are names (black, white, red, yellow, gray, dark_gray, light_gray) or #rrggbb; they snap to what the profile can show. Elements: {"type":"text","text":..,"x":..,"y":..,"size":12,"color":"black","bold":false, "anchor":"la","max_width":px,"max_lines":1} (anchor: Pillow anchors, e.g. "la","mm","ra") {"type":"rect","x":..,"y":..,"w":..,"h":..,"fill":colour|null,"outline":colour|null,"width":1} {"type":"line","x1":..,"y1":..,"x2":..,"y2":..,"color":"black","width":1} {"type":"progress","x":..,"y":..,"w":..,"h":..,"value":0.0-1.0} Returns the image URL, sha256 and changed (see render_card).

render_layoutA

Lay out a screen from nested rows and columns (no pixel coordinates) and store it as (profile, label).

root fills the whole display. Containers split space between children; text can fit itself. Always check warnings in the result: it reports truncated text, overflow and elements that got no room, so you can fix the layout and render again (same label overwrites).

Nodes (every node accepts w, h in px and flex as a share of leftover space): {"type":"column"|"row","children":[...],"gap":4,"padding":6,"align":"stretch|start|center|end", "justify":"start|center|end|space-between","fill":colour,"border":px,"border_color":colour} padding is a number, [vertical, horizontal] or [top, right, bottom, left]. align = cross axis (default stretch); justify = main axis when no child has flex. {"type":"text","text":"..","size":12|"fit","bold":false,"color":"black","align":"left|center|right", "valign":"top|middle|bottom","max_lines":1,"min_size":8,"max_size":96,"fit":"shrink"} size "fit" (or fit "shrink") picks the largest size that fits the box: give it flex or w/h. Text longer than its box is cut with an ellipsis (and warned): raise max_lines to wrap. {"type":"rect","fill":colour,"outline":colour} (a bar or rule: {"type":"rect","h":2,"fill":"black"}) {"type":"progress","value":0.0-1.0,"h":8} {"type":"spacer"} (give it flex or w/h) Colours: black, white, red, yellow, gray, dark_gray, light_gray or #rrggbb (snapped to the profile). Limits: 8 levels deep, 120 nodes.

list_imagesA

List stored images (all profiles, or one) with URL, sha256, size and last-changed time.

delete_imageC

Delete the image stored for (profile, label).

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

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

A3.6/5.0

Scored across 6 tools

Disambiguation4/5

The three render tools are distinguishable: render_card is a fixed header/body/footer template, render_image takes pixel-coordinate drawing elements, and render_layout uses nested rows/columns without coordinates. They could be confused at a glance (card output is achievable via the other two), but the descriptions clarify the boundaries well. list_profiles vs list_images is also clearly separated by resource.

Naming Consistency5/5

All six tools follow a strict verb_noun snake_case pattern: list_profiles, list_images, render_card, render_image, render_layout, delete_image. Verb families are internally consistent (render_*, list_*). No mixed conventions.

Tool Count5/5

Six tools is well-scoped for a display image rendering/storage server. Each tool earns its place: profile discovery, three rendering variants, listing, and deletion. No filler or redundancy.

Completeness4/5

The image lifecycle is mostly covered: render (create), list (read), delete. However, there is no single-image get/inspect tool to fetch metadata for one (profile, label) without listing everything, and profiles can only be listed, not defined. These are minor gaps agents can work around via list_images.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources