Atlas UI
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| WORKSPACE_ROOT | No | The 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
| Capability | Details |
|---|---|
| tools | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| 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; |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
| 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 |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
Latest Blog Posts
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
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