Skip to main content
Glama

Server Configuration

Describes the environment variables required to run the server.

NameRequiredDescriptionDefault
WORKSPACE_ROOTNoThe path to your project root. Can also be passed as CLI argument. Defaults to two directories up from the server.two directories up from the server

Capabilities

Features and capabilities supported by this server

CapabilityDetails
tools
{}

Tools

Functions exposed to the LLM to take actions

NameDescription
list_all_componentsA

List the codebase catalog as compact summaries: { totalCount, lastScanned, byLayer, components } where each entry has name, architecture layer, category, relative path, and description/routePath when present. byLayer counts cover the whole catalog; layer filters the components list. Pass verbose:true for full metadata objects (large). Follow up with get_component_detail for one item's full data.

search_componentsA

Search across the full codebase (components, pages, hooks, services, adapters, stores, DTOs, types) by name, path, description, or keywords. Uses fuzzy matching and multi-token scoring. Returns compact summaries (name, layer, path, _score) ranked by relevance — follow up with get_component_detail / get_component_props for full data.

get_component_propsA

Get TypeScript prop interface for a specific component. Returns prop names, types, required status, default values, and JSDoc descriptions. Supports both interface and type alias prop definitions. Provide either name (catalog lookup) or componentPath (file path). If the result is ambiguous, re-call with file to disambiguate.

find_similar_componentsA

Find components similar to a natural language description using keyword AND structural matching. Scores based on name, hooks, child components, data fetching pattern, and architecture layer. Returns up to 15 results.

get_component_detailA

Get detailed information about a specific component, page, hook, service, adapter, or store by name. Returns full metadata including props, hooks, state, child components, event handlers, data fetching pattern, test ids, form-field selectors, accessibility, API endpoints, and architecture layer. If the name matches multiple items, returns ambiguous with candidates — re-call with file.

find_component_usagesA

Find where a component, hook, or service is used (imported and rendered in templates/JSX) across the entire codebase. Searches components, pages, hooks, services, etc. Returns files, parent items, and line numbers with usage type (template, jsx, or import). Useful for impact analysis.

get_architecture_overviewA

Get a high-level overview of the entire application architecture. Returns counts by layer (components, pages, hooks, services, adapters, contexts), category breakdown, data flow chains (page -> hook -> service), and route map.

get_dependency_chainA

Get the full dependency chain for any component, hook, or service. Returns both upstream (what uses it) and downstream (what it depends on) relationships. Supports recursive traversal with depth parameter (1-3). Useful for understanding impact of changes and tracing data flow.

get_route_mapA

Get the complete route -> page -> component mapping. Returns all routes (React Router or Vue Router) with their page components, protection status, hooks/composables used, child components rendered, dynamic segments, and nested route hierarchy.

get_hook_detailA

Get detailed information about a custom hook or Vue composable. Returns parameters, return type, query keys, adapter/service calls, data fetching pattern, and which components use this hook/composable. If the name matches multiple hooks, returns ambiguous with candidates — re-call with file.

find_dead_codeA

Find dead code — exported components, hooks, services, and adapters that are never imported or used anywhere else in the codebase. Returns unused exports with reasons explaining why they appear unused. Useful for codebase cleanup.

get_data_flowA

Trace the full data path from a component through composables/stores → services → adapters → API endpoints, INCLUDING data fetched by child components. Returns per-chain detail (each tagged with the via render path that reached it) plus allEndpoints — the union of every endpoint the rendered route hits. Store-mediated flows (Pinia/Zustand) are traced too. If the name matches multiple items, returns ambiguous with candidates — re-call with file.

find_dangling_listenersA

Find dead event wiring across the catalog: a parent binds @some-event on a child component that never fires it — either the child DECLARES the event but never emit()s it (dead plumbing), or it neither declares nor emits it (a typo/renamed event). Native DOM events and children with dynamic/undeclared emit APIs are excluded to avoid false positives. This is the cross-component companion to the per-component emitsDead/emitsFired fields (see get_component_detail). Vue only. Pass file to scope to parents under a path substring.

