frontend-stack
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| FRONTEND_STACK_CHANNEL | No | Default browser channel when the call does not pass one. | |
| FRONTEND_STACK_HEADLESS | No | Set to false to watch the browser. | |
| FRONTEND_STACK_USER_DATA_DIR | No | Use a persistent browser profile, so pages behind a login stay signed in. Use a dedicated profile. |
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
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| frontend_stack_pipelineA | Returns the frontend build pipeline (audit, one style, taste floor, build, review, verify, perf) and the style menu as markdown. Call it at the start of any website, landing page, UI, or redesign build. |
| list_stylesA | Returns the style menu as JSON grouped by family. Pick exactly ONE style per build. |
| verify_pageA | Opens a URL in Playwright Chromium at each viewport (default: 390x844 mobile touch and 1440x900 desktop) and returns a screenshot, console errors, failed requests (4xx/5xx), horizontal overflow, axe-core accessibility violations, an ARIA accessibility snapshot, and the detected pointer type (coarse/fine). Look at the screenshots before calling a build done. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| frontend_stack | Run the full frontend pipeline on the current build. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| pipeline | Pipeline and style menu |
TDQS
Scored across 3 tools
verify_page is clearly distinct (browser verification), but frontend_stack_pipeline and list_styles overlap substantially since the pipeline tool also returns the style menu as markdown while list_styles returns the same menu as JSON. The format/purpose difference is explained in the descriptions, so an agent can pick correctly, but the boundary is blurry.
All names use snake_case, which is consistent, and list_styles/verify_page follow a verb_noun pattern. frontend_stack_pipeline breaks the pattern by being a noun phrase with a redundant server-name prefix, a minor deviation.
Three tools is on the thin side for a 'frontend-stack' server, but each one serves a distinct role in the described workflow (guidance, style choice, verification) and none feels gratuitous. Slightly under-scoped rather than bloated.
The surface covers pipeline discovery, style selection, and post-build verification, but there is no tool to actually scaffold, generate, or build a page, and no tool to re-read or diff results after iterating. The workflow has a notable gap between 'pick a style' and 'verify the page'.