check_task_id
ChatGPTUse this only when the user asks whether a query they started has finished, giving its task_id (natural_to_data returns it with status "in-progress"). Do not call it on your own right after natural_to_data, and do not use it to start a new query. Pass the task_id exactly as the user gave it, even when it looks wrong. Status "success": the finished result. "in-progress": still running; tell the user to ask again later. "warning": it finished without data. "error": its error_code says why (the query failed, or UNKNOWN_TASK: a task_id not copied exactly or expired); follow its next_step.
dataslayer_subscription_information
ChatGPTUse this when the user asks about their Dataslayer plan, limits, usage, renewal or company, e.g. "which is my plan?", "when is my plan renewed?", "what are my Google Sheets limits?" or "how many users are in my company?". Returns "account_details": email, first_name, last_name and "company" (name, owner: the user the subscriptions belong to, users_in_company; empty when the user has no company). And "subscriptions_details", per service the user has started (a missing service was never used): - quota_limit (-1 means unlimited), limit_type ("query": one per call, "row": per returned row), limit_frequency ("daily": resets at 00:00 UTC, "monthly": resets on sub_start_day) and current_usage; the usage left is quota_limit - current_usage. - plan: name, is_trial, start_date, expiration_date, billing_cycle (MONTHLY or YEARLY), subscription_type (custom or Stripe) and is_cancelled (true: it does not renew, but works until expiration_date). - account_limit, has_blend_active, has_ai_insights_active, datasource_limit and, only when datasource_limit is true, datasources: the only ones usable in that service. AI Insights (this MCP, GPTs and AI Looker Analyzer) is usable when at least one service has has_ai_insights_active; its datasources are the union of those services' datasources, or all of them when one of those services has datasource_limit false. Blends work the same way with has_blend_active.
get_available_connections_and_accounts_info_by_datasource
ChatGPTUse this when the user asks which accounts, properties or sites they have in one datasource, or for the schema of a "database" connection. Do not use it to get data (use natural_to_data) or to list the connected datasources (use get_hub_connections). Returns "connections" ({"id"}), "accounts" ({"id", "name", "connection_id"}), for "database" the "database_schema" of each connection id and, when the datasource has no connection, a "log_link" where the user connects one in the Dataslayer Hub, also said in "message": give the user that link.
get_available_datasources
ChatGPTReturn the datasources available to the current user. Use this tool for discovery only: - when the caller needs to know which datasources can be queried; - when the user names a datasource ambiguously and you need canonical IDs; - before asking for connections, accounts or fields. Always use the returned id as the canonical datasource identifier in later tool calls. Success schema: { "status": "success", "result": { "available_datasources": [ {"id": "<datasource_id>", "name": "<datasource_name>"}, ... ], "other_datasources": [ {"id": "<datasource_id>", "name": "<datasource_name>"}, ... ] } } Error schema: { "status": "error", "error_code": "INTERNAL_ERROR", "message": "<human-readable message>" }
get_available_fields_by_datasource
ChatGPTUse this when the user asks which metrics, dimensions or options a datasource has, e.g. "which CTR metrics does Facebook Ads have?". Do not use it to get data: use natural_to_data. Returns "metrics" and "dimensions" as {"id", "aliases", "type", "category", "concept", "common"} (compact false adds each field's "description") and "options" with their possible values. Use the returned ids as they are; never invent one. The answer can be large: narrow it with field_type, category, search_text, common_only or limit. A search_text that finds nothing answers a "message" saying what to try next.
get_hub_connections
ChatGPTUse this when the user asks which or how many data sources they have connected, e.g. "how many / which data sources do I have?", "my connected sources" or "¿cuántas fuentes de datos tengo?". Count only the datasources whose list of connections is not empty. For what the plan allows (trials included) use get_available_datasources; for the accounts inside the connections use get_available_connections_and_accounts_info_by_datasource. Returns every datasource id with its connections; an empty list means not connected: { "<datasource_id>": [{"id": "<connection id>", "is_shared": <bool>, "shared_by": "<email>"}], "<datasource_id>": [], ... }
get_next_paginated_result
ChatGPTUse this only when the user asks for the next page of a query result, giving the task_id that natural_to_data returned. Do not call it on your own, and do not use it to start a new query. Pass the task_id exactly as given; page_token is not needed: each call gives the page after the last one given. Returns the next page and, when more pages remain, a next_page_token. "error" with NOT_FOUND: there are no more pages, tell the user; any other "error": follow its next_step.
get_schedules_from_user
ChatGPTUse this when the user asks which Google Sheets or Excel schedules they have saved. Read only: it cannot create or change schedules. For data transfers to warehouses or storage use manage_data_transfer_schedules. Pass destination when the user said Google Sheets or Excel. Returns the schedules (document, type, timezone, query parameters, last execution, created and modified dates); status "success" with an empty list means the user has none. Show every field returned.
get_special_datasource_call_type_hints_tool
ChatGPTUse this when the user asks how to request data from a special datasource (google_trends, google_pagespeed, google_keyword_planner, applovin, instagram_public_data, facebook_public_data, youtube_public_data), or to know which call_type to pass to get_available_fields_by_datasource for one of them. Returns, per special datasource, its "call_types", the "extra_args" each one takes and "notes". To get data, write those values (usernames, page ids, keywords...) in the question of natural_to_data: it takes no other argument.
manage_alerts
ChatGPTManage AI Alerts This tool translates a natural language request into an AI alert action (create, update, delete, list or run existing alerts) and fills in the parameters required by the Dataslayer API. You can also obtain a history of the executions of a specific alert, using "get_history" operation Assistant Prompt Use this tool whenever the user wants to manage AI alerts. Infer the intent and return the appropriate operation: - create: configure a new alert. Ensure you capture or infer a clear name, message, frequency, schedule, and timezone. If the user omits these, propose sensible defaults aligned with the request. - update: modify an existing alert. Identify the alert by ID or name. Only change the fields the user mentions; keep other settings untouched. - delete: remove an existing alert. Confirm the alert ID or name before deleting. - get: list the user’s saved alerts when they just want to review existing ones. - run: add alert to queue execution. Identify the alert by ID or name. - get_history: list history executions from an alert. Identify the alert by ID or name. Always confirm that schedule details (weekday, hour, minute, selected hours) make sense, and clarify ambiguities when required. Remember that message and schedule information are mandatory for create/update operations, while they are optional for delete. Respond with empathetic, professional language and include actionable next steps if the user needs to provide extra details. Success schema: { "status": "success", "result": "<alert management payload>" } Error schema: { "status": "error", "error_code": "INVALID_HEADERS" | "INTERNAL_ERROR", "message": "<human-readable message>", "result": "<optional raw payload>" }
manage_data_transfer_schedules
ChatGPTManage Data Transfer Schedules IMPORTANT Just use this tool if user wants to manage his data transfer schedules for next services: - Big Query - AWS Redshift - AWS S3 - Snowflake - Google Cloud Storage - Database In other case, not use it This tool manages data transfer schedules for the user associated with the provided user token. Use this tool whenever the user wants to manage data transfer schedules. Infer the intent and return the appropriate operation: - create: configure a new data transfer schedule. Ensure you capture or infer a clear name, message, frequency, schedule, and timezone. If the user omits these, propose sensible defaults aligned with the request. - update: modify an existing data transfer schedule. Identify the data transfer schedule by ID or name. Only change the fields the user mentions; keep other settings untouched. - delete: remove an existing data transfer schedule. Confirm the data transfer schedule ID or name before deleting. - get: list the user’s saved data transfer schedules when they just want to review existing ones. - run: add data transfer schedule to queue execution. Identify the data transfer schedule by ID or name. - get_history: list history executions from a data transfer schedule. Identify the data transfer schedule by ID or name. Take into account, Dataslayer has different services to data transfer funcionality, and each one has its own parameters (destination_params): - Big Query: "project_id", "dataset_id", "table_id", "destination_email" - AWS Redshift: "table_name", "connection_id" - AWS S3: "upload_path", "file_name", "connection_id" - Snowflake: "table_name", "connection_id" - Google Cloud Storage: "upload_path", "file_name", "connection_id" - Database: "table_name", "connection_id" Service has been defined clarify in question passed by the user, and his respective destination parameters. Always confirm that schedule details (weekday, hour, minute, selected hours) make sense, and clarify ambiguities when required. Remember that message and schedule information are mandatory for create/update operations, while they are optional for delete. Respond with empathetic, professional language and include actionable next steps if the user needs to provide extra details. Success schema: { "status": "success", "result": "<data transfer schedule payload>" } Error schema: { "status": "error", "error_code": "INVALID_HEADERS" | "SUBSCRIPTION_REQUIRED" | "INTERNAL_ERROR", "message": "<human-readable message>", "result": "<optional raw payload>" }
natural_to_data
ChatGPTUse this when the user asks for marketing or analytics data: metrics by dimensions for some accounts and dates, e.g. "clicks by campaign in Facebook Ads last month". Pass the whole request in question; the tool resolves the datasource, accounts, fields and dates and runs the query. Do not use it for questions outside marketing or analytics, or only to list datasources, fields or accounts (use the other tools for that). One datasource and one period per call: to compare datasources (Google Ads against Facebook Ads) or periods (September against September last year), call it once for each. When the user refines a previous query, restate it with the change, so the accounts, metrics, dimensions and connections they did not change stay the same. How to read the answer: - "success": "result" holds the table. Show the values exactly as returned, without rounding, splitting or combining them. - "in-progress": the query is still running. Tell the user and give them the task_id so they can ask for it later (check_task_id); do not poll it on your own. - A next_page_token in the result: show this page, and tell the user they can ask for the next one (get_next_paginated_result with the task_id). Do not split the request into smaller queries. - "warning" with MISSING_FIELDS or "error" with MISSING_ACCOUNT: ask the user for what is missing instead of guessing it. - Any other "error" or "warning": follow its next_step.