audit_template_patternsA

Repo-wide template-layer design-drift audit for Vue overlays/modals — the one-call replacement for grepping overlay classes, backdrop @click handlers, Teleport, z-index, and header markup. Returns per-component signals (overlays + whether the backdrop click uses .self, Teleport target, z-index values, headings) plus synthesized findings: backdrop-click-missing-self, overlay-not-teleported, modal-no-heading, zindex-exceeds-max (only when templatePatterns.maxZIndex is configured), and more. Raw per-component signals are also on get_component_detail.templatePatterns. Vue only. Pass file to scope by path substring.

whats_affectedA

The edit→verify glue: given changed files (or auto-detected from git status when omitted), walk the dependency graph UPSTREAM to find every component/page affected by the change, map those to routes, and return concrete verification targets — ready-to-run check_page/render_component suggestions. Each changed file gets a risk classification (low/medium/high/critical with a scoring breakdown: layer, blast radius, routes reached, direct dependents) and the result carries an overallRisk; routes and suggested checks are ordered riskiest-first. Call it after editing to know exactly what to re-check in the browser and how carefully.

render_componentA

Render a catalog component in the running app and return a screenshot plus runtime diagnostics (console errors, uncaught exceptions, failed network requests). Resolves the component to its URL automatically via the route map — just name the component you changed. Use this to visually confirm a change actually works. Requires the dev server to be running.

check_pageA

Navigate to any URL (absolute, or a path relative to the dev server) and return a screenshot plus runtime diagnostics: console errors, uncaught exceptions, and failed network calls. The 'did my change break anything' workhorse — call it after editing to confirm the page still renders clean. Requires the dev server to be running.

verify_data_flowA

Render a component's route and check the REAL network traffic against the endpoints that static analysis (get_data_flow, including child components and stores) predicts. Matching is method-aware. The key output is unexpectedApiCalls — observed calls that map to NO predicted endpoint, i.e. real source-vs-runtime drift (dynamic URLs, app-level fetches, or genuine divergence). verdict is 'confirmed' when every observed call is accounted for. Pass actions to drive interactions (fill/click/...) before the network is read — that's how predicted MUTATION endpoints (POST/PUT/DELETE) get exercised and verified. Requires the dev server to be running.

capture_flowA

Drive a multi-step user flow against a SINGLE persistent page and screenshot each step. Each step can navigate (component/route/url) and/or run interactions (click, fill, select, press, check, hover, waitFor) — so you can log in, fill a form, submit, and verify the next screen as one flow. State (cookies, form values, SPA route) carries across steps. Each step reports the API calls it triggered ({method, path, status}) so you can confirm a click actually fired its mutation. Aggregates diagnostics into a single pass/fail; on a failed action it screenshots the broken state and stops. Requires the dev server to be running.

reset_loginA

Recover the browser's authenticated session in-place: re-reads .atlas-ui.json (so a browser.login block added or fixed after server startup takes effect — no restart needed), clears cookies/storage and any stuck login error, then (by default) re-runs the configured login flow immediately. Use this when authed runtime tools (render_component/check_page/capture_flow on protected routes) start failing with a login error, or right after adding/changing browser.login config. No-op with a note if no browser.login is configured even after the re-read. Public routes never need this; pass "public": true on those tools to skip login entirely.

inspect_rendered_pageA

The reverse bridge: open a live page and report which CATALOG components are actually mounted on it, mapped back to their source files. Walks React/Vue dev internals in the running app — use it to go from 'the thing I see on screen' to 'the file I should edit' without grepping. Give a catalog component, a route, or a raw url. Text-only output (use render_component for a screenshot). Requires the dev server (dev build) to be running.

Prompts

Interactive templates invoked by user choice

NameDescription

No prompts

Resources

Contextual data attached and managed by the client

NameDescription

No resources

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/calebsjames/atlas-ui-mcp'

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