Web Performance Insights

Get AI-powered recommendations to IMPROVE, FIX, or OPTIMIZE a specific website performance metric. Returns actionable analysis with concrete fixes for Lighthouse categories and Core Web Vitals. If no analysis exists yet for that page + metric, the tool STARTS one automatically and returns `state: "pending"`; the widget loads the results when the job finishes (do NOT re-call the tool yourself). A completed analysis is returned as-is — repeat calls never start a duplicate job. `state: "pending"` covers TWO waits, and neither is an error: 1. the AI analysis job is running, or 2. the page had no audit yet (or the audit is still running), so a Lighthouse audit is running first — this takes 1-2 minutes and the analysis follows automatically. In both cases say briefly that it is still running and STOP. Do NOT call this tool again, do NOT call any other tool, and never tell the user the analysis failed — the widget polls on its own. ## When to Use User explicitly asks to IMPROVE, FIX, ANALYZE, or OPTIMIZE a metric: - Keywords: improve, fix, analyze, optimize, enhance, boost, reduce, "what's wrong with", "how to improve" - Metrics: performance, SEO, accessibility, best-practices, LCP, FCP, TBT, CLS, SI, TTI ## Do NOT use - "get / show / check <metric>" (view the number, no advice) → `perfmon_get_audit_data` - "run / start a new audit" → `perfmon_run_audit` ## Inputs - metric_name (REQUIRED): Lighthouse category or Core Web Vital. Default: "performance" if user doesn't specify. - test_id (priority) or url (fallback): identifies the page. If the user named NEITHER ("analyze accessibility from Hanoi"), call the tool anyway with just what you have - it answers `state: "form"` with a setup form the user fills in. Do NOT ask for the URL in chat instead of calling, and do NOT invent one. - device / location (OPTIONAL): pin the audit point on the url route; IGNORED when test_id is given. Pass BOTH when the user named a device and a test location. On the url route, supplying both lets the tool start a new audit at exactly that combination when no audit matches yet; with only one of them (or neither) it answers with the setup form instead of guessing the other. ## Examples | User Prompt | metric_name | identifier | |---|---|---| | "How to improve performance for example.com?" | performance | url: example.com | | "Fix LCP issues" | largest-contentful-paint | (from context) | | "Optimize SEO for test_123" | seo | test_id: test_123 | ## RESPONSE BEHAVIOR (VERY IMPORTANT) On success, `content[0].text` (= `structuredContent.response_instruction`) contains a <system_instruction> block. FOLLOW IT: 1. Reply BRIEFLY in your own words — the widget already shows the full analysis and recommendations, so just point the user to it (do NOT restate the details, do NOT show internal IDs). 2. Do NOT print a numbered next-step list — the next steps are shown as clickable "Next suggestion" cards inside the widget; the user clicks one to run it. 3. Do NOT call another tool after this response — wait for the user's choice. ## TOOL ROUTING (shared across every perfmon tool — obey before choosing) Match the user's ACTION VERB, never the data noun. "audit", "test", "report" and "score" are NOUNS naming the data; on their own they do NOT mean "make a new one". | User intent | Action verbs | Tool | |---|---|---| | View existing data / scores / history | get, show, check, view, display, fetch, "what is", "how is X performing", trends, history | `perfmon_get_audit_data` | | Start a NEW measurement | run, start, trigger, launch, re-run, "again", "new audit", "measure it now" | `perfmon_run_audit` | | Improve / fix a metric | improve, fix, optimize, analyze, enhance, reduce, "what's wrong with" | `perfmon_analyze_metric` | | Real-user field data only | CrUX, "real user", "field data", "real-world metrics" | `perfmon_get_crux_data` | | Export a PDF | generate, export, download, save + (PDF / report) | `perfmon_generate_report` | | Two named pages, head-to-head | compare, "versus", "vs competitor" | `perfmon_compare_page_insights` | | Three or more pages, ranked | benchmark, rank, "against each other" | `perfmon_benchmark_page_insights` | | Greeting / capability question | hi, hello, "what can this do", "how do I start" | `perfmon_introduce` | ### Tiebreakers - **Noun-only prompt** ("audit niteco.com", "performance for niteco.com") is NOT a request for a new measurement. Use `perfmon_get_audit_data`. Starting a new audit requires an explicit run / start / new / again word. - **Same metric, different verb**: "get LCP" -> `perfmon_get_audit_data`; "improve LCP" -> `perfmon_analyze_metric`. - **DEFAULT when still ambiguous -> `perfmon_get_audit_data`.** It is read-only and instant, and when no data exists it tells the user to run an audit — so guessing it is cheap, while guessing `perfmon_run_audit` wrongly costs the user a 2-3 minute run they did not ask for.

