Quanti IA

Récupère la spec ET les queries ACTUELLES d'un dashboard. À appeler AVANT update_dashboard : lis la spec, modifie-la, renvoie la version complète.

get_dashboard

Retrieves the full context of a Quanti launch session. The user has pre-configured an analysis from the Quanti interface and was redirected here with a launch_id. Call this function to get the analysis details to execute (name, prompt or SQL template, project).

get_launch_context

Gets the full context of a project: active connectors with their datasets, visual branding, and business context (about both the client organization and the user querying the MCP). Use the folderId obtained from list_projects. Always call this tool before answering analytical questions or generating a report. **Response structure:** - `connectors`: active data sources with sku, dataset, last_sync, tables_count. May also carry `description`/`purpose` (account-level business notes) and, for custom connectors, `domains` (the business domains its tables cover, e.g. "CRM / Clients", "Ventes / E-commerce") and `tables` (client-defined table names). Use `domains`/`tables` to route to the right connector BEFORE calling get_schema_context — they tell you what an opaquely-named custom dataset actually contains. - `branding` (optional): visual identity (logo_url, primary_color, secondary_color, tertiary_color, font_family) — apply it when generating reports. - `organization` (optional): semantic info about the client company filled in by them during onboarding — `presentation` (what the company does), `industry` (sector), `culture` (working style). Use it to adapt tone, vocabulary, and analytical priorities. - `user` (optional): info about the human querying the MCP — `service` (department), `mission` (their role's objective), `role` (job title). Use it to tailor responses to their job context. Not present when authenticated via API key. - `context_summary` (optional): a ready-to-inject markdown summary of organization + user. Useful as a system prompt prefix. **Important:** `organization`, `user`, and `context_summary` are soft hints — they are absent for projects where the client hasn't completed the onboarding wizard. Treat their content as guidance, never as constraints.

get_project_context

Step 1 of schema discovery: returns the catalog of tables relevant to the user's question. Each table comes with its dataset, business name, dw_table_name and a short description — but NOT the field-level details (no columns, no types, no semantic codes). Use the catalog to identify the most promising candidate(s), then call **get_table_schema** to fetch the full structure of a specific table before writing SQL. **IMPORTANT for SQL queries**: Use ONLY the `dataset.table` format (e.g., `prod_google_ads_v2.campaign_stats`). NEVER prefix with a project_id.

get_schema_context

Step 2 of schema discovery: returns the full structure of a single table — fields with types, semantic codes, business names, and the semantic definitions referenced by those codes. Call this AFTER get_schema_context once you've picked a candidate table. Returns: dw_table_name (use this in SQL), description, fields[], semantic_definitions{} keyed by code.

get_table_schema

Invite une personne (par email) à consulter un dashboard. Réservé à l'owner. L'invité reçoit un email d'invitation et voit aussi l'invitation sur sa home Quanti. Utilise list_dashboards pour trouver l'id.

invite_to_dashboard

Lists aggregation views (materialized views and procedures) created for a project. **When to use this tool:** - When the user asks "what views exist?", "my aggregations", "my materialized views" - Before creating a new view to check it doesn't already exist - To get the view ID for deletion **Response format:** Returns a JSON array with each view's ID, full_name (dataset.name), type, SQL, description, and creation date.

list_aggregation_views

Liste les templates (chartes graphiques) EXISTANTS du projet (slug, nom, is_default + spec couleurs/typo). ⚠️ APPELLE-LE AVANT toute création OU modification graphique : réutilise un template existant (référence son slug dans create_dashboard) ou modifie-le (update_template) — ne crée un nouveau template (create_template) QUE si la liste est vide.

list_templates

Liste les dashboards d'un projet auxquels l'utilisateur a accès (id, titre, url). À utiliser pour retrouver un dashboard à modifier.

list_dashboards

Lists your personal use cases (scope: member). **What is a use case?** A use case is a reusable analysis you created or saved. It contains a business description and optionally a SQL template. **When to use this tool:** - When the user asks for "my analyses", "my use cases", "what I saved" - Before creating a new use case to check it doesn't already exist - To find the ID of a use case to modify or delete **Visibility**: These use cases are private and only visible to you.

list_my_use_cases

Lists pre-configured reports (prebuilds) available for a connector. **What is a prebuild?** A prebuild is a standardized report maintained by Quanti for a given connector (e.g., Campaign Stats for Google Ads). It defines the BigQuery table structure (columns, types, metrics) and the associated API query. For a REVERSE connector, there is no report and no table: the templates are outbound push contracts (which fields the third-party API expects). The response shape differs accordingly — see Response format below. **When to use this tool:** - When the user asks "what reports are available for [connector]?" - When the user doesn't know which data or metrics exist for a connector - BEFORE get_schema_context, to explore available reports for a connector - To understand the data structure before writing SQL **Difference with get_schema_context:** - list_prebuilds → discover which reports/tables EXIST for a connector (catalog) - get_schema_context → get the actual BigQuery schema for the client project (effective data) **Response format — TWO possible shapes, check which one you got:** 1. Inbound connectors (the usual case) → key **"prebuilds"**. For each: ID, name, description, BigQuery table name, and fields (name, type, description, is_metric). Fields with is_metric=true are aggregatable metrics (impressions, clicks, cost...), the others are dimensions (date, campaign_name...). These tables exist in the warehouse: you can write SQL against them. 2. Reverse connectors (SKU starting with "reverse-", e.g. reverse-googleads, reverse-meta) → key **"pushes"** and kind="reverse_pushes". These connectors SEND data OUT to a third-party platform (Google Ads, Meta...). Each push lists the destination fields to be FED, with: field_id, type, required, is_primary_key, and the transforms Quanti applies (auto_hash for PII hashed in SHA256, auto_normalize_phone for E.164). ⚠️ These field_id are NOT warehouse columns — no table exists behind them. Never write SQL against them. Use them to answer "what do I need to provide to feed this destination?", to help build the source table, or to explain a mapping. The mapping itself (destination field → source column) is configured in the connector's Mapping tab. **SKU examples**: googleads, meta, tiktok, tiktok-organic, amazon-ads, amazon-dsp, piano, shopify-v2, microsoftads, prestashop-api, mailchimp, kwanko — and for reverse: reverse-googleads, reverse-meta, reverse-meta-pixel, reverse-tiktok, reverse-amazonads, reverse-adobe

list_prebuilds

Lists use cases shared with the project team (scope: project). **When to use this tool:** - When the user asks for "team analyses", "project use cases" - To see what colleagues have shared - Before sharing a new use case to avoid duplicates **Visibility**: These use cases are visible to all project members.

list_project_use_cases

Lists all projects accessible by the user. Call this function first to discover available projects.

list_projects

Lists scheduled queries configured in the project's BigQuery. **What is a scheduled query?** A scheduled query is a SQL query automatically executed on a defined schedule in BigQuery. It is used to aggregate data, populate reporting tables, or perform recurring transformations. **When to use this tool:** - When the user EXPLICITLY asks about scheduled queries, BigQuery pipelines, or transfer configs - When the user asks "what are my scheduled queries?", "my BigQuery pipelines" - To check execution frequency or status of a specific scheduled query **Do NOT use this tool** for general data queries, analytics, or when the user asks about page views, metrics, or data from connectors. Use get_schema_context + execute_query instead. **Available filters:** - dataset: filter by destination dataset (e.g., 'prod_reports') - status: filter by status 'active' (enabled) or 'disabled' **Response format:** Returns a JSON with for each scheduled query: its name, SQL query, execution schedule, destination dataset, status (active/disabled), and last/next execution dates.

list_scheduled_queries

Re-runs a Marketing Mix Modeling study previously configured with setup_mmm. **Important:** Do NOT call this right after setup_mmm. The first run is automatically triggered by setup_mmm. Use run_mmm only to re-launch an existing study later (e.g., after data refresh or parameter changes). **Prerequisite:** Must have called setup_mmm first to obtain an account_id. **Duration:** The Meridian fit (MCMC) takes approximately 10-30 minutes depending on data volume. The user will receive an email when results are ready. **Results:** Results are written to the project's data warehouse (mmm_channel_summary and mmm_weekly_contributions tables). They can then be queried via execute_query.

run_mmm

Searches the official Quanti documentation (docs.quanti.io) to answer questions about using the platform. **When to use this tool:** - When the user asks "how to do X in Quanti?", "what is a connector?", "how to configure BigQuery?" - When the user needs help configuring or using a connector (Google Ads, Meta, Piano, etc.) - To explain Quanti concepts: projects, connectors, prebuilds, data warehouse, tag tracker, transformations - When the user asks about the Quanti MCP (setup, overview, semantic layer) **This tool does NOT replace:** - get_schema_context: to get the actual BigQuery schema for a client project - list_prebuilds: to list pre-configured reports for a connector - get_use_cases: to find reusable analyses - execute_query: to execute SQL **Available topic filters:** connectors, data-warehouses, data-management, tag-tracker, mcp-server, transformations

get_help

Searches for relevant use cases to answer the user's question. Use cases contain SQL templates and business definitions. Use this function to discover available analyses.

get_use_cases

Configures a Marketing Mix Modeling (MMM) study for a project. **What is MMM?** Marketing Mix Modeling measures the real contribution of each marketing channel (Google Ads, Meta, etc.) on a KPI (leads, revenue, conversions), accounting for external factors (seasonality, holidays, promotions). **Recommended workflow:** 1. Use get_schema_context to discover the project's tables/columns 2. Generate input SQL queries (KPI, channels, exogenous variables) 3. **Validate each query before calling setup_mmm:** Use execute_query to run a COUNT(*) wrapper on each input query (e.g., SELECT COUNT(*) FROM (<query>)). If any query returns 0 rows, do NOT include it in setup_mmm — warn the user that the data source is empty and ask whether to proceed without it or fix the query. 4. Call setup_mmm with the validated SQL queries — the study is automatically launched after setup 5. Do NOT call run_mmm after setup_mmm: the first run is triggered automatically **Important:** run_mmm is only needed to RE-RUN an existing study later, not after initial setup. **Input queries format:** Each query must return a "time" column (DATE) and the requested metrics. - role="kpi": a "kpi" column (the target KPI) - role="channel": "spend" and "impressions" columns + channel_name - role="exogenous": columns named after the exogenous variables + columns[] **Granularity**: "weekly" is recommended (MMM standard). SQL should aggregate by week. **Important**: Adapt the SQL dialect to the project's data warehouse type (BigQuery, Snowflake, Redshift).

setup_mmm

Modifie un dashboard EXISTANT (garde son id/url/partage) au lieu d'en créer un nouveau. Remplace la spec (et title/template/queries si fournis). Réservé à l'owner/editor. Workflow : get_dashboard → modifier la spec → update_dashboard avec la spec complète + les queries. N'émets JAMAIS de HTML.

update_dashboard

Met à jour la charte (couleurs, typo, logo, header/footer) d'un template EXISTANT, identifié par son slug. À utiliser pour TOUTE modification graphique d'un dashboard : modifie le template en cours (le slug référencé par le dashboard, lu via get_dashboard → spec.template), ne crée PAS un nouveau template. Tous les dashboards qui utilisent ce template récupèrent la nouvelle charte. Fournis la spec COMPLÈTE du template (même format que create_template).

update_template

Updates an existing use case that you created. **When to use this tool:** - To improve the description or SQL of an existing use case - To fix an error in a use case - To change a use case's category **Permissions:** You can only modify use cases you created. **Tip:** Use list_my_use_cases or list_project_use_cases first to get the use case ID.

update_use_case