Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
VIRADA_KIT_PUBLIC_URLNoPublic URL where the remote MCP server is hosted, for example https://your.host. Used when running the HTTP server behind HTTPS so chat apps can connect to https://your.host/mcp.

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
get_kit_specA

The kit format and how to make a kit: the sheets and their panels, the layer types, the workflow. Read first.

get_templateB

A sheet's template ('jersey' 2048x2048 or 'bib' 2048x1024). style 'guide': the panels and where the game's male (blue) and female (pink) riders' kit edges, seams, zip and pockets fall, for placing layers. style 'clean': white panels with thin outlines, names and which way is up, the zip line, pockets, cuff and gripper bands: the canvas to paint a whole sheet on (route B, e.g. with an image model; paint everything, leave no outlines or words). save_to: also write the full-size PNG to this path (local servers).

add_assetB

Add a picture the kit uses: a logo for an 'image' layer (PNG with transparency is best) or a whole painted sheet for {"sheet": ...}. Give a local file path (local servers) or base64 PNG/JPEG data. Use the id it returns in the kit. Names: letters, digits, _ and -. In a chat app that can't send a picture's bytes, skip this: build with layers.

list_assetsC

The pictures added so far.

validate_kitB

Check a kit object against the format. Returns 'valid' or the problems to fix.

render_sheetsB

The kit's two finished sheets as pictures (jersey, then bib), to check the flat layout.

preview_kitA

The kit on the game's rider, in the game's look; follow it with compare_to_reference and fix what differs. body: 'male' or 'female'. views (any of front, front34_left, left, back, right, front34_right; default front, front34_left, back). front34_left = the front turned to show the rider's left side, like most product photos.

compare_to_referenceA

The user's reference picture beside the kit on the game's rider from a similar angle, to spot what differs (colours, where panels and logos sit, sizes). Pick the view nearest the reference's angle. The rider is cropped to the jersey (jersey_only, default) or to the jersey and bibs, as product pictures are framed. If you can't send the picture's bytes (a chat app), leave the reference out: you get the rider's views alone to set beside the picture you can see. grid (default on) draws the FRONT and BACK panels' coordinates on the rider (a line every 0.1 of u and v, thicker at u = 0.5): read off where and how big each logo, stripe and panel edge is in the reference, and set the same numbers in the kit.

export_kitA

Write the kit file (.kit.zip: kit.json, the two finished sheets, its pictures, previews) and hand it back. Only after the compare loop shows the kit matching the user's pictures (see get_kit_spec's workflow); it refuses a kit that was never compared, or one with invented parts, until user_approved=true (the user has seen and agreed). The result carries the file itself (an embedded resource, application/zip, also readable later as kit://) for you to save or pass on, plus where the server wrote it (path: local servers; default its work folder) and a preview to check.

import_kitC

Open a .kit.zip (made here or elsewhere) to keep working on it: returns its kit object (to edit and pass to the other tools) and adds its pictures as assets; also shows it on the riders.

Prompts

Interactive templates invoked by user choice

NameDescription
make_kitMake a Virada kit from your kit pictures

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A3.5/5.0

Scored across 10 tools

Disambiguation5/5

Each tool targets a distinct step or resource in the kit workflow: spec reading, template fetch, asset add/list, validation, flat-sheet rendering, rider preview, reference comparison, export, and import. The potentially overlapping render_sheets vs preview_kit and preview_kit vs compare_to_reference are clearly separated by their descriptions (flat layout vs on-rider view vs side-by-side reference). No two tools appear to do the same thing.

Naming Consistency5/5

All ten tools follow a consistent verb_noun snake_case pattern (get_kit_spec, get_template, add_asset, list_assets, validate_kit, render_sheets, preview_kit, compare_to_reference, export_kit, import_kit). Verbs are used predictably and no convention mixing is present.

Tool Count5/5

Ten tools is well-scoped for a kit-design workflow, with each tool earning its place as a stage (spec, template, assets, validate, render, preview, compare, export, import). Nothing feels redundant or padded.

Completeness4/5

The workflow lifecycle is essentially complete: read spec, get template, manage assets, validate, render, preview, compare against reference, and round-trip via export/import. The only minor gap is asset lifecycle management (add/list exist but no remove or rename), which agents can work around.

Maintenance

ActivityMaintained
ResponsivenessNo recent community issues