Benchmark and rank two or more pages against each other on the same device and test location — best-first by Lighthouse Performance. Returns each page's Lighthouse category scores, Core Web Vitals, and CrUX field data. Provide `page_urls` (';'-separated, at least 2 distinct URLs), `device`, and `location`. If device or location is missing or unknown, the tool returns a form so the user can pick a supported device and location. A missing or mismatched audit on any page is run automatically at the requested device + location; while that audit runs the tool returns `state: "pending"` and the widget polls until the ranking is ready (do NOT re-call the tool yourself). ## RESPONSE BEHAVIOR (VERY IMPORTANT) On success, `content[0].text` (= `structuredContent.response_instruction`) contains a <system_instruction> block. FOLLOW IT: 1. Reply BRIEFLY in your own words — the widget already shows the ranking, so just point the user to it and state which page leads (do NOT restate the numbers). 2. Do NOT print a numbered next-step list — next steps are shown as clickable cards in the widget; the user clicks one to run it. 3. Do NOT call another tool after this response — wait for the user's choice. ## Do NOT use - Only ONE page named, or a single page's own data → `perfmon_get_audit_data` - Exactly TWO pages head-to-head → `perfmon_compare_page_insights` ## TOOL ROUTING (shared across every perfmon tool — obey before choosing) Match the user's ACTION VERB, never the data noun. "audit", "test", "report" and "score" are NOUNS naming the data; on their own they do NOT mean "make a new one". | User intent | Action verbs | Tool | |---|---|---| | View existing data / scores / history | get, show, check, view, display, fetch, "what is", "how is X performing", trends, history | `perfmon_get_audit_data` | | Start a NEW measurement | run, start, trigger, launch, re-run, "again", "new audit", "measure it now" | `perfmon_run_audit` | | Improve / fix a metric | improve, fix, optimize, analyze, enhance, reduce, "what's wrong with" | `perfmon_analyze_metric` | | Real-user field data only | CrUX, "real user", "field data", "real-world metrics" | `perfmon_get_crux_data` | | Export a PDF | generate, export, download, save + (PDF / report) | `perfmon_generate_report` | | Two named pages, head-to-head | compare, "versus", "vs competitor" | `perfmon_compare_page_insights` | | Three or more pages, ranked | benchmark, rank, "against each other" | `perfmon_benchmark_page_insights` | | Greeting / capability question | hi, hello, "what can this do", "how do I start" | `perfmon_introduce` | ### Tiebreakers - **Noun-only prompt** ("audit niteco.com", "performance for niteco.com") is NOT a request for a new measurement. Use `perfmon_get_audit_data`. Starting a new audit requires an explicit run / start / new / again word. - **Same metric, different verb**: "get LCP" -> `perfmon_get_audit_data`; "improve LCP" -> `perfmon_analyze_metric`. - **DEFAULT when still ambiguous -> `perfmon_get_audit_data`.** It is read-only and instant, and when no data exists it tells the user to run an audit — so guessing it is cheap, while guessing `perfmon_run_audit` wrongly costs the user a 2-3 minute run they did not ask for.

