What can you do with this server?

The Atlas UI server gives Claude deep awareness of a frontend codebase (React/Vue) through static code analysis and live browser-driven runtime tools. Catalog & Search * List all components, pages, hooks, services, adapters, stores, contexts, DTOs, and types (filterable by layer) * Search by name/keywords or natural language description; find similar components * Get full component metadata: props, hooks, state, children, event handlers, data fetching, test IDs, accessibility info, API endpoints Architecture & Navigation * High-level architecture overview: counts, categories, data flow chains, route maps * Full route → page → component mapping (React Router, Vue Router, Next.js, Nuxt) * In-app section mapping: detect tab/sidebar/view multiplexers not visible in the route map Dependency & Data Flow * Trace upstream/downstream dependencies for any item * Find everywhere a component, hook, or service is imported or rendered * Trace complete data path: component → hook/store → service → adapter → API endpoint * Detect dead code (exported items never imported) Impact Analysis * Determine what components/pages are affected by file changes, with risk classification and verification suggestions Vue-Specific Audits * Find dangling event listeners (parent binds events child never emits) * Audit template patterns for overlays/modals (z-index, Teleport, backdrops) Live Browser / Runtime Tools (requires a running dev server) * Render any component or navigate to any URL, capturing screenshots and reporting console errors, exceptions, and failed network requests * Verify data flow at runtime: compare actual network traffic against statically predicted API calls * Drive multi-step user flows (login, form fills, clicks) across a persistent page, with per-step screenshots and API call reports * Reverse-map which catalog components are actually mounted on a live page * Configure browser settings (dev server URL, headless mode, viewport) and automate login pre-steps for protected routes

How do I use Atlas UI?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Atlas UI List all components in my project." That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Atlas UI

by calebsjames

Overview Schema Source Related Servers Score Discussions Admin

TypeScript

Local

Atlas UI

MCP server that gives Claude deep awareness of your frontend codebase — components, hooks, services, routes, data flow, the whole thing. Point it at a React or Vue project and it builds a catalog that Claude can query while it works.

TLDR: Quick Start

Configure VS Code (via your MCP extension settings, e.g. .vscode/mcp.json):

{
  "mcpServers": {
    "atlas-ui": {
      "command": "node",
      "args": ["/absolute/path/to/atlas-ui/dist/server.js"],
      "env": {
        "WORKSPACE_ROOT": "/absolute/path/to/your/target/project"
      }
    }
  }
}

Restart VS Code and try these prompts:
- "List all the components in my project." (list_all_components)
- "What are the props for the Button component?" (get_component_props)
- "Show me the data flow for the UserProfile component." (get_data_flow)
- "Are there any dead components we can delete?" (find_dead_code)

Related MCP server: Component Library MCP

What it does

Instead of Claude grep-ing around your codebase every time it needs to understand how things fit together, this server scans your project up front and exposes a set of tools for navigating the architecture. It understands:

Components, pages, hooks, services, adapters, contexts, stores — categorized by architecture layer (stores cover Pinia, Zustand, and Redux Toolkit)
Props and interfaces — parsed from TypeScript definitions
Dependency chains — what uses what, upstream and downstream
Route maps — React Router and Vue Router, plus file-based routing (Next.js App/Pages Router, Nuxt), including protected routes and nested layouts
Data flow — traces the full path from component → hook/store → service → adapter → API endpoint
Dead code — finds exported items that nothing imports (entry points like App.tsx/main.tsx count as usage, so root-mounted components aren't false-flagged)
Drivable selectors — each component's data-testid values and form fields with ready-to-use selectors, so flows can be scripted without reading source

It auto-detects whether your project is React, Vue and sets up sensible scan targets accordingly. File watching keeps the cache fresh as you work.

Catalog-wide listings and search results return compact summaries to keep token cost down; get_component_detail has the full metadata, and list_all_components accepts verbose: true when you really want everything. When a name matches multiple files, name-based tools return an ambiguous result with candidates instead of guessing — re-call with file (a path substring) to pick one.

Setup

From npm (no clone needed):

npx atlas-ui-mcp /path/to/your/app

or in an MCP config, "command": "npx", "args": ["-y", "atlas-ui-mcp", "/path/to/your/app"].

From source:

npm install
npm run build

Claude Code

Add to your project's .mcp.json (or ~/.claude/mcp.json for global):

{
  "mcpServers": {
    "atlas-ui": {
      "command": "node",
      "args": ["/path/to/atlas-ui/dist/server.js"],
      "env": {
        "WORKSPACE_ROOT": "/path/to/your/project"
      }
    }
  }
}

Claude Desktop

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "atlas-ui": {
      "command": "node",
      "args": ["/path/to/atlas-ui/dist/server.js"],
      "env": {
        "WORKSPACE_ROOT": "/path/to/your/project"
      }
    }
  }
}

WORKSPACE_ROOT tells the server where your project lives. You can also pass it as a CLI arg (node dist/server.js /path/to/project). If neither is set, it defaults to two directories up from the server because that's where mine lives. Feel free to update if you have a common folder for MCPs.

Configuration

Drop a .atlas-ui.json in your project root to customize scanning. If you don't create one, the server auto-detects your framework and uses defaults based on what it finds.

{
  "scanTargets": [
    { "dir": "src/components", "extensions": [".tsx"], "type": "component" },
    { "dir": "src/pages", "extensions": [".tsx"], "type": "page" },
    { "dir": "src/hooks", "extensions": [".ts", ".tsx"], "type": "hook" },
    { "dir": "src/services", "extensions": [".ts"], "type": "service" },
    { "dir": "src/adapters", "extensions": [".ts"], "type": "adapter" },
    { "dir": "src/contexts", "extensions": [".tsx"], "type": "context" }
  ],
  "routeFiles": ["src/App.tsx"],
  "aliases": {
    "@/": "src/"
  },
  "exclude": ["node_modules", "dist", "build", "__tests__", "*.test.*", "*.spec.*"]
}

Field	What it does
`scanTargets`	Directories to scan, what extensions to look for, and what architecture layer they belong to. Valid types: `component`, `page`, `hook`, `service`, `adapter`, `context`, `store`, `dto`, `type`
`routeFiles`	Entry points for route parsing (React Router or Vue Router). Next.js / Nuxt file-based routes are discovered automatically alongside these
`aliases`	Path aliases so the server can resolve imports like `@/components/Button`
`exclude`	Glob patterns to skip
`phiCompliance`	`{ "enabled": true }` turns on PHI/HIPAA heuristics (query cache settings, console.log near patient data, web-storage use). Off by default — non-healthcare projects get zero PHI noise

Defaults by framework

React — scans src/components (.tsx), src/pages (.tsx), src/hooks (.ts/.tsx), src/services (.ts), src/adapters (.ts), src/contexts (.tsx), src/stores + src/store (.ts). Routes from src/App.tsx, plus Next.js app//pages/ file routes when next is a dependency.

