Skip to main content
Glama

ui_implement

Iteratively refine UI by capturing screenshots, comparing to design references, and applying changes until a visual match threshold is met.

Instructions

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 "").

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
project_dirYes
taskYes
design_refsNo
target_routeNo
max_itersNo
applyNo
match_thresholdNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Behavior5/5

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

The description fully discloses the iterative workflow, including creating a git worktree, starting a dev server, taking screenshots, diff-gating, and cleanup. It explains the effect of the 'apply' parameter on whether files are written back. No annotations are provided, so the description carries the full burden and meets it well.

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

Conciseness4/5

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

The description is detailed but well-structured with a summary, numbered workflow, args list, and returns section. It is front-loaded with the core purpose. While long, the complexity of the tool justifies the length. Could be slightly more concise, but very effective.

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 complexity, 7 parameters, no annotations, and the presence of an output schema, the description covers all necessary aspects: purpose, workflow, parameter meanings, and return value structure. No gaps are evident.

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?

With 0% schema description coverage, the description compensates with a dedicated 'Args:' section that explains each parameter's meaning, defaults, and behavior. For example, 'project_dir' is described as 'Absolute path to the project root (must contain the scope)' and 'match_threshold' is explained in context of design_refs.

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 begins with a clear verb 'Implement/modify UI' and specifies the resource 'UI for task' and method 'iterative, diff-gated vision loop'. It distinguishes from sibling tool 'ui_review' by detailing an implementation workflow rather than review.

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

Usage Guidelines3/5

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

The description implies usage for implementing UI changes via a vision loop, but does not explicitly contrast with sibling tool 'ui_review' or state when each should be used. No exclusion criteria or alternatives are mentioned.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/qdzsh/agy-ui-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server