Compare the performance of two pages head-to-head — your page versus a competitor page — on the same device and test location. Returns each side's Lighthouse category scores, Core Web Vitals, and CrUX field data, plus the per-category gap (your page minus competitor). Provide `your_page_url`, `competitor_page_url`, `device`, and `location`. If device or location is missing or unknown, the tool returns a form so the user can pick a supported device and location. A missing or mismatched audit on either side is run automatically at the requested device + location; while that audit runs the tool returns `state: "pending"` and the widget polls until the comparison is ready (do NOT re-call the tool yourself). ## RESPONSE BEHAVIOR (VERY IMPORTANT) On success, `content[0].text` (= `structuredContent.response_instruction`) contains a <system_instruction> block. FOLLOW IT: 1. Reply BRIEFLY in your own words — the widget already shows the side-by-side comparison table, so just point the user to it and state which page leads (do NOT restate the numbers). 2. Do NOT print a numbered next-step list — next steps are shown as clickable cards in the widget; the user clicks one to run it. 3. Do NOT call another tool after this response — wait for the user's choice. ## Do NOT use - Only ONE page named, or a single page's own data → `perfmon_get_audit_data` - THREE or more pages → `perfmon_benchmark_page_insights` ## TOOL ROUTING (shared across every perfmon tool — obey before choosing) Match the user's ACTION VERB, never the data noun. "audit", "test", "report" and "score" are NOUNS naming the data; on their own they do NOT mean "make a new one". | User intent | Action verbs | Tool | |---|---|---| | View existing data / scores / history | get, show, check, view, display, fetch, "what is", "how is X performing", trends, history | `perfmon_get_audit_data` | | Start a NEW measurement | run, start, trigger, launch, re-run, "again", "new audit", "measure it now" | `perfmon_run_audit` | | Improve / fix a metric | improve, fix, optimize, analyze, enhance, reduce, "what's wrong with" | `perfmon_analyze_metric` | | Real-user field data only | CrUX, "real user", "field data", "real-world metrics" | `perfmon_get_crux_data` | | Export a PDF | generate, export, download, save + (PDF / report) | `perfmon_generate_report` | | Two named pages, head-to-head | compare, "versus", "vs competitor" | `perfmon_compare_page_insights` | | Three or more pages, ranked | benchmark, rank, "against each other" | `perfmon_benchmark_page_insights` | | Greeting / capability question | hi, hello, "what can this do", "how do I start" | `perfmon_introduce` | ### Tiebreakers - **Noun-only prompt** ("audit niteco.com", "performance for niteco.com") is NOT a request for a new measurement. Use `perfmon_get_audit_data`. Starting a new audit requires an explicit run / start / new / again word. - **Same metric, different verb**: "get LCP" -> `perfmon_get_audit_data`; "improve LCP" -> `perfmon_analyze_metric`. - **DEFAULT when still ambiguous -> `perfmon_get_audit_data`.** It is read-only and instant, and when no data exists it tells the user to run an audit — so guessing it is cheap, while guessing `perfmon_run_audit` wrongly costs the user a 2-3 minute run they did not ask for.