Next.js (when next is a dependency) — the React defaults widen to the layouts Next sanctions: shared code colocated inside the App Router dir (app/- and src/app/-nested components, hooks, contexts, providers, services, lib, stores), the src-level src/lib + src/providers, and root-level dirs next to app/ or pages/ (components, hooks, lib, pages, ...). Directories that don't exist are skipped, so this costs nothing on plain src/* layouts.

Vue — scans src/components (.vue), src/views + src/pages (.vue), src/composables (.ts), src/services (.ts), src/adapters (.ts), src/stores + src/store (.ts). Routes from src/router/index.ts, plus Nuxt pages/ file routes when nuxt is a dependency.

Nuxt (when nuxt is a dependency) — the Vue defaults widen to Nuxt's root-level dirs (components, layouts, pages, composables, stores, utils) and their Nuxt 4 app/-nested equivalents.

Scan coverage warning

Layout conventions are unbounded, so no default list can cover them all — but a scan that misses the app should say so instead of returning a near-empty catalog that reads as "this app has no components". After every scan, the server checks for UI source files (.tsx/.jsx/.vue) that no scan target covers. When the misses outweigh the catalog (or the catalog is empty), list_all_components and get_architecture_overview include a coverageWarning naming the heaviest uncovered directories, so the fix is a copy-paste scanTargets entry in .atlas-ui.json. Files owned by file-based routing (Next App Router special files, pages/ routes) don't count as missed.

Tools

`list_all_components`

Compact catalog listing: { totalCount, lastScanned, byLayer, components } where each entry is a summary (name, layer, category, path, description, route). Filter with layer; pass verbose: true for full metadata objects.

`search_components`

Fuzzy search across the whole codebase by name, path, or keywords. Multi-token scoring, ranked by relevance. Returns compact summaries with _score; limit caps results (default 20).

`get_component_props`

Returns the TypeScript prop interface for a component — prop names, types, required/optional, defaults, and JSDoc descriptions. Accepts a catalog name or a componentPath; failures come back as { error } with the reason.

`find_similar_components`

Describe what you're looking for in plain English and it finds matching components using keyword + structural matching (hooks used, child components, data fetching patterns, layer). Returns compact summaries.

`compare_implementations`

The reuse guardrail. find_similar_components / search_components score on structural metadata, so they rank near-duplicates to the top — exactly the ones whose subtle behavioral differences matter most — with no signal that the bodies diverge. Before unifying two look-alikes, this tool compares them at sub-file granularity and tells you whether that's safe.

Give it two symbol references { file, symbol, enclosingSymbol? }. Each resolves a function, arrow, class/static method, object getter/method, or a computed() / useMemo() / useCallback() (compared by its callback body). It normalizes away comments, formatting, quote style, numeric form, and semicolon/trailing-comma noise, then diffs the token streams and returns:

verdict — equivalent (byte-equal after normalization → safe to unify) or diverges
divergences[] — each classified (literal, callee-changed, guard-changed, operator-changed, added-block, removed-block, changed) with the original source snippet on each side and file line spans (locA / locB)

Works for both Vue and React off the same engine — a .vue <script> is extracted to TS and its lines mapped back, so a Vue composable/computed and a React hook/memo compare on equal footing (you can even compare one against the other). b.file may be omitted to compare two symbols in the same file. Identifiers and type annotations are preserved (no alpha-renaming); Options-API this.x vs composable x.value access styles are not normalized in v1.

`get_component_detail`

Full metadata dump for any item — props, hooks, state, children, event handlers, data fetching, testIds and formFields (drivable selectors for capture_flow), accessibility info, API endpoints, architecture layer.

`find_component_usages`

Find everywhere a component/hook/service is imported or rendered. Returns files, parent components, and line numbers. Also scans entry points (App.tsx, main.tsx, layouts) and route files that live outside scan targets. Good for impact analysis before making changes.

`whats_affected`

The edit→verify glue. Give it changed files (or let it read git status) and it walks the dependency graph upstream to every affected component and page, maps those to routes, and returns concrete check_page / render_component suggestions. Edit → whats_affected → check exactly what matters.

`get_architecture_overview`

High-level view of the whole app — counts by layer, category breakdown, data flow chains, and the route map.

`get_dependency_chain`

Traces upstream (what uses it) and downstream (what it depends on) for any item. Supports recursive depth 1-3.

`get_route_map`

Full route → page → component mapping with protection status, hooks used, child components, dynamic segments, and nested routes. Covers React Router, Vue Router, and file-based routing (Next.js App/Pages Router, Nuxt).

`get_section_map`

The companion to get_route_map for SPAs that multiplex one route into several in-app sections — a role shell / tabbed page / sidebar switch where the lists are section switches, not routes (so get_route_map can't point at them). For each routed page (and each page/root shell) it detects a view multiplexer: a single state variable gating sibling sub-views. Works for both frameworks off their own constructs — Vue v-if="view === 'x'" + @click="view = 'x'", React {tab === 'x' && <X/>} + onClick={() => setTab('x')} — never off app-specific names.

Returns { containers, note? }. Each container carries its route (when routed), its selector (the state variable), and sections[]. Each section has:

id — the literal the selector takes for this section (e.g. "prescriptions")
child — the component rendered for it
reachedBy — query (the view syncs to a URL param), click (a control switches it), or unknown (statically unprovable — e.g. a store/reducer or non-literal condition; drive the UI to explore)
queryParam — { key, value } when URL-reachable
activator — { selector, label }, the drivable control that switches to the section (a [data-testid] or text= selector), when statically identifiable

note (present only on an empty result) explains why nothing was found. A fully route-based app returns no containers — this tool adds signal exactly where the route map goes quiet.

Driving to a section. The runtime tools consume this map so you don't have to wire the click yourself. render_component, verify_data_flow, inspect_rendered_page, and each capture_flow step take a section argument (or you can just name the section's child component) — the tool navigates to the container's route and then reveals the section automatically: it appends the query param for a query section, or clicks the activator for a click section, before it screenshots and reads the network. So a section's own render, console, and API calls (with Phase-1 row counts) are what get captured — no guessed sidebar clicks.

`get_hook_detail`

Deep dive on a hook/composable — parameters, return type, query keys, adapter calls, data fetching pattern, and which components use it.

`find_dead_code`

Finds exported items that are never imported anywhere. Optionally filter by layer. Components referenced only from entry points or route files are correctly treated as live.

`get_data_flow`

Traces the full data path: component → composable/hook/store → service → adapter → API endpoint — including endpoints fetched by child components (a page rarely fetches everything itself). Store-mediated flows (Pinia/Zustand) surface in a stores step per chain. Walks the child render tree (bounded by depth, default 3, plus a cycle-guard). Each chain is tagged with the via render path that reached it, and allEndpoints gives the union of everything the rendered route hits. Saves you from manually chaining get_component_detail + get_hook_detail calls.

Name collisions: get_component_detail, get_component_props, get_hook_detail, get_dependency_chain, and get_data_flow return { ambiguous: true, candidates: [...] } when a name matches multiple files. Instead of silently picking one, automatically re-calls with file (a path substring) to disambiguate.

Runtime browser tools — let agents check their work

