docs: note parameter support in data apps

guides/data-apps.mdx

@@ -142,6 +142,18 @@ This means:
 - **The agent generates code, not data.** When the app is being built, Claude sees your dbt model catalog (tables, dimensions, metrics) and any context you attach to the prompt. It writes queries against your semantic layer; it does not get a dump of your warehouse.
 - **The agent can see anything you attach.** Charts, dashboards, images, and sample data you include in the prompt are passed to the agent as context. Don't include data you wouldn't be comfortable sending to the model.
 
+## Parameters in data apps
+
+Data apps can drive [Lightdash parameters](/guides/developer/using-parameters) from interactive controls inside the app — a dropdown that switches a KPI between `total_revenue` and `won_revenue`, a region selector that re-runs queries scoped to a chosen market, or a comparison-mode toggle that swaps a year-over-year window between `YTD` and `Last 12 months`.
+
+Parameters change the SQL itself (via `${lightdash.parameters.X}` substitutions), so they're the right tool when you want one chart to show different things — not just fewer rows. When you only want to restrict which rows are scanned, use a filter instead.
+
+Prompt the agent when you want parameters in the app. For example:
+
+> Add a dropdown that lets the user pick a KPI (Total revenue, Won revenue, Deal count, Win rate). Wire it up to the `kpi_selector` parameter on the `deals` model so the headline number re-runs when the selection changes.
+
+The agent only uses parameters that are declared in your dbt YAML or `lightdash.config.yml`. If a parameter doesn't exist, ask your data team to add it — see [How to use parameters](/guides/developer/using-parameters) for the YAML syntax.
+
 ## Best practices
 
 - **Iterate.** Most apps get substantially better after a few rounds of iteration. Start with the rough shape, then refine.