Generate a downloadable PDF report containing all audit data, metrics, and analysis results for a web page. ## When to Use User wants to GENERATE, EXPORT, DOWNLOAD, or SAVE a PDF report: - Keywords: generate, export, download, save, create, PDF, report - Requires an EXPORT intent — the word "report" alone is a noun for the data, not a request for a file. ## Do NOT use - "get / show / check the report|audit|score for X" (read on screen, no file) → `perfmon_get_audit_data` - "run / start a new audit" → `perfmon_run_audit` ## Inputs All four are optional: - `test_id` (priority) — one exact completed audit. - `url` (fallback) — resolved to an audit for that page. - `device` + `location` — pin the by-URL resolution to the audit that ran at that exact combination. Pass them whenever the user named a device/location. ## Result - If a matching audit exists: Returns PDF download link in widget. - If none exists at the requested device/location: a fresh audit is STARTED and the response is `state: "generating"`. Say it is running; the widget shows the report itself. Do NOT re-call this tool. - If the requested device/location is not supported: `state: "form"` listing the supported options — never silently exported for a different combination. - If neither test_id nor url was given: `state: "form"` setup form so the user can name the page. Do NOT re-call this tool — wait for their submit. ## Examples - "Generate a report for niteco.com" → url: "niteco.com" - "Export PDF for test_123" → test_id: "test_123" - "Download the audit report" → (url from context) ## RESPONSE BEHAVIOR (VERY IMPORTANT) On success, `content[0].text` (= `structuredContent.response_instruction`) contains a <system_instruction> block. FOLLOW IT: 1. Reply BRIEFLY in your own words — the widget already shows the report; include the download link exactly as instructed in the block (do NOT restate the file name). 2. Do NOT print a numbered next-step list — next steps are shown as clickable cards in the widget; the user clicks one to run it. Do NOT suggest generating a PDF again — it was just created. 3. Do NOT call another tool after this response — wait for the user's choice. ## TOOL ROUTING (shared across every perfmon tool — obey before choosing) Match the user's ACTION VERB, never the data noun. "audit", "test", "report" and "score" are NOUNS naming the data; on their own they do NOT mean "make a new one". | User intent | Action verbs | Tool | |---|---|---| | View existing data / scores / history | get, show, check, view, display, fetch, "what is", "how is X performing", trends, history | `perfmon_get_audit_data` | | Start a NEW measurement | run, start, trigger, launch, re-run, "again", "new audit", "measure it now" | `perfmon_run_audit` | | Improve / fix a metric | improve, fix, optimize, analyze, enhance, reduce, "what's wrong with" | `perfmon_analyze_metric` | | Real-user field data only | CrUX, "real user", "field data", "real-world metrics" | `perfmon_get_crux_data` | | Export a PDF | generate, export, download, save + (PDF / report) | `perfmon_generate_report` | | Two named pages, head-to-head | compare, "versus", "vs competitor" | `perfmon_compare_page_insights` | | Three or more pages, ranked | benchmark, rank, "against each other" | `perfmon_benchmark_page_insights` | | Greeting / capability question | hi, hello, "what can this do", "how do I start" | `perfmon_introduce` | ### Tiebreakers - **Noun-only prompt** ("audit niteco.com", "performance for niteco.com") is NOT a request for a new measurement. Use `perfmon_get_audit_data`. Starting a new audit requires an explicit run / start / new / again word. - **Same metric, different verb**: "get LCP" -> `perfmon_get_audit_data`; "improve LCP" -> `perfmon_analyze_metric`. - **DEFAULT when still ambiguous -> `perfmon_get_audit_data`.** It is read-only and instant, and when no data exists it tells the user to run an audit — so guessing it is cheap, while guessing `perfmon_run_audit` wrongly costs the user a 2-3 minute run they did not ask for.