The tools above understand your code statically. These five drive a real (headless) browser against your running app, so an agent can see the result of a change instead of guessing. They reuse the static catalog — the route map resolves a component to its URL automatically, so you name the component you changed and the browser knows where to go.

Powered by Playwright/Chromium. They require your dev server to be running and degrade gracefully — the static tools work even if the browser binaries aren't installed.

`render_component`

Render a catalog component in the live app and return a screenshot plus runtime diagnostics (console errors, uncaught exceptions, failed network requests). Resolves component → URL via the route map; or pass a raw route. Pass params for dynamic segments (e.g. {"id": "123"}). The screenshot comes back as an image the agent can look at. For a component that lives inside a one-route shell, pass section (see get_section_map) — or just name the section's child component — and it auto-reveals that section (query-append or activator click) before the shot, reporting how under viewSection.

`check_page`

The "did my change break anything" workhorse. Navigate to any url (absolute, or a path relative to the dev server) and get back a screenshot + console errors + uncaught exceptions + failed network calls. Call it after an edit to confirm the page still renders clean.

`verify_data_flow`

Source-vs-runtime check. Renders a component's route, watches the real network traffic, and checks it against the endpoints get_data_flow predicts (child tree and stores included). Matching is method-aware — a predicted GET /users no longer "confirms" an observed DELETE /users. The key output is unexpectedApiCalls — observed calls that map to no predicted endpoint. That's the real drift signal: dynamic/template-literal URLs, app-level bootstrap fetches outside the component's tree, or genuine divergence. verdict is confirmed when every observed call is accounted for. (Predicted-but-unobserved endpoints are expected — a render exercises only a slice of what the subtree could call — so those are reported as a count, not a list.) Each observed call (matched or unexpected) also carries the response-body summary — bytes, rowCount, rowsFrom, totalCount — so drift and payload-shape can be read from one result.

Pass actions (same shape as capture_flow actions) to drive the page after load and before the network is read — fill the form, click Save, and the resulting POST gets verified too. Without actions, only render-time calls (typically GETs) are observable.

`inspect_rendered_page`

The reverse bridge. Opens a live page and reports which catalog components are actually mounted on it, mapped back to source files — "what do I edit to change the thing I'm looking at?" without grepping. Works by walking React/Vue dev internals, so it needs the dev build (not prod). Takes a catalog component, a route, or a raw url; returns { framework, mounted: [{name, count, relativePath, architectureLayer}], unmatched }, text-only.

`capture_flow`

Drive a multi-step user flow against a single persistent page and screenshot each step. A step can navigate (component/route/url) and/or run interactions — so an agent can log in, fill a form, submit, and verify the next screen as one flow. Page state (cookies, form values, SPA route) carries across steps. Each step reports the API calls it triggered ({method, path, status, bytes, rowCount, rowsFrom, totalCount}), so "did clicking Save actually POST?" and "how many rows did that list return?" are answered in the same call. Aggregates diagnostics into a single pass/fail; on a failed action it screenshots the broken state and stops.

Response-body summary: for JSON API responses, each call also carries a payload summary alongside {method, path, status} — bytes (response size), rowCount (rows in the primary collection), rowsFrom (which JSON key was counted: $ for a top-level array, or a key path like data / data.items), and totalCount (a server-reported pagination total, when the body has one). Count-level assertions — "the projects call returned 1578 scoped rows" — no longer need a drop to curl. The row heuristic is framework- and app-agnostic: it counts a top-level array, a well-known envelope key (data/results/items/records/content/edges/…), or an object's sole array property, and always reports rowsFrom so a wrong guess is visible rather than silent. Bodies are read only for xhr/fetch or /api/ responses, and only their shape — never their contents — is reported.

Tip: get_component_detail exposes each component's testIds and formFields (with ready-made selectors) — build your steps from those instead of reading source.

Each step's actions run in order. Supported action types: click, fill, select, check, uncheck, hover, press, waitFor. Selectors accept CSS or Playwright engines (#email, text=Submit, role=button[name="Save"]). fill/select use text; press uses key.

Visible matches are preferred automatically. Responsive layouts often render the same control twice (a desktop and a hidden mobile variant); actions and waitFor target the first visible match of the selector, so hidden duplicates never pin a click or wait until timeout, and no :visible suffix is needed. If every match stays hidden, the timeout error says so (N match(es) but none visible) instead of surfacing a generic retry log. This applies to all action runners: capture_flow steps, verify_data_flow actions, and the browser.login pre-step.

{
  "steps": [
    { "label": "open login", "route": "/login" },
    { "label": "sign in", "actions": [
      { "type": "fill", "selector": "#email", "text": "demo@acme.dev" },
      { "type": "fill", "selector": "#password", "text": "••••••" },
      { "type": "click", "selector": "text=Log in" },
      { "type": "waitFor", "selector": "#dashboard" }
    ]},
    { "label": "verify dashboard", "component": "Dashboard" }
  ]
}

Filled values are reported by length, not content, so passwords/tokens don't leak into the transcript.

Browser configuration

Add a browser block to .atlas-ui.json (all fields optional — these are the defaults):

{
  "browser": {
    "devServerUrl": "http://localhost:5173",
    "headless": true,
    "viewport": { "width": 1280, "height": 800 },
    "outputDir": ".atlas-ui/captures",
    "routeParams": { "id": "1" }
  }
}

Field	What it does
`devServerUrl`	Base URL of your running app. The MCP assumes the dev server is already up.
`headless`	Run Chromium headless (default `true`). Set `false` to watch it drive.
`viewport`	Screenshot dimensions.
`outputDir`	Where screenshots/videos are written (relative to your project, git-ignored).
`routeParams`	Default values for dynamic route segments; per-call `params` override them.

First-time setup downloads the browser binary:

npx playwright install chromium

If your app is behind a login, add a login block. The session authenticates once on first browser use, and because every tool shares a single page, that session persists across all calls — so protected routes render logged-in. Put credentials in env vars and reference them with ${VAR}; never inline secrets (the config is committed).

{
  "browser": {
    "devServerUrl": "http://localhost:5173",
    "login": {
      "url": "/login",
      "actions": [
        { "type": "fill", "selector": "#email", "text": "${APP_EMAIL}" },
        { "type": "fill", "selector": "#password", "text": "${APP_PASSWORD}" },
        { "type": "click", "selector": "button[type=submit]" }
      ],
      "successSelector": "text=Logout"
    }
  }
}

Field	What it does
`url`	Where the login form lives (absolute or dev-server-relative).
`actions`	The same action types as `capture_flow` (`fill`, `click`, …). `text` supports `${ENV_VAR}`.
`successSelector`	Wait for this to confirm login succeeded (e.g. a "Logout" link).
`successUrlIncludes`	Or confirm the URL changed to include this substring.

The env vars must be visible to the MCP server process (set them in the env block of your mcp.json server entry). On login failure the session tears down and the next call retries, rather than silently running unauthenticated. Filled values are reported by length, so credentials never appear in tool output.

