Uxia

Returns the Usability Optimization Score (UoS, 0–100) for a test — Uxia's proprietary whole-flow UX score derived from the test's issues, each weighted by severity and by the share of testers who hit it, and corrected for audience size — plus its qualitative label (Partial/Good/Very Good/Excellent), a breakdown of the contributing issue counts (high/medium/low) and the weighted issue load, and an `about` field explaining what the score means, how to read the bands, and how it helps compare different flows tested with similar audiences. Call this when the user asks how the test scored overall, e.g. 'what's the optimization score', 'how usable is this', or 'what's the overall result'. This is NOT the UXIA-Q satisfaction score (0–5) — for UXIA-Q or SUS call get_satisfaction_score instead.

get_optimization_score

Fetch the individual respondent answers to ONE market-research survey question, by its questionId (obtain the questionId from get_market_research_summary). Returns each respondent's name, a short persona description, their answer, and their stated reasoning. Use the optional 'filter' to narrow to one segment — the same buckets a chart bar represents: 'Yes'/'No' for yes/no, a rating value (e.g. '4') for rating, an exact option label for multiple choice, or a cluster theme for open-ended. Call this only when the user wants the actual individual responses or a specific segment's verbatim answers; the aggregate distributions and per-question summaries are available separately (via get_market_research_summary).

get_question_responses

Returns the self-reported satisfaction scores for a test: the overall UXIA-Q score (0–5, the average of four pillars — usability, trust, appearance, loyalty), each pillar score, and the SUS (System Usability Scale, 0–100 with a letter grade) when computed, plus an `about` field explaining what these scores mean. Call this when the user asks about the UXIA-Q score, a satisfaction pillar, the SUS score, or what those scores mean (e.g. 'what's the UXIA-Q score', 'how do testers rate trust', 'what's the SUS', 'what does this score mean'). This is NOT the Usability Optimisation Score (0–100, computed from issues) — for that call get_optimization_score. If a score is null it was not computed for this test; say so rather than substituting another metric.

get_satisfaction_score

Drill into one screen by frame index: aggregated metrics, any loop activity, and a per-tester list with visits, misclicks, and their last action on that screen. Each tester entry includes a 'transcript:<id>' ref the user can click to open the full transcript. Use this after list_screen_metrics or list_dropoff_points has pointed at a specific screen.

get_screen_details

Summarise the test's strengths — the things testers responded well to, found easy, or appreciated — by analysing the testers' post-test reflections together with the test's satisfaction scores. Call this when the user asks for strong points, strengths, positives, what worked well, or what testers liked. Returns strength themes, each with a short description and the supporting testers (with a transcript reference per tester). If there are no tester reflections, it reports that none are available rather than inventing positives.

get_strengths

Get full detail for one WCAG success criterion in this accessibility test, by its WCAG code (scId, e.g. '1.4.3'). Returns Uxia's plain-language description and examples, the remediation teams, this test's result (status, evidence, recommended verification steps, and affected frames), and a link to the official W3C 'Understanding' page. Use the scId from list_success_criteria.

get_success_criterion

Get metadata for one test in the caller's workspace by its id (obtain the id from list_tests). Returns title, goal, status, type, source, creation date, a 'url' deep link to open the test in Uxia (consider sharing this 'url' with the user as a clickable link), and 'hasResults' — only when hasResults=true will the per-test analytics tools (list_insights, get_insight, etc.) return data for this test.

get_test

Get one real AI tester's individual post-test answer for a single post-test question, plus that question's response/clustering context. Each individual tester answer includes a stable quote ref. Pass testerName only when it is an actual tester name returned by list_test_questions.testerNames; never pass placeholders like "all", "everyone", or "testers". For all tester responses, call list_test_questions, then call this tool once per listed testerName for each relevant question. For one tester's answers across all post-test questions, call list_test_questions, then call this tool once per listed question with testerName set to that tester. Do not use transcript tools for post-test response requests. Pass the "ref" string exactly as list_test_questions returned it; do NOT construct the ref yourself or derive it from the question number.

get_test_question_responses

Get the current test setup: title, the tester mission (returned as "goal"), the scenario/context shown to testers, and the configured post-test questions. The "goal" field IS the mission (the concrete action the tester performs); "scenario" is the situational framing around it. Use this when the caller asks for the test scenario, test context, mission, goal, or configured questions for a specific test.

get_test_setup

Fetch one AI tester's full profile by name (age, demographics, role, psychological profile) and render it as a tester card. Match is case-insensitive and partial. Use when the user asks about a specific tester by name — e.g. "tell me about Sarah", "who is tester X", "show me X's profile". Tester names come from list_insights / list_transcripts. If several testers match the name it returns candidate names to disambiguate; if none match it reports that and lists the available testers. Scoped to this test's testers only.

get_tester

Read a single tester transcript as plain text. The ref is what list_transcripts returns (format: 'transcript:<id>'). Paginate via offset+limit (chars) if the transcript is long.

get_transcript

List WCAG accessibility tests in the caller's workspace, most recent first. These are a distinct kind of test from usability tests (list_tests) — they audit screens against WCAG success criteria. Use this to find an accessibility test's id before calling list_success_criteria or get_success_criterion, which require a testId. Pass 'query' to search by title, 'status' to filter, and 'limit' to cap results. Each result includes 'hasResults' (only hasResults=true tests can be analyzed) and a 'url' deep link to open the test in Uxia.

list_accessibility_tests

List up to 10 audiences in the caller's Uxia workspace. Use this to discover existing audiences before creating a new one, to reference an audience by id in another action, or to summarize the workspace's targeting setup.