Read and display existing audit data, scores, metrics, and historical performance trends for a web page. This is the PRIMARY tool for viewing any audit results. DEFAULT TOOL: use this whenever the user asks about a page's audit, performance, score, or metrics WITHOUT explicitly asking to start a new measurement. "Audit" and "test" as NOUNS mean the stored data, not a request to make new data. ## When to Use User wants to VIEW, GET, CHECK, or SHOW audit data, scores, or metrics: - Action keywords: get, show, check, view, display, fetch, "what is", "how is performing" - Data keywords: audit, performance, webperf, SEO, accessibility, best-practices, metrics, Lighthouse, score, Core Web Vitals - Historical: trends, history, over time, past N days/months ## Do NOT use - "run / start a new audit", "audit it again", "measure it now" → `perfmon_run_audit` - "improve / fix / optimize <metric>" → `perfmon_analyze_metric` ## Inputs Provide test_id (priority) or url (fallback) when the user named a page or a test. BOTH MAY BE OMITTED: if the user asks for an audit without naming a page (e.g. "get audit for page"), call this tool with NO arguments — it answers with a setup form the user fills in. Do NOT refuse the call or ask for the URL instead of calling. Optional filters: last_n_days, last_n_months, start_date, end_date, device, location. ## Examples | User Prompt | Parameters | |---|---| | "get audit niteco.com" | url: "niteco.com" | | "get performance for niteco.com" | url: "niteco.com" | | "how is niteco.com performing" | url: "niteco.com" | | "Get audit for example.com" | url: "example.com" | | "Show trends for last 30 days" | url: "example.com", last_n_days: 30 | | "Check results for test 260127_2C_8F" | test_id: "260127_2C_8F" | | "get audit for page" (no page named) | *(no parameters)* | ## RESPONSE BEHAVIOR (VERY IMPORTANT) On success, `content[0].text` (= `structuredContent.response_instruction`) contains a <system_instruction> block. FOLLOW IT: 1. Reply BRIEFLY in your own words — the widget already shows every metric, so just point the user to it (do NOT restate the numbers). 2. Do NOT print a numbered next-step list — next steps are shown as clickable "Next suggestion" cards in the widget; the user clicks one to run it directly. 3. Do NOT call another tool after this response — wait for the user's choice. ## PENDING STATE (test_id polling) When queried by `test_id` (e.g. right after `perfmon_run_audit`) and the audit is still running, the tool returns `state: "pending"` and the widget polls automatically. Follow `content[0].text` / `structuredContent.response_instruction` as above; briefly tell the user the audit is still running (~1-2 minutes) and do NOT call this tool again yourself — the widget updates itself. `structuredContent.url` carries the audited page URL, echoed for the widget's own CrUX lookup; it may be absent, which is a normal pending response — never restate it and never treat it as an error. ## TOOL ROUTING (shared across every perfmon tool — obey before choosing) Match the user's ACTION VERB, never the data noun. "audit", "test", "report" and "score" are NOUNS naming the data; on their own they do NOT mean "make a new one". | User intent | Action verbs | Tool | |---|---|---| | View existing data / scores / history | get, show, check, view, display, fetch, "what is", "how is X performing", trends, history | `perfmon_get_audit_data` | | Start a NEW measurement | run, start, trigger, launch, re-run, "again", "new audit", "measure it now" | `perfmon_run_audit` | | Improve / fix a metric | improve, fix, optimize, analyze, enhance, reduce, "what's wrong with" | `perfmon_analyze_metric` | | Real-user field data only | CrUX, "real user", "field data", "real-world metrics" | `perfmon_get_crux_data` | | Export a PDF | generate, export, download, save + (PDF / report) | `perfmon_generate_report` | | Two named pages, head-to-head | compare, "versus", "vs competitor" | `perfmon_compare_page_insights` | | Three or more pages, ranked | benchmark, rank, "against each other" | `perfmon_benchmark_page_insights` | | Greeting / capability question | hi, hello, "what can this do", "how do I start" | `perfmon_introduce` | ### Tiebreakers - **Noun-only prompt** ("audit niteco.com", "performance for niteco.com") is NOT a request for a new measurement. Use `perfmon_get_audit_data`. Starting a new audit requires an explicit run / start / new / again word. - **Same metric, different verb**: "get LCP" -> `perfmon_get_audit_data`; "improve LCP" -> `perfmon_analyze_metric`. - **DEFAULT when still ambiguous -> `perfmon_get_audit_data`.** It is read-only and instant, and when no data exists it tells the user to run an audit — so guessing it is cheap, while guessing `perfmon_run_audit` wrongly costs the user a 2-3 minute run they did not ask for.

Get Chrome User Experience Report (CrUX) real-world performance data for a URL. Shows Core Web Vitals from actual user visits (field data, not lab data). ## When to Use User asks for real-world / field / CrUX performance data: - Keywords: CrUX, "real user", "field data", "Chrome User Experience", "real-world metrics" - Requires an explicit field-data signal — a plain "performance" question is NOT this tool. ## Do NOT use - "get / show performance|audit|scores for X" (lab data + CrUX together) → `perfmon_get_audit_data`, which already returns CrUX inside its payload. Only use THIS tool for a CrUX-only request. - "run / start a new audit" → `perfmon_run_audit` ## Inputs - url (REQUIRED): Full URL with protocol (e.g., "https://niteco.com") - is_desktop (optional, default: true): Desktop or Mobile data ## Result - If data exists: CrUX metrics for both URL and origin level. - If no data: URL may have low traffic or be too new. ## Example - "Get CrUX data for https://niteco.com" → url: "https://niteco.com" ## RESPONSE BEHAVIOR (VERY IMPORTANT) On success, `content[0].text` (= `structuredContent.response_instruction`) contains a <system_instruction> block. FOLLOW IT: 1. Reply BRIEFLY in your own words — the widget already shows every CrUX metric (URL + origin p75), so just point the user to it (do NOT restate the p75 numbers). 2. Do NOT print a numbered next-step list — next steps are shown as clickable cards in the widget; the user clicks one to run it. 3. Do NOT call another tool after this response — wait for the user's choice. ## TOOL ROUTING (shared across every perfmon tool — obey before choosing) Match the user's ACTION VERB, never the data noun. "audit", "test", "report" and "score" are NOUNS naming the data; on their own they do NOT mean "make a new one". | User intent | Action verbs | Tool | |---|---|---| | View existing data / scores / history | get, show, check, view, display, fetch, "what is", "how is X performing", trends, history | `perfmon_get_audit_data` | | Start a NEW measurement | run, start, trigger, launch, re-run, "again", "new audit", "measure it now" | `perfmon_run_audit` | | Improve / fix a metric | improve, fix, optimize, analyze, enhance, reduce, "what's wrong with" | `perfmon_analyze_metric` | | Real-user field data only | CrUX, "real user", "field data", "real-world metrics" | `perfmon_get_crux_data` | | Export a PDF | generate, export, download, save + (PDF / report) | `perfmon_generate_report` | | Two named pages, head-to-head | compare, "versus", "vs competitor" | `perfmon_compare_page_insights` | | Three or more pages, ranked | benchmark, rank, "against each other" | `perfmon_benchmark_page_insights` | | Greeting / capability question | hi, hello, "what can this do", "how do I start" | `perfmon_introduce` | ### Tiebreakers - **Noun-only prompt** ("audit niteco.com", "performance for niteco.com") is NOT a request for a new measurement. Use `perfmon_get_audit_data`. Starting a new audit requires an explicit run / start / new / again word. - **Same metric, different verb**: "get LCP" -> `perfmon_get_audit_data`; "improve LCP" -> `perfmon_analyze_metric`. - **DEFAULT when still ambiguous -> `perfmon_get_audit_data`.** It is read-only and instant, and when no data exists it tells the user to run an audit — so guessing it is cheap, while guessing `perfmon_run_audit` wrongly costs the user a 2-3 minute run they did not ask for.

