Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
AGY_UI_DRY_RUNNoSet to '1' to make the tools skip every external side effect (spawning agy, launching Playwright, running git, starting a dev server) and return a stub payload.

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
}
experimental
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
ui_implementA

Implement/modify UI for task via an iterative, diff-gated vision loop.

Workflow: 1. Load .agy-ui-scope and create an isolated git worktree. 2. Start the dev server (from scope.serve) inside the worktree and wait for it to be ready. 3. Loop up to max_iters: screenshot the route across viewports, build a vision prompt listing the shot + design-ref paths, run agy -p in the worktree, diff-gate the result, re-screenshot. Stop early once a round produces no new in-scope changes. 4. Collect the final diff, stop the server, clean up the worktree.

Args: project_dir: Absolute path to the project root (must contain the scope). task: Natural-language description of the UI change. design_refs: Optional absolute paths to design reference images. target_route: Optional route appended to scope.serve.url (e.g. "/login"); defaults to the base URL. max_iters: Maximum vision-loop iterations. apply: When True (default), copy the in-scope changed files from the worktree back into project_dir so the user can git diff and review/commit them. When False, the worktree is collected and torn down without writing anything to the project. match_threshold: Only used when design_refs is non-empty. agy is asked to self-report a 0-100 match score against the mockup each round; the loop stops early once that score reaches this threshold.

Returns: A dict with files_changed, diff, escalations, iterations, shots_before, shots_after, warnings, applied (whether apply was requested), applied_files (paths written to the project), match_score (the last self-reported 0-100 score, or None when no design refs were supplied), and match_gaps (the last reported remaining differences, or "").

ui_reviewA

Serve the app, screenshot it, and have agy critique it read-only.

Any file agy edits during the critique is reverted by the diff-gate, so this tool never mutates the project.

When a11y is set (and the platform is a web target), each target is also audited with axe-core; the violations ground agy's critique and are returned structurally under a11y. Native platforms have no DOM, so the audit is skipped there with a note.

Args: project_dir: Absolute path to the project root (must contain the scope). target_route: Optional route appended to scope.serve.url. against_design: Optional absolute paths to design reference images to critique against. a11y: Run axe-core accessibility checks on web targets (default True).

Returns: A dict with critique (agy's text), shots (captured paths), targets (the reviewed target names), a11y (a {target: [violations]} map; empty when disabled/native), and warnings.

ui_initA

Auto-detect the stack and write a starter .agy-ui-scope config.

Zero-to-config helper for non-technical users: inspects the project's manifests (package.json / pubspec.yaml / lockfiles), guesses the framework, serve command, and edit-scope globs, and writes a .agy-ui-scope YAML at the project root that the user can then tweak by hand. After this, the ui_implement / ui_review tools run with no further setup.

Args: project_dir: Path to the project root to scan and write into. overwrite: When False (default) an existing .agy-ui-scope is left untouched and status: "exists" is returned. Pass True to regenerate it (clobbering the existing file).

Returns: A dict describing the outcome: status (ok/exists/error), scope_path (absolute), written (whether the file was written), detected (framework/platform/serve/package-manager), allow and deny globs, design_dir_found, next_steps, and warnings.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

TDQS

A4.7/5.0

Scored across 3 tools

Disambiguation5/5

Each tool targets a distinct phase: ui_init configures the project, ui_implement applies changes, and ui_review critiques without mutating. There is no meaningful overlap in purpose, despite sharing some arguments like project_dir and target_route.

Naming Consistency5/5

All tools follow a consistent ui_<verb> pattern in snake_case. The verbs init, implement, and review are clear and predictable, making tool selection straightforward.

Tool Count5/5

Three tools are well-scoped for the server's setup-implement-review lifecycle. Each tool earns its place, and the count is comfortably within the ideal range for a focused MCP server.

Completeness5/5

The tool surface covers the full intended workflow: initialize a scope, implement UI changes, and review the result against design and accessibility criteria. ui_init's overwrite option and ui_implement's apply flag also provide sensible config-reset and dry-run paths.

Maintenance

ActivityInactive
ResponsivenessNo issues