list_audiences

Screens where testers stopped progressing, ranked by how many testers dropped off there. Use this for 'where did testers drop off', 'where did people get lost', 'which screen lost the most testers'. Each point includes the absolute count, the share of all testers, and how many distinct drop-off paths end on that screen.

list_dropoff_points

List the real human-participant recording sessions for this test (talk-aloud transcripts + post-test answered questions). These are actual people who took the test, distinct from the AI testers covered by list_transcripts. Returns lightweight summaries; call get_human_session with a returned ref to read a session's full transcript and answers.

list_human_sessions

List insights (UX issues) found in this test, sorted by severity (high → prototype). ONE call returns all severities together — do NOT call this multiple times to iterate per severity or per category. For 'top N insights' just call with the appropriate limit. Use the severity or category filters only when the user asks for a specific slice. To answer 'what did <AI tester> flag / raise as issues?', pass that tester's name in the optional `testerName` filter — it keeps only insights where one of the supporting quotes is attributed to that tester (case-insensitive, partial match). Omit it to list across all testers (never pass a blank value or a group word like 'human'). This covers AI testers only; for a human participant use get_human_session. If unsure of the exact tester names, call list_transcripts first. Call get_insight with a returned 'ref' for full evidence. Severity values: high | medium | low | prototype.

list_insights

Screens that testers came back to after navigating away — a signal of confusion, dead-ends, or testers backtracking to look for something. Use this for 'what screens caused loops', 'where did people go in circles', 'screens with backtracking'. A revisit is counted when a tester returns to a screen they had previously left.

list_loop_screens

List the distinct paths testers took, sorted by how many testers followed each path. Use this for 'most common path', 'what paths did testers follow', 'what paths did the ones who dropped off take'. Each path is a sequence of screens/pages with completion/drop-off counts. Filter by status ('success' or 'drop-off') for drop-off-specific queries. On live (livepages) tests, paths are the page sequences testers visited (labeled by page title/URL) and misclick/attempt figures are omitted; filtering status='drop-off' shows which page sequences ended in a drop-off.

list_paths

Per-screen navigation metrics (misclick rate, average attempts, total clicks, testers reached), sortable. Use this for 'which screens had the most misclicks', 'which screen was hardest to use', 'screens with the most attempts'. Pass sortBy to pick the ranking dimension; default is misclick rate descending.

list_screen_metrics

List the WCAG success criteria evaluated in this accessibility test, sorted by WCAG code. Each item has its status (passed | failed | review), conformance level (A | AA | AAA), category (Perceivable | Operable | Understandable | Robust), review scope (design and/or code), and a short evidence summary. ONE call returns every criterion together — do NOT call repeatedly to iterate per status or level. Use the optional filters only for a specific slice: 'status' (e.g. failed to see only failures), 'level', 'category', or 'reviewScope'. Call get_success_criterion with a returned 'scId' for full guidance, the per-test evidence, recommended verification steps, and a link to the official WCAG page.

list_success_criteria

List post-test questions asked at the end of the study, with the count of tester responses each received and the tester names that answered each question. In this product, "tester responses", "all tester responses", "question responses", and "what did testers answer?" mean these post-test question answers by default. Each question has a 1-based "number" — the position the user sees, so the user's "question 1" / "Q1" is the item with number 1. To show tester responses, call get_test_question_responses with this tool's exact question ref and a real testerName from testerNames. For all tester responses, call get_test_question_responses once per testerName; never pass placeholders like "all", "everyone", or "testers" as testerName. Never build the ref yourself from the question number. Do not use transcript tools for response/answer requests.

list_test_questions

List usability tests in the caller's workspace, most recent first. Use this to find a test's id before calling the per-test tools (list_insights, get_insight, etc.), which require a testId. Pass 'query' to search by title (case-insensitive substring), 'status' to filter, and 'limit' to cap results. Each result includes 'hasResults' — only tests with hasResults=true can be analyzed by the per-test tools — and a 'url' deep link to open the test in Uxia (consider sharing this 'url' with the user as a clickable link).

list_tests

List AI-tester task-session transcripts (one per tester) with step counts. This is for session steps, clicks, reasoning, expectations, and screen-by-screen behavior — NOT post-test question answers. For "tester responses", "all tester responses", "question responses", or "what did testers answer?", use list_test_questions and get_test_question_responses instead. Pass the optional `testerName` filter (case-insensitive, partial) to narrow to a single tester — e.g. 'why did Carlos click X' is `{ testerName: 'Carlos' }`; omit it to list every tester. Use get_transcript with a returned ref to read the full text.

list_transcripts

Inspect one audience before launching a livepage test. Returns the current approved tester count, the exact tester count after MCP auto-approval and plan limits, the exact expected credit usage, and whether a free launch allowance applies. Call this immediately before asking the user to approve a launch.

preview_audience_launch

Search the AI testers' quotes (the automated testers that ran the flow) across all insights and any standalone user_quotes, for a substring (case-insensitive). AI TESTERS ONLY: this does NOT cover human-participant sessions — for anything a human/real participant said, use get_human_session, never this tool. `query` is the TOPIC only — what was said (e.g. 'payment gateway', 'CTA'); do NOT put a tester's name in `query`. To restrict results to one AI tester, pass their name in the separate optional `testerName` filter (case-insensitive, partial); omit it to search across all testers (never pass a blank value or a group word like 'human'). So 'what did Jaime say about the payment gateway?' is `{ query: 'payment gateway', testerName: 'Jaime' }`. Returns matched quotes with the source insight ref where applicable.

search_quotes