Update to Ingest Labs

{
  "description": "Answer IngestLabs Insights / analytics questions via the ingestlabs MCP tools against production (mcp.ingestlabs.com): list_vendors, list_projects, list_insights_contexts, get_insights_schema, execute_insights_query, create_mdp_ai_report_from_insights, list_mdp_ai_reports, get_mdp_ai_report, execute_mdp_ai_report, update_mdp_ai_report_from_insights. Use for production dashboards, reports, attribution, KPIs, IDL/CDP/media_tags metrics, and MDP AI report lifecycle.",
  "included_files": [
    {
      "relative_path": "examples.md",
      "size_in_bytes": 7372
    }
  ],
  "name": "ingestlabs",
  "skill_md_contents": "---\nname: ingestlabs\ndescription: >-\n  Answer IngestLabs Insights / analytics questions via the ingestlabs MCP\n  tools against production (mcp.ingestlabs.com): list_vendors, list_projects,\n  list_insights_contexts, get_insights_schema, execute_insights_query,\n  create_mdp_ai_report_from_insights, list_mdp_ai_reports, get_mdp_ai_report,\n  execute_mdp_ai_report, update_mdp_ai_report_from_insights. Use for production\n  dashboards, reports, attribution, KPIs, IDL/CDP/media_tags metrics, and MDP AI\n  report lifecycle.\n---\n\n# IngestLabs Insights (MCP) — Prod\n\nHost LLM maps natural language → Insights schema ids (dimensions/metrics). MCP only discovers schema and executes.\n**Environment: production** (`https://mcp.ingestlabs.com`).\n\n## Prerequisites\n\n1. MCP server **ingestlabs** connected (Streamable HTTP).\n2. Production API:\n\n```json\n\"ingestlabs\": {\n  \"type\": \"http\",\n  \"url\": \"https://mcp.ingestlabs.com/v1/mcp\"\n}\n```\n\n3. Complete OAuth (portal login) when your MCP client prompts. Endpoint is `/v1/mcp` (not `/mcp`).\n\nIf the server is connected but tools fail, follow [SETUP.md](../../SETUP.md).\n\n## Scope (must resolve before analytics or config tools)\n\nResolve `vendor_id` (and `project_id` when needed) **before** calling Insights or Tag Manager tools.\n\n1. **Organization / vendor**\n   - If the user did not name an organization (or only used a nickname with more than one match): call **`list_vendors`**, present name + `vendor_id`, and **ask which org** to use.\n   - Auto-pick only when the user has **exactly one** vendor, or the same vendor was already confirmed earlier in this conversation.\n   - Never invent `vendor_id`. Never reuse example placeholders or another customer’s id.\n2. **Project** (Tag Manager tools, or product `media_tags`)\n   - If project is missing or ambiguous: call **`list_projects`** with the resolved `vendor_id`, present choices, and ask.\n   - Do not call `execute_insights_query` for `media_tags` without `project_id`.\n3. Keep the chosen scope for the rest of the thread unless the user switches org/project.\n\n## Product and context routing\n\n```\nproduct: idl | cdp | media_tags\n```\n\n| Product | Notes |\n| --- | --- |\n| `idl` / `cdp` | Vendor-scoped; `project_id` usually not required |\n| `media_tags` | **`project_id` required** |\n\nWhen picking a context after `list_insights_contexts`, prefer match on **keywords / description** over name alone.\nUse the **`context_id` returned by the tool** (do not invent ids). Common MCP catalog ids:\n\n| User topic | Product | Prefer context id / keywords |\n| --- | --- | --- |\n| Attribution, MTA, channel revenue, UTM credit (touchpoint grain) | `idl` | `mcp_attribution_touchpoints` |\n| Conversion / order list with first+last touch UTMs (txn grain) | `idl` | `mcp_mdp_attributed_transactions` |\n| One-shot touchpoint + Shopify/ads/session mega-merge (legacy) | `idl` | `mcp_mdp_attribution_journey` — prefer ATP/mat_txn + enrichments instead when possible |\n| Meta / Facebook ads, ROAS, ad sets | `idl` | `mcp_facebook_ads` |\n| Google Ads, Search, Shopping, PMax | `idl` | `mcp_google_ads` |\n| TikTok ads | `idl` | `mcp_tiktok_ads` |\n| Shopify orders / customers | `idl` | `mcp_shopify_orders` / `mcp_shopify_customers` |\n| GA4 daily property metrics (users, sessions) | `idl` | `mcp_ga4_metrics_daily` |\n| GA4 source / medium / channel | `idl` | `mcp_ga4_traffic_source` |\n| GA4 landing pages | `idl` | `mcp_ga4_landing_pages` |\n| Site events, sessions, ATC, checkout (IL) | `idl` | `mcp_sessionized_events` |\n| Item / SKU events | `idl` | `mcp_events_il_items` |\n| SaaS / product event metrics | `idl` | `mcp_events_saas_metrics` |\n| Traffic quality, bots, invalid traffic (TQS) | `idl` | `mcp_ingest_id_v2_tqs` |\n| Tag fire aggregates | `media_tags` | `mcp_il_trino_tag_records` |\n| Raw tag recorded events | `media_tags` | `mcp_il_tag_recorded_events` |\n\n**Ambiguity rules**\n\n- Ads without platform → ask Meta vs Google vs TikTok (or list contexts and let the user choose).\n- “Sessions / traffic” → distinguish GA4 bridge contexts vs IL sessionized events vs tag fires.\n- “Revenue” by channel/journey → attribution context; do not treat ads **spend** as revenue.\n- Attribution rows fan out (N touchpoints per conversion); use weighted attribution metrics as schema documents, do not naive-sum raw touchpoint rows as orders.\n- Transaction list with FT/LT UTMs → `mcp_mdp_attributed_transactions`, not touchpoint grain.\n- Prefer **primary grain + curated enrichments** over `mcp_mdp_attribution_journey` when the question spans domains (see Cross-context joins). Journey still works for deep ads hierarchy in one shot until enrichment-intra walks are universal.\n- If two contexts still look equally valid → show both and ask; do not guess.\n\n## Mandatory Insights workflow\n\nAlways after scope is resolved, in this order:\n\n1. **`list_insights_contexts`** — pick primary `context_id` (defines **row grain**) from name / description / keywords\n2. **`get_insights_schema`** — map NL fields to dimension/metric **ids**; read **`joinable_contexts`**. Classifications default to `{ id, mapping_count }`; pass **`include_classifications: true`** only when enum from→to mappings are needed.\n3. If the question needs columns from another domain listed in `joinable_contexts`: call **`get_insights_schema` again** with `include_context_ids` (max 3) to merge those dims/metrics\n4. **`execute_insights_query`** — primary `context_id` + optional **`enrichment_context_ids`** (same ids as include) + field ids from the merged schema\n\nDo not invent dimension or metric ids. Do not invent join keys or enrichment contexts. Do not skip schema when unsure.\nYou may reuse a `context_id` and field ids already loaded in this session when the topic is unchanged; re-list when the domain changes.\n\n## Cross-context joins (curated)\n\nSome primaries allow **left-join enrichments** from an allowlisted registry (not free joins).\n\n| Concept | Meaning |\n| --- | --- |\n| Primary `context_id` | Owns row grain and date window |\n| `joinable_contexts` | From `get_insights_schema` — which contexts may be enriched, with `join_summary` / `edge_id`. Includes **transitive** hops (e.g. attributed txns → Shopify orders → customers) with `hop_count`, `via_context_ids`, `join_path`. |\n| `include_context_ids` | Schema-only: merge enrichment dims/metrics into the schema response (max 3). May include transitive targets listed in `joinable_contexts`. |\n| `enrichment_context_ids` | Execute/report: actually left-join those contexts (must appear in `joinable_contexts`; intermediates are resolved automatically) |\n\n**Rules**\n\n- Only enrich contexts returned in `joinable_contexts` for that primary. Never invent edges.\n- Date filters apply to the **primary** only; enrichments are left joins (nulls when unmatched).\n- Typical compositions: `mcp_mdp_attributed_transactions` or `mcp_attribution_touchpoints` + `mcp_shopify_orders` (+ **`mcp_shopify_customers` via SO→SC**), sessionized, item events, or ads **campaign** contexts.\n- Deeper ads hierarchy (adset/ad) after campaign enrichment may still require the ads context alone or journey until the planner walks enrichment intra-relationships.\n- When saving an MDP AI report after an enriched execute, pass the same **`enrichment_context_ids`** (and field ids) as the execute — not dates/limit.\n- Select supports up to **40** dimensions+metrics (raised for export-style purchase lists).\n\n## Execute rules\n\n- Prefer **`date_preset`**: `today` | `yesterday` | `last_7d` | `last_30d` (vendor timezone).\n- Or both **`from`** and **`to`** as epoch seconds GMT — never mix with `date_preset`.\n- If `is_date_filter_optional` is false, dates are required.\n- Use schema **ids** in `dimensions`, `metrics[].id`, `filters[].field`, `sort[].field`.\n- For a dimension with `dim_typ: dt`, include `interval_suffix`: `m` | `h` | `d` | `w`.\n- Obey each dimension's `is_mandatory` mode (`FILTER`, `SELECT`, or `FILTER_AND_SELECT`).\n- Filter only dimensions with `filterable: true` (metrics are not filterable in execute); operators are case-insensitive and `CONTAINS` aliases `CONTAINS_IN`.\n- `metrics[].aggregate_fn` is case-insensitive and optional for defaulted or `COMPUTED` metrics; ignore aggregate_fn on bare `COMPUTED` metrics.\n- Prefer a small `limit` for exploration (e.g. 10–25); default 100, max 500. Prefer metric-only queries when the user wants one number. If `truncated: true` (or `total_count` > `row_count`), say so and offer a tighter filter or higher limit.\n- Need at least one dimension or metric.\n\n## Save as MDP AI Report\n\nAfter a successful **`execute_insights_query`**, the user may ask to save the query as a durable MDP AI report. Call **`create_mdp_ai_report_from_insights`** only when:\n\n1. Scope is resolved (`vendor_id`, and `project_id` when `product` is `media_tags`).\n2. You have already run **`execute_insights_query`** in this conversation and shown results.\n3. The user **explicitly confirms** they want to save (report **name**; optional description/timing).\n\n### Save workflow\n\n1. Confirm with the user: report **name**, optional **description**, optional **start_timing** / **end_timing** for default run windows. Do **not** ask about `can_be_audience` — default it to `false` (omit the field, or pass `false`). Only set `true` if the user explicitly asks for audience eligibility.\n2. Reuse the **same** `vendor_id`, `product`, `project_id` (if any), `context_id`, `enrichment_context_ids` (if any), `dimensions`, `metrics`, `filters`, `sort`, and `interval_suffix` as the last successful execute — **not** `date_preset`, `from`/`to`, or `limit` (those are execution-only).\n3. Call **`create_mdp_ai_report_from_insights`**.\n4. In the chat response, show only **Report ID** (`report_id`) and **Report URL** (`portal_url` as a clickable link). Do **not** display `creation_source` (or raw field names like `report_id` / `portal_url`). Optionally mention the report name in the opening line.\n\nDo not call save before execute. Do not invent field ids — reuse ids from the prior execute (via schema). Do not save without user confirmation.\n\n### Tool parameters\n\n| Field | Required | Notes |\n| --- | --- | --- |\n| `vendor_id` | Yes | Confirmed org id |\n| `product` | Yes | `idl` \\| `cdp` \\| `media_tags` |\n| `project_id` | When `media_tags` | Same as execute |\n| `context_id` | Yes | Same as execute |\n| `name` | Yes | Report display name |\n| `can_be_audience` | No | Default `false`. Do **not** ask — only set `true` if the user explicitly requests audience use |\n| `description` | No | Optional |\n| `dimensions` | No* | Same ids as execute |\n| `metrics` | No* | Same ids + optional `aggregate_fn` as execute |\n| `filters` | No | Same as execute (baked into compiled SQL) |\n| `sort` | No | Same as execute |\n| `interval_suffix` | When date dim | `m` \\| `h` \\| `d` \\| `w` — same as execute |\n| `start_timing` | No | Optional relative window start (`qty`, `unit`, `reset`) |\n| `end_timing` | No | Optional relative window end (`qty`, `unit`, `reset`) |\n\n\\*At least one dimension or metric (same rule as execute).\n\n**Not accepted:** `from`, `to`, `date_preset`, `limit`. Saved reports use relative `start_timing` / `end_timing` (when set) for portal runs, not the exploration date range.\n\n## Manage MDP AI Reports\n\nAfter reports exist, use these tools (same vendor scope rules as Insights):\n\n| Tool | When |\n| --- | --- |\n| `list_mdp_ai_reports` | Discover reports. **Required** `scope`: `CUSTOM` or `PREBUILT`. For AI-saved reports prefer `scope=CUSTOM` + `creation_source=MCP`. Optional `search`, `offset`, `limit` (max 100). |\n| `get_mdp_ai_report` | Inspect metadata, `idl_query_request` (with context name/description), timings, column map. SQL omitted unless `include_sql: true` (debugging only). |\n| `execute_mdp_ai_report` | Run saved SQL for a date range. Same date rules as Insights: `date_preset` **or** both `from`+`to`. Default `limit` 100, max 500. Does not change the stored definition. |\n| `update_mdp_ai_report_from_insights` | Recompile an **MCP** report’s query from a new Insights shape. Same confirm + prior successful `execute_insights_query` rules as create. Only `creation_source=MCP` reports. |\n\n### Update workflow\n\n1. User confirms they want to change an existing MCP report (and which `report_id`).\n2. Run **`execute_insights_query`** with the new fields and show results.\n3. Call **`update_mdp_ai_report_from_insights`** with the same field ids (no dates/limit) plus `report_id`.\n4. In the chat response, show only **Report ID** and **Report URL** (same rules as create). Do **not** display `creation_source`.\n\nDo not update AI_CHAT / Thinkr reports via this tool. Do not pass client SQL.\n\n### Portal behavior (MCP-created reports)\n\nReports saved via MCP have `creation_source: 'MCP'`. In the portal MDP Reports UI they support **view, run, export, delivery, and metadata/timing configuration**:\n\n- **Read-only query definition** in the portal — use **`update_mdp_ai_report_from_insights`** to change fields via MCP.\n- **Metadata edits** — name, description, audience flag, and timing can also be updated in the portal without changing SQL.\n\n## Answering\n\n- Lead with the number/table the user asked for.\n- Cite **org name + vendor_id**, product, `context_id`, date range (`from`/`to` or preset), and that data is from **production**.\n- On tool errors: fix args (ids, dates, `project_id`, scope) and retry once; then report the error.\n\n## Tag Manager tools\n\n- Hierarchy: vendor → project → providers / tags / data elements.\n- List/get before create/update. Mutate only on **explicit** user request.\n- Confirm project when the user named only the org.\n\n## Out of scope\n\n- Raw SQL / Thinkr nl2sql\n- Editing AI_CHAT report queries via MCP (Thinkr/portal owns those)\n- Widget or dashboard CRUD\n- `internal` Insights contexts\n- Site performance / Lighthouse contexts (no `site_performance` product on these tools yet)\n- Staging or local MCP environments (this plugin is production only)\n\n## Examples\n\nSee [examples.md](examples.md).\n"
}