Introduce the Niteco Web Performance Insights app and how to get started. ## When to Use - The user greets the assistant ("hi", "hello") or opens the connector with no request - The user asks what this app / connector can do, for a feature overview, or how to start - NO other tool matches and the user has not asked about a specific page, metric, or audit ## Do NOT use - The user named a page, URL, metric, or audit → route by the matrix below (an ambiguous data question defaults to `perfmon_get_audit_data`, never to this tool) ## Inputs - None. ## Result For UI-capable clients: a widget with a welcome banner and the app's 6 capabilities as clickable "Next suggestion" cards. For text-only clients: a text-only introduction plus a numbered quick-start list. No page data, no follow-up form either way. ## RESPONSE BEHAVIOR (VERY IMPORTANT) `content[0].text` (= `structuredContent.response_instruction`) contains a <system_instruction> block. FOLLOW IT: - UI-capable clients: reply with ONE short, warm sentence inviting the user to pick a capability from the widget above — do NOT list, number, or describe the capabilities (the cards already show them). - Text-only clients: present the introduction VERBATIM (keep every emoji, line break, and the numbered quick-start list), add no extra commentary. Either way, do NOT call another tool — wait for the user to choose what to do next. ## TOOL ROUTING (shared across every perfmon tool — obey before choosing) Match the user's ACTION VERB, never the data noun. "audit", "test", "report" and "score" are NOUNS naming the data; on their own they do NOT mean "make a new one". | User intent | Action verbs | Tool | |---|---|---| | View existing data / scores / history | get, show, check, view, display, fetch, "what is", "how is X performing", trends, history | `perfmon_get_audit_data` | | Start a NEW measurement | run, start, trigger, launch, re-run, "again", "new audit", "measure it now" | `perfmon_run_audit` | | Improve / fix a metric | improve, fix, optimize, analyze, enhance, reduce, "what's wrong with" | `perfmon_analyze_metric` | | Real-user field data only | CrUX, "real user", "field data", "real-world metrics" | `perfmon_get_crux_data` | | Export a PDF | generate, export, download, save + (PDF / report) | `perfmon_generate_report` | | Two named pages, head-to-head | compare, "versus", "vs competitor" | `perfmon_compare_page_insights` | | Three or more pages, ranked | benchmark, rank, "against each other" | `perfmon_benchmark_page_insights` | | Greeting / capability question | hi, hello, "what can this do", "how do I start" | `perfmon_introduce` | ### Tiebreakers - **Noun-only prompt** ("audit niteco.com", "performance for niteco.com") is NOT a request for a new measurement. Use `perfmon_get_audit_data`. Starting a new audit requires an explicit run / start / new / again word. - **Same metric, different verb**: "get LCP" -> `perfmon_get_audit_data`; "improve LCP" -> `perfmon_analyze_metric`. - **DEFAULT when still ambiguous -> `perfmon_get_audit_data`.** It is read-only and instant, and when no data exists it tells the user to run an audit — so guessing it is cheap, while guessing `perfmon_run_audit` wrongly costs the user a 2-3 minute run they did not ask for.