SPA note: all browser tools share one page so in-app/session-storage auth survives navigation. If your app stores its token in sessionStorage (common), a per-page approach would lose it — sharing the page is what makes the login pre-step stick.

License

MIT — free for any use, modification, and redistribution. Contributions welcome.

Available Tools

21 tools

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.

ParametersJSON Schema

Name	Required	Description	Default
`file`	No	Optional path substring — only audit components whose path matches.

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden. It details the audit's scope (repo-wide), outputs (signals and findings), and references a related tool. It doesn't explicitly state read-only behavior, but the nature of an audit suggests no side effects.

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 informative but slightly lengthy. It front-loads the core purpose, then lists outputs and notes. While efficient, it could be trimmed slightly without losing meaning.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a repo-wide audit tool, the description covers return values (both per-component and synthesized findings) and mentions configuration dependency for z-index max. Without an output schema, this level of detail is adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has one parameter 'file' with description. The description adds value by explaining its optional usage: 'Pass `file` to scope by path substring.' This context, combined with high schema coverage, justifies a score above baseline.

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 clearly states the tool's purpose: 'Repo-wide template-layer design-drift audit for Vue overlays/modals.' It specifies what it returns (per-component signals and synthesized findings) and distinguishes itself as a replacement for manual grepping of specific patterns.

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

Usage Guidelines4/5

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

The description implies usage for Vue overlay/modal audits and mentions the optional file scoping. It does not explicitly state when not to use it or provide alternatives, but it clearly indicates Vue-only applicability and scope limitation.

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

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.

ParametersJSON Schema

Name	Required	Description
`steps`	Yes	Ordered list of steps. A step must have a navigation target and/or actions.
`public`	No	Skip the configured login pre-step for the whole flow — use for flows that stay on public routes so a broken/missing credential can't block them (default false).
`settleMs`	No	Default extra ms to wait after each step before screenshotting (per-step settleMs overrides).

TDQS

A4.7/5.0

Behavior5/5

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

Without annotations, the description fully discloses key behaviors: state persistence across steps, API call reporting per step, pass/fail aggregation with screenshot on failure, and dev server requirement. This provides complete behavioral transparency for an AI agent.

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

Conciseness5/5

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

The description is a single focused paragraph with a strong front-loaded topic sentence. Every subsequent sentence adds essential detail (state, API calls, diagnostics, prerequisite) without redundancy or filler.

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 (3 params, many action types, no output schema), the description covers flow building, navigation, interactions, error handling, and output expectations. It leaves no critical gaps for an AI agent to use the tool effectively.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining interactive behavior (e.g., visible matches preferred, within scoping logic, per-step navigation vs actions). It enriches parameter understanding without repeating schema.

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 uses specific verbs ('Drive', 'screenshot') and clearly identifies the resource ('multi-step user flow against a SINGLE persistent page'). It distinguishes from siblings by highlighting the multi-step, stateful nature, which is unique among sibling tools like check_page or inspect_rendered_page.

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

Usage Guidelines4/5

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

The description explains when to use this tool (for multi-step flows with navigation and interactions) and implicitly contrasts with simpler siblings. It notes a prerequisite ('Requires the dev server to be running') but lacks explicit when-not-to-use guidance or alternatives.

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

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.

ParametersJSON Schema

Name	Required	Description
`url`	Yes	URL or path to check (e.g., "http://localhost:5173/login" or "/login").
`public`	No	Skip the configured login pre-step for this call — use for public routes (e.g. "/landing") so a broken/missing credential can't block them (default false).
`fullPage`	No	Capture the full scrollable page instead of just the viewport (default false).
`settleMs`	No	Extra milliseconds to wait after load before screenshotting (e.g. for animations).
`waitUntil`	No	Navigation wait strategy (default networkidle).

TDQS

A4.2/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses navigation, screenshot, diagnostics output, and dependency on dev server. Does not mention side effects, but as a read-only diagnostic tool, this is adequate.

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

Conciseness5/5

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

Two sentences, front-loaded with key action and output. Every sentence adds value without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description lists return values (screenshot, diagnostics) and requirements. It could mention error handling or response format, but is sufficiently complete for a diagnostic tool with detailed parameter schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds no parameter-specific detail beyond the schema; the schema already explains each parameter thoroughly.

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 clearly states the tool navigates to a URL and returns a screenshot with runtime diagnostics. It uses specific verbs and distinguishes itself from sibling tools as a page-breakage checker.

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

Usage Guidelines4/5

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

Provides clear when-to-use guidance: 'call it after editing to confirm the page still renders clean.' Requires dev server running. Lacks explicit alternatives or when-not-to-use, but context is sufficient.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Name to search for (e.g., "Button", "useHandoffState", "patientService")

TDQS

A4.3/5.0

Behavior3/5

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

With no annotations, description carries full burden. It covers what is searched (components, pages, hooks, services) and what is returned (files, parent items, line numbers, usage type). However, it doesn't disclose limitations, performance implications, or behavior for non-existent names.

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

Conciseness5/5

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

Two sentences, all information is relevant: purpose, scope, return data, use case. No redundant words or filler.

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?

Despite no output schema, the description sufficiently explains the return format. Tool is simple with one parameter, and the description covers purpose, scope, return data, and use case, making it complete for decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with a good schema description. The tool description provides concrete examples of valid names (e.g., 'Button', 'useHandoffState', 'patientService'), adding helpful context beyond the schema.

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?

Description states exactly what the tool does: find where a component/hook/service is used across the codebase, including imports and renders. It specifies the returned data (files, parent items, line numbers with usage type). Clearly distinguishes from siblings like search_components and get_component_detail.

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

Usage Guidelines4/5

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

Explicitly says 'Useful for impact analysis', providing a clear use case. Does not explicitly mention when not to use or name alternatives, but the context of siblings and the description's specificity imply appropriate usage.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`file`	No	Optional path substring — only check parent components whose path matches.

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations provided, the description carries the full burden and discloses the tool's behavior well: it checks parent-child event wiring, excludes certain cases, and is Vue-only. It implies a read-only analysis but does not state if any side effects occur. Overall, it is transparent about its functional scope.

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 moderately long but well-structured, with each sentence providing important information. It front-loads the purpose and uses clear language. While slightly verbose in places, it avoids unnecessary details and maintains focus.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains what the tool does and its constraints, but it does not describe the output format or return value. Given the tool's complexity (cross-component analysis) and the absence of an output schema, this is a notable gap. The description would benefit from stating what the tool returns (e.g., list of matches, parent-child pairs).

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'file' is described in both the schema and the description. The description adds context: 'Optional path substring — only check parent components whose path matches.' This extends the schema's generic 'Optional path substring' by specifying how it scopes the analysis, adding value beyond the schema.

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 clearly states the tool finds dead event wiring across the catalog, specifying that it detects parent-child event binding issues where the child never fires the event. It distinguishes between dead plumbing (declares but doesn't emit) and typo/renamed events (neither declares nor emits). This is specific and differentiates from related tools like get_component_detail.

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

Usage Guidelines4/5

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

The description explains when to use the tool (to find dangling event listeners) and what it excludes (native DOM events, dynamic/undeclared emit APIs) to avoid false positives. It also references get_component_detail as a companion tool. However, it does not explicitly mention when not to use it or compare to other sibling tools like find_dead_code.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`layer`	No	Optional: limit dead code search to a specific architecture layer

TDQS

A3.6/5.0

Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions the tool returns 'reasons explaining why they appear unused', but does not disclose any behavioral traits such as performance impact, limitations (e.g., only scans static imports), or edge cases. This lack of detail reduces transparency.

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

Conciseness5/5

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

The description is two sentences long. The first sentence defines the tool's action and scope, the second explains output and use case. Every word serves a purpose, with no redundancy or filler. It is front-loaded and efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one optional parameter and no output schema, the description adequately covers what the tool does, what it returns (unused exports with reasons), and a typical use case (cleanup). It lacks detail on the exact output format, but the provided context is sufficient for most agents to decide invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% as the single parameter 'layer' has a clear description in the input schema ('Optional: limit dead code search to a specific architecture layer'). The tool description adds no additional meaning beyond the schema, earning the baseline score of 3.

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 uses a specific verb 'find' and resource 'dead code', with clear scope ('exported components, hooks, services, and adapters'). It distinguishes from siblings like 'find_component_usages' by focusing on unused exports rather than usages of a specific component.

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 states 'Useful for codebase cleanup' but does not explicitly mention when to use this tool versus alternatives (e.g., 'find_component_usages'), nor does it specify when not to use it. The usage context is implied but not formalized.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`description`	Yes	Natural language description (e.g., "button for submitting forms", "hook that fetches patient data")

TDQS

A3.5/5.0

Behavior3/5

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

While no annotations are provided, the description discloses the dual matching approach and scoring factors. It does not mention read-only behavior or side effects, which is acceptable for a search tool but could be more explicit.

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

Conciseness5/5

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

Two concise sentences front-load the purpose and key details. No redundant information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers the matching method, scoring criteria, and result limit, but lacks details on result format, ordering, and any access requirements. Given the number of sibling tools, more completeness would help.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'description' is well-documented in the schema with examples. The tool description adds context about scoring but does not enhance the parameter meaning beyond the schema.

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 clearly states the verb 'find', the resource 'components', and the method using keyword and structural matching. It specifies scoring criteria and result limit, distinguishing it from siblings like 'search_components'.

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

Usage Guidelines2/5

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

No explicit guidance on when to use this tool versus alternatives like 'search_components' or 'find_component_usages'. The description does not mention prerequisites or exclusions.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior2/5

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

No annotations are provided, so the description bears full responsibility. It discloses what data is returned but fails to mention whether the operation is read-only, any side effects, or performance implications. For a tool with no annotations, this is minimal transparency.

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

Conciseness5/5

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

The description is a single, well-structured sentence that front-loads the purpose and lists key outputs. Every word adds value, and there is no redundancy.

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 there are no parameters and no output schema, the description adequately explains what the tool returns. It is complete for a simple overview retrieval tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are no parameters (empty schema, 100% coverage), so the baseline is 4. The description adds no parameter info, but none is needed as there are no inputs.

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 clearly states it returns a high-level overview of the application architecture, listing specific elements like counts by layer, category breakdown, data flow chains, and route map. It distinguishes itself from sibling tools that focus on detailed components, hooks, or data flows.

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 use for broad architectural understanding through phrases like 'high-level overview,' but does not explicitly state when to use this tool versus siblings, nor provides when-not or alternative recommendations.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`file`	No	Optional file path to disambiguate if multiple items have the same name
`name`	Yes	Item name (e.g., "Button", "PatientDetail", "useHandoffState", "patientAdapter")

TDQS

A4.2/5.0

Behavior4/5

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

Without annotations, the description carries full burden. It discloses successful behavior (returns full metadata) and edge case handling (ambiguous returns candidates). It does not explicitly state read-only nature, error handling for missing items, or performance considerations, but covers key behavioral aspects adequately.

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

Conciseness5/5

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

The description is concise (two sentences), front-loads the primary purpose, and efficiently covers the edge case. Every sentence adds value with no redundancy or fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Despite no output schema, the description specifies the types of metadata returned (props, hooks, etc.) and the ambiguous case. It is missing explicit error handling (e.g., 'component not found') but overall provides sufficient context for the tool's operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with descriptions for both parameters. The description adds value by explaining the disambiguation use case for the 'file' parameter and specifying example values for 'name'. It clarifies the 'ambiguous' return, which is not in schema.

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 specifies a clear action ('get detailed information') and resource ('specific component, page, hook, service, adapter, or store by name'). It lists the extensive metadata returned, distinguishing it from sibling tools like get_component_props or get_hook_detail which are more focused.

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 explains behavior when multiple matches occur and instructs to re-call with 'file' parameter. However, it does not explicitly advise when to use this tool over specialized siblings (e.g., 'for props only, use get_component_props'). The usage context is implied but not fully clarified.

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

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.

ParametersJSON Schema

Name	Required	Description
`file`	No	Optional path substring to disambiguate when `name` matches multiple files
`name`	No	Catalog component name (e.g., "Button"). Alternative to componentPath.
`componentPath`	No	Relative path to component file from workspace root (e.g., "src/components/ui/button.tsx")

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description carries full burden. It discloses the type of information returned and ambiguity handling, but lacks details on error cases, side effects (none expected), or what happens if no parameters are provided (since required is empty).

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

Conciseness5/5

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

Two sentences in the first paragraph, then a short second paragraph. Front-loaded with purpose, no wasted words. Very concise and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no output schema, the description explains return values (prop names, types, etc.) and ambiguity handling. It covers the main use cases, but could be more explicit about error handling when component is not found. Still, it is largely complete for its purpose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, baseline 3. The description adds value by explaining the usage pattern (provide either 'name' or 'componentPath', disambiguate with 'file'), and clarifies the relationship between parameters, going beyond the individual parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool gets TypeScript prop interface for a component, specifying return fields and supporting both interface and type alias. However, it does not explicitly differentiate from sibling tools like 'get_component_detail' or 'find_component_usages', which could also involve props.

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

Usage Guidelines4/5

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

The description provides clear guidance on how to use the tool: provide either 'name' or 'componentPath', and if ambiguous, re-call with 'file'. It implies when to use it (getting prop interface) but does not mention when not to use it or alternatives.

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

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.

ParametersJSON Schema

Name	Required	Description
`file`	No	Optional path substring to disambiguate when the name matches multiple files
`name`	Yes	Component or composable name (e.g., "ProjectModal", "useProjectModal")
`depth`	No	How deep into the child component tree to trace (default 3). 0 = the target's own calls only.

TDQS

A4.1/5.0

Behavior4/5

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

Without annotations, the description carries the full burden of disclosure. It transparently describes the tool's behavior: it traces data flows, returns per-chain details and allEndpoints, and handles ambiguity. It implies a read-only, idempotent operation. No destructive or side effects are mentioned, which is appropriate for a trace tool.

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 a single paragraph of three sentences, efficiently covering purpose, behavior, and ambiguity handling. It front-loads the main action. While it could benefit from slight restructuring (e.g., bullet points), it is concise and contains no unnecessary words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity of a data flow tracing tool and the absence of an output schema, the description provides sufficient context: it explains what is traced, what is returned (per-chain details with render path, allEndpoints), and how the 'depth' parameter works. It does not detail exact output structure but gives a solid high-level understanding.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description does not add any new information about parameters beyond what is already in the schema. The schema descriptions for 'name', 'file', and 'depth' are repeated verbatim in the description, providing no extra semantic value.

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 clearly states the verb 'Trace' and the resource 'full data path from a component... to API endpoints'. It specifies what is included (child components, store-mediated flows) and how ambiguity is handled (returns ambiguous with candidates). This effectively distinguishes it from siblings like 'verify_data_flow'.

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

Usage Guidelines4/5

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

The description provides clear context on when to use the tool (for tracing data flows, including child and store-mediated flows) and how to handle ambiguous matches (re-call with 'file'). However, it does not explicitly mention when not to use it or compare it to alternative tools like 'verify_data_flow'.

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

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.

ParametersJSON Schema

Name	Required	Description
`file`	No	Optional path substring to disambiguate when the name matches multiple files
`name`	Yes	Item name (e.g., "CompleteHandoffButton", "useHandoffState")
`depth`	No	Recursion depth (1-3, default 1). Depth 2+ includes nested dependsOn/usedBy on child nodes.

TDQS

A4.1/5.0

Behavior3/5

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

No annotations provided, so description must fully disclose behavior. It mentions returning both upstream and downstream relationships and supports recursive traversal with depth up to 3. However, it does not explicitly state it is a read-only operation, nor does it describe the structure of the returned data. This is adequate but not comprehensive.

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

Conciseness5/5

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

Two sentences, front-loaded with the main action, followed by return type and use case. No superfluous information. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the absence of an output schema, the description only vaguely states it returns relationships. For an agent to properly interpret the tool's output, more detail on the structure of the returned dependency chain (e.g., format of nodes, edges) would be beneficial. However, for a dependency chain tool with recursive traversal, the description provides a reasonable level of completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema already describes all three parameters with 100% coverage. The description adds value by explaining the depth parameter's purpose more specifically: 'Depth 2+ includes nested dependsOn/usedBy on child nodes.' This goes beyond the schema's generic description of depth as 'Recursion depth (1-3, default 1).' The examples for name parameter also help.

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?

Description clearly states the tool gets the full dependency chain for any component, hook, or service, specifying both upstream and downstream relationships. This distinguishes it from siblings like find_component_usages or get_data_flow. The mention of recursive traversal with depth parameter adds specificity.

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

Usage Guidelines4/5

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

Description indicates it is useful for understanding impact of changes and tracing data flow, providing clear context. However, it does not explicitly state when not to use it or compare to alternative tools like find_component_usages or whats_affected, which could help further differentiation.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`file`	No	Optional path substring to disambiguate when the name matches multiple files
`name`	Yes	Hook name (e.g., "useHandoffState", "usePatientData")

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description covers the ambiguous response behavior and lists return contents, but does not specify error handling for missing names or other edge cases.

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

Conciseness5/5

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

The description is concise with three sentences: first states purpose, second lists returns, third covers edge case. No fluff and front-loaded.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers primary usage and ambiguous disambiguation, lists return contents (compensating for no output schema), but omits behavior when name is not found. Fairly complete for a moderately complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Input schema already describes both parameters adequately (100% coverage). The description reinforces the disambiguation use of `file` but does not significantly extend beyond the schema.

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 clearly states the tool retrieves detailed information about a custom hook or Vue composable, distinguishing it from sibling tools like get_component_detail by specifying the resource type and listing specific return fields.

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 explains how to handle ambiguous matches by re-calling with `file`, but does not provide explicit guidance on when to use this tool over alternatives or when not to use it.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

No annotations are provided, so the description must carry the full burden. The verb 'Get' implies a read-only retrieval with no side effects, which is positive. However, the description does not mention any potential limitations (e.g., size of mapping, performance), authentication needs, or data freshness. It is minimally adequate but not thorough.

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 a single sentence that effectively front-loads the main purpose. It is concise but lists many return items in a stream-of-consciousness style. Slightly improving structure (e.g., listing items) could enhance readability but it remains efficient.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given zero parameters and no output schema, the description covers the return content comprehensively (routes, components, protection, hooks, child components, dynamic segments, hierarchy). It is nearly complete for a simple retrieval tool, though it lacks mention of any edge cases or limitations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

There are zero parameters, and the input schema is empty with 100% coverage. According to the guidelines, the baseline for 0 parameters is 4. The description adds no parameter information because there are none, which is appropriate.

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 clearly states the purpose: getting the complete route -> page -> component mapping. It lists specific return items (protection status, hooks, child components, etc.), making it highly specific and differentiating it from siblings that might focus on other aspects like component details or architecture overviews.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives such as get_architecture_overview or get_component_detail. The description only states what the tool does, but omits any context about when it's appropriate or when to choose another sibling tool.

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

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.

ParametersJSON Schema

Name	Required	Description
`url`	No	Absolute URL or dev-server-relative path to open.
`route`	No	Route path to open (e.g., "/patients/:id").
`params`	No	Values for dynamic route segments, e.g. {"id": "123"}.
`settleMs`	No	Extra milliseconds to wait after load before inspecting.
`component`	No	Catalog component name whose route to open (resolved via the route map).

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description must carry full weight for behavioral disclosure. It states the tool 'walks React/Vue dev internals' and requires the dev server, which are important constraints. However, it does not mention whether the tool is read-only, what happens on error (e.g., if the dev server is not running), or performance implications. This leaves some gaps beyond what the context signals provide.

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

Conciseness5/5

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

The description is concise (4 sentences) and front-loaded with the core purpose. Every sentence adds value: first sentence defines the tool, second explains the internal mechanism, third lists input options, fourth covers output format and prerequisite. No redundant or vague phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (5 parameters, no output schema, no annotations, 21 siblings), the description covers the main use case, prerequisite, and key distinction from render_component. It lacks explicit description of the output format beyond 'text-only output' and does not discuss error scenarios or edge cases. An example of the output would improve completeness, but it is still adequate for an agent to decide when to invoke.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% description coverage, so baseline is 3. The description adds value by explaining the relationship between component, route, and url: 'Give a catalog component, a route, or a raw url.' This clarifies that these are alternative ways to specify the target page, which is not obvious from the schema alone. The settleMs parameter is not elaborated in the description, but the schema handles it.

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 clearly states the tool's purpose: 'open a live page and report which CATALOG components are actually mounted on it, mapped back to their source files.' It distinguishes from siblings by explicitly noting 'Text-only output (use render_component for a screenshot).' The verb 'inspect' and the resource 'rendered page' are specific and unambiguous.

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

Usage Guidelines4/5

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

The description provides clear usage guidance: 'use it to go from the thing I see on screen to the file I should edit without grepping.' It mentions an alternative tool (render_component) and a prerequisite (dev server must be running). However, it doesn't explicitly contrast with other siblings like check_page or find_component_usages, which could also be relevant.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`layer`	No	Optional: filter the components list to one architecture layer
`verbose`	No	Return full Component objects instead of compact summaries (default false; large output)

TDQS

A4.3/5.0

Behavior4/5

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

With no annotations, the description carries full behavioral disclosure. It describes the return structure (totalCount, lastScanned, byLayer, components), notes that byLayer covers the whole catalog, and warns that verbose can be 'large'. This provides sufficient transparency for a read-only operation.

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

Conciseness5/5

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

The description is concise, with no wasted words. It front-loads the core purpose and structures information logically: return format, then parameter guidance, then follow-up suggestion.

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 no output schema, the description adequately explains the return structure. It covers the two parameters and provides a follow-up recommendation. For a tool with many siblings, it provides sufficient context for an agent to decide when to use it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Both parameters have 100% schema description coverage, so the schema already documents them. The description restates that layer filters the components list and verbose returns full metadata, but does not add significant new meaning beyond the schema.

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 clearly states the tool lists the codebase catalog as compact summaries with specified fields. It distinguishes itself from sibling tools like get_component_detail (which provides full data for one item) and get_architecture_overview.

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

Usage Guidelines4/5

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

The description explains when to use verbose mode and suggests following up with get_component_detail for full item data. It also mentions the layer filter. However, it does not explicitly exclude cases or compare with other sibling tools like search_components.

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

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.

ParametersJSON Schema

Name	Required	Description
`route`	No	Optional: render a raw route path directly instead (e.g., "/patients/:id"). Use instead of `component`.
`params`	No	Values for dynamic route segments, e.g. {"id": "123"}. If omitted, sensible placeholders are guessed.
`public`	No	Skip the configured login pre-step for this call — use for public routes so a broken/missing credential can't block them (default false).
`fullPage`	No	Capture the full scrollable page instead of just the viewport (default false).
`settleMs`	No	Extra milliseconds to wait after load before screenshotting (e.g. for animations).
`component`	No	Catalog component name to render (e.g., "PatientDetail"). The route map resolves it to a URL.

TDQS

A3.9/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses the outputs (screenshot and diagnostics) and the requirement of a running dev server. However, it does not mention whether the tool has any side effects (e.g., modifying state) or authentication requirements.

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

Conciseness5/5

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

The description is concise (4 sentences) and front-loaded with the primary action. Every sentence adds value, including the purpose, output, mechanism, use case, and requirement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the complexity (6 parameters, no output schema, no annotations), the description explains the main outputs and prerequisite but lacks details on the exact return format (e.g., media type of screenshot, structure of diagnostics) and error handling.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 100% coverage with detailed descriptions for each parameter. The tool description itself does not add any additional meaning beyond what the schema provides, so the baseline score is appropriate.

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 clearly states the tool renders a catalog component and returns a screenshot plus runtime diagnostics. It distinguishes from siblings by mentioning automatic route resolution via the route map and focusing on visual verification of a component change.

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

Usage Guidelines4/5

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

The description provides explicit context on when to use the tool (to visually confirm a change works) and a prerequisite (dev server running). However, it does not explicitly state when not to use it or list alternatives among the sibling tools.

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

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.

ParametersJSON Schema

Name	Required	Description	Default
`relogin`	No	Re-run the login flow immediately after resetting (default true). Set false to just clear state and let the next authed call trigger login.

TDQS

A4.5/5.0

Behavior4/5

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

No annotations provided, so description carries full burden. It discloses the recovery nature, no-op condition, and that it clears state. Lacks mention of permissions or if repeated calls have side effects, but still provides solid behavioral context.

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?

Description is moderately sized but each sentence is meaningful. It front-loads the main action, follows with usage guidance and edge cases. Minor redundancy but overall well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a tool with one optional parameter and no output schema, the description covers use cases, edge cases (no-op, public routes), and parameter behavior. It does not mention return value, but is adequate for agent decision-making.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% for the single parameter. Description adds value by stating default behavior (relogin defaults true) and effect of false (just clear state). Goes beyond what schema provides.

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 clearly states the tool recovers the browser's authenticated session in-place, with specific actions: re-read config, clear cookies/storage, re-run login flow. It distinguishes from sibling tools which are about component analysis, not session management.

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

Usage Guidelines5/5

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

Explicitly states when to use: when authed runtime tools fail with login error or after changing browser.login config. Also clarifies when not needed: public routes can skip login entirely, providing a clear alternative parameter.

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

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.

ParametersJSON Schema

Name	Required	Description
`layer`	No	Optional: filter results to a specific architecture layer
`limit`	No	Maximum results to return (default 20)
`query`	Yes	Search query - component name, keyword, or multi-word phrase (e.g., "patient card", "handoff button")

TDQS

A4.2/5.0

Behavior4/5

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

With no annotations, the description appropriately discloses that the tool uses fuzzy matching and multi-token scoring, and returns ranked results with a _score. It implies read-only behavior, though not explicitly stated. No contradictions.

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

Conciseness5/5

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

Two sentences: first covers action and scope, second covers matching method and follow-up instruction. No wasted words, front-loaded with key information.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description explains the return format (compact summaries with name, layer, path, _score) which is important since no output schema. It could mention the default limit (20) but otherwise complete for a search tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so baseline is 3. The description adds context on matching algorithm and return format, but not significantly beyond the schema's parameter descriptions. The layer and limit parameters are already well-described in schema.

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 clearly states it searches across the full codebase by name, path, description, or keywords, listing specific entity types. It distinguishes itself from sibling tools like get_component_detail and get_component_props by noting it returns compact summaries and advising follow-up for full data.

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

Usage Guidelines4/5

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

The description provides good context on when to use this tool (initial search) and explicitly mentions follow-up with get_component_detail/props for full details. However, it does not explicitly state when not to use it or other alternatives beyond those two.

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

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.

ParametersJSON Schema

Name	Required	Description
`file`	No	Optional path substring to disambiguate when the name matches multiple files
`name`	Yes	Component or composable name whose data flow to verify (e.g., "PatientDetail").
`depth`	No	How deep to trace the child component tree for predictions (default 3).
`params`	No	Values for dynamic route segments, e.g. {"id": "123"}.
`actions`	No	Optional interactions to run after the route loads and BEFORE network traffic is evaluated (e.g. fill a form and click Save to exercise a POST).
`settleMs`	No	Extra milliseconds to wait before reading the observed network traffic (default 500).

TDQS

A4.4/5.0

Behavior4/5

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

Without annotations, the description carries full burden. It outlines the workflow (render, interact, wait, compare) and explains key outputs (unexpectedApiCalls, verdict) and behavior (method-aware, delayed reading). Minor omission of side effects, but overall transparent.

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 a single dense paragraph but efficiently conveys all necessary information. It could be improved with structural elements like bullet points, but it remains readable and focused.

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 (6 params, nested objects, no output schema), the description thoroughly covers the workflow, expected outputs, and prerequisites (dev server). It leaves no critical gaps for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so baseline is 3. The description adds value by explaining the purpose of actions (exercising mutations) and settleMs (wait time), and provides examples for within. This elevates it above baseline.

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 clearly defines the tool's function: comparing real network traffic against static analysis predictions. It uses a specific verb (verify), resource (data flow), and methodology (method-aware matching), differentiating it from siblings like get_data_flow.

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

Usage Guidelines4/5

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

The description explains when to use the tool (after static analysis) and notes a prerequisite (dev server running). It also details how actions drive mutation endpoint verification, providing sufficient context despite lacking explicit alternatives.

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

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.

ParametersJSON Schema

Name	Required	Description
`files`	No	Workspace-relative changed files (e.g., ["src/hooks/useUsers.ts"]). Omit to auto-detect from git status.
`offset`	No	Skip this many affected items (for paging past the default 100-item page). Default 0.
`maxItems`	No	Page size for affectedItems (max 500). Default 100.
`maxDistance`	No	Cap the upstream walk at this distance (1 = direct users only). Default 5.

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations provided, the description carries full burden. It discloses the upstream walk, risk classification, ordering by risk, and auto-detection from git status. It does not mention authorization or rate limits, but for a read-only analysis tool, the transparency is adequate.

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 a single dense paragraph that is efficient but could be slightly more structured for readability. It front-loads the key action ('edit→verify glue') and provides all necessary details without redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's complexity (dependency graph, risk classification, paging) and lack of output schema, the description adequately describes the output components (risk per file, overallRisk, ordered routes). It provides sufficient context for an agent to understand the return value.

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?

Schema description coverage is 100%, and the description adds significant context: auto-detection for the files param, paging for offset and maxItems, and distance cap meaning for maxDistance. It also explains the risk classification and overall risk in the output.

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 clearly states the tool's purpose: given changed files (or auto-detected from git status), it walks the dependency graph upstream to find affected components/pages, maps to routes, and returns verification targets. It distinguishes from siblings like check_page or render_component by being a planning/discovery tool, not a direct action tool.

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

Usage Guidelines4/5

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

The description explicitly says 'Call it after editing to know exactly what to re-check in the browser and how carefully,' providing clear when-to-use guidance. It doesn't explicitly mention when not to use or alternatives, but the context implies it's for post-edit analysis, not for other tasks.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

21 tool updatesv3.0.0Jul 8, 2026
- First observedaudit_template_patterns
- First observedcapture_flow
- First observedcheck_page
- First observedfind_component_usages
- First observedfind_dangling_listeners
- First observedfind_dead_code
- First observedfind_similar_components
- First observedget_architecture_overview
- First observedget_component_detail
- First observedget_component_props
- First observedget_data_flow
- First observedget_dependency_chain
- First observedget_hook_detail
- First observedget_route_map
- First observedinspect_rendered_page
- First observedlist_all_components
- First observedrender_component
- First observedreset_login
- First observedsearch_components
- First observedverify_data_flow
- First observedwhats_affected

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4.2/5.0

Disambiguation5/5

Each tool targets a distinct aspect of codebase analysis and testing, from finding dead code to auditing templates to verifying data flows. Even tools that seem similar (e.g., check_page vs. render_component vs. capture_flow) have clearly different scopes: one-time snapshot, component rendering, and multi-step flows, respectively. No two tools have overlapping purposes.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern using lowercase and underscores (e.g., find_dead_code, get_component_detail, capture_flow). No mixing of conventions like camelCase or different verb styles. The naming is predictable and readable.

Tool Count4/5

21 tools is on the higher end but well-justified for a comprehensive codebase exploration and testing suite. Each tool serves a specific purpose, and the count reflects the breadth of features (catalog browsing, impact analysis, runtime verification, etc.) without feeling excessive.

Completeness5/5

The tool set covers the full lifecycle of codebase analysis: discovery (list/search), inspection (get_component_detail, get_data_flow), dependency mapping (get_dependency_chain, whats_affected), dead code detection, template auditing, runtime verification (check_page, render_component, capture_flow), and even login recovery. There are no obvious gaps for the intended use case.

Maintenance

ActivityStale

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

mcp
dev.augments
Augments MCP Server - A comprehensive framework documentation provider for Claude Code
Developer Tools Documentation Access
2128
Remote Desktop CommanderOAuth
app.desktopcommander
Hosted MCP server connecting claude.ai, ChatGPT and other AI apps to your own computer
Shell Access OS Automation
219
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2
gread A
io.github.NitroRCr
An MCP server that gives your AI access to the source code and docs of all public github repos
Version Control Code Analysis Documentation Access
5361

Related MCP Servers

lovable-mcp-server
Developer Tools Code Analysis
hiromima
A
license
Not graded
quality
F
maintenance
An MCP server for real-time analysis of Lovable-generated projects, enabling Claude Desktop to instantly understand project structure, components, dependencies, and more.
Updated a year ago (2025-08-07 13:04 UTC)
39
MIT
Component Library MCP
Developer Tools Code Analysis
vasyl-bilous
A
license
B
quality
D
maintenance
An MCP server that scans React and Vue projects, extracts component metadata (props, slots, events, imports, usage), and exposes it to AI coding agents via structured tools.
Updated 4 months ago (2026-04-28 17:00 UTC)
7
1
MIT
vue-ts-lsp
Developer Tools Code Analysis
enc0ded
A
license
Not graded
quality
B
maintenance
Self-contained MCP server providing type-aware code intelligence for TypeScript, JavaScript, and Vue files, exposing tools like hover, definition, references, and diagnostics to Claude Code without requiring global language server installations.
Updated 3 months ago (2026-06-19 15:46 UTC)
MIT
solograph
Code Analysis Search Knowledge & Memory
fortunto2
A
license
A
quality
B
maintenance
Code intelligence MCP server for Claude Code providing multi-project code graph, semantic search, session history, knowledge base, and web search.
Updated 15 days ago (2026-08-24 11:28 UTC)
15
3
MIT

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

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

Atlas UI

TLDR: Quick Start

What it does

Setup

Claude Code

Claude Desktop

Configuration

Defaults by framework

Scan coverage warning

Tools

list_all_components

search_components

get_component_props

find_similar_components

compare_implementations

get_component_detail

find_component_usages

whats_affected

get_architecture_overview

get_dependency_chain

get_route_map

get_section_map

get_hook_detail

find_dead_code

get_data_flow

Runtime browser tools — let agents check their work

render_component

check_page

verify_data_flow

inspect_rendered_page

capture_flow

Browser configuration

Login pre-step (authenticated routes)

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

`list_all_components`

`search_components`

`get_component_props`

`find_similar_components`

`compare_implementations`

`get_component_detail`

`find_component_usages`

`whats_affected`

`get_architecture_overview`

`get_dependency_chain`

`get_route_map`

`get_section_map`

`get_hook_detail`

`find_dead_code`

`get_data_flow`

`render_component`

`check_page`

`verify_data_flow`

`inspect_rendered_page`

`capture_flow`