Start a NEW Lighthouse measurement of a web page. This tool MEASURES a page; it does not read results that already exist. ## When to Use The user explicitly asks to START a measurement. Requires one of these signals: - Verbs: run, start, trigger, launch, re-run, rerun, remeasure - Phrases: "new audit", "another audit", "audit it again", "test it again", "measure it now" ## Do NOT use - "get / show / check / view audit|performance|score|metrics for X" -> `perfmon_get_audit_data` - "improve / fix / optimize X" -> `perfmon_analyze_metric` - A prompt naming "audit" or "test" as a NOUN with no run verb -> `perfmon_get_audit_data` ## Inputs - url (REQUIRED): Page URL to audit (e.g., "niteco.com" or "https://niteco.com") - device (optional): "Desktop" or "Mobile" - location (optional): Test location (e.g., "Hanoi", "Singapore") ## Workflow - All parameters provided → Execute immediately - Missing device/location → Display form for user to select ## Result Returns test ID for tracking. Audit takes ~2-3 minutes to complete. ## Examples - "Run a NEW audit for niteco.com" → url: "niteco.com" (shows form) - "Audit niteco.com again" → url: "niteco.com" (shows form) - "Run mobile audit for niteco.com in Hanoi" → url: "niteco.com", device: "Mobile", location: "Hanoi" ## RESPONSE BEHAVIOR (VERY IMPORTANT) On success, `content[0].text` (= `structuredContent.response_instruction`) contains a <system_instruction> block. FOLLOW IT: 1. Reply BRIEFLY in your own words — the widget already tracks the audit progress, so just confirm the audit started and point the user to it (do NOT restate the details). 2. Do NOT print a numbered next-step list — the next step is shown as a clickable "Next suggestion" card in the widget; the user clicks it to view the results. 3. Do NOT call another tool after this response — the audit runs asynchronously (~2-3 minutes); wait for the user to ask for results. ## TOOL ROUTING (shared across every perfmon tool — obey before choosing) Match the user's ACTION VERB, never the data noun. "audit", "test", "report" and "score" are NOUNS naming the data; on their own they do NOT mean "make a new one". | User intent | Action verbs | Tool | |---|---|---| | View existing data / scores / history | get, show, check, view, display, fetch, "what is", "how is X performing", trends, history | `perfmon_get_audit_data` | | Start a NEW measurement | run, start, trigger, launch, re-run, "again", "new audit", "measure it now" | `perfmon_run_audit` | | Improve / fix a metric | improve, fix, optimize, analyze, enhance, reduce, "what's wrong with" | `perfmon_analyze_metric` | | Real-user field data only | CrUX, "real user", "field data", "real-world metrics" | `perfmon_get_crux_data` | | Export a PDF | generate, export, download, save + (PDF / report) | `perfmon_generate_report` | | Two named pages, head-to-head | compare, "versus", "vs competitor" | `perfmon_compare_page_insights` | | Three or more pages, ranked | benchmark, rank, "against each other" | `perfmon_benchmark_page_insights` | | Greeting / capability question | hi, hello, "what can this do", "how do I start" | `perfmon_introduce` | ### Tiebreakers - **Noun-only prompt** ("audit niteco.com", "performance for niteco.com") is NOT a request for a new measurement. Use `perfmon_get_audit_data`. Starting a new audit requires an explicit run / start / new / again word. - **Same metric, different verb**: "get LCP" -> `perfmon_get_audit_data`; "improve LCP" -> `perfmon_analyze_metric`. - **DEFAULT when still ambiguous -> `perfmon_get_audit_data`.** It is read-only and instant, and when no data exists it tells the user to run an audit — so guessing it is cheap, while guessing `perfmon_run_audit` wrongly costs the user a 2-3 minute run they did not ask for.