Dataslayer

Check whether a previously started async task has finished. ONLY to be called when a user has explicitly sent an ID and asking if the task has finished Do not call this tool automatically as result after another tool. ## IMPORTANT: * Do not create a new query with this tool. * You will never, under any circumstance change or modify the task id to be returned. * If the ask for a task id that does not exists you will NOT modify the task id and return the response as it is. * NEVER call this tool automatically Success schema: { "status": "success", "result": "<finished task payload>" } Warning schema: { "status": "warning", "result": "<finished task payload>" } In-progress schema: { "status": "in-progress", "error_code": "TASK_NOT_FINISHED", "result": "<same task id or task payload>" } Error schema: { "status": "error", "error_code": "INVALID_HEADERS" | "TASK_NOT_FINISHED" | "INTERNAL_ERROR" | "<datasource-specific code>", "message": "<human-readable message>" } Notes: - `warning` means the task finished but the datasource returned a business-level problem. - `error` means the task failed in a way that should not be treated as valid query output. - `in-progress` means the task is still running and should be polled again later.

This tool returns information about subscription status for the user and other account information, Use it to retrieve subscription information for the user, and then, construct the response according to user question. This information is returned for each service started by the user. If the service does not appear means this user never use it. Also, it returns information about account and company (if user is any the company) Response will have the next structure: { "account_details": { "email": <email>, # User email "first_name": <first_name>, # First name "last_name": <last_name>, # Last name "company": { # If the user does not below a company, it returns an empty dictionary "name": <company_name>, # Name of company "owner": <owner_email>, # Email of company owner. The subscriptions are associated to this user. "users_in_company": <num_users> # Return the number of users in the company. } }, "subscriptions_details":{ <Service name>: { "quota_limit": <limit>, # It means the limit of usage for the user. -1 means unlimited "limit_type": <type>, # It means type of limitation. "query" counts one per call, "row" counts depend on rows in the response "limit_frequency": <frequency>, # Period to count limits and usage. "daily" reset at 00:00 UTC, "monthly" reset at 00:00 for "sub_start_day" "sub_start_day": <sub_start_day>, # Indicates day to reset limits if "monthly" frequency. "current_usage": <usage>, # Service usage for current period. "current_usage" - "quota_limit" means available usage. "plan": { # Plan information "name": <name>, # The name of the current plan "is_trial": <is_trial>, # It means if user is in the trial of the plan "expiration_date": <exp_date>, # Determine when the plan finish unless user renew it "start_date": <start_date>, # Shows the init of the plan usage "billing_cycle": <cycle>, # Indicates frequency user has to renew the plan "MONTHLY" or "YEARLY" "subscription_type": <sub_type>, # Indicates how we manage his plan, if it is custom or is using stripe "is_cancelled": <cancelled> # If True, this plans will not renew automatically, but user will be able to use until expiration date }, "account_limit": <account_limit>, "has_blend_active": <has_blend_active>, # Indicates if user can use blends in this service. "has_ai_insights_active": <has_ai_insights_active>, # Indicates if user can use AI services. "datasource_limit": "is_datasource_limit", # If False, user can use all datasources. "datasources": <datasources_list>, # Optional, just if "datasource_limit" is True. Indicates the datasources the user can use in this service. }, ... } } ## IMPORTANT INFORMATION ABOUT AI INSIGHTS - "has_ai_insights_active" is use to AI Insights funtions. It means, MCP server, GPT creations and AI Looker Analyzer. - If "has_ai_insights_active" is a True foe one of the service means this user can use this functionallity. - If the user can use AI Insights, datasources availables will be the union for all datasources into services with "has_ai_insights_active" - If there is at least one service with "has_ai_insights_active", but "datasource_limit" is False, user can use all datasources. ## IMPORTANT INFORMATION ABOUT BLENDS - It is quiet similar to AI Insights. - User can create blends if he has "has_blend_active" as True in at least one service. - Queries using these blends, only available for services with "has_blend_active". - Datasources available for it will be datasources specified in this service (all if "datasource_limit" is False) ## TOOL USAGE - Call this tool if user asking about Dataslayer subscription details, questions like: - Which is my Dataslayer plan? - When my plan is renewed? - What about Google Sheets limitations for Dataslayer? - etc. - Questions about dataslayer account details, questions like: - How many users are there in my company? - Who is the company owner in dataslayer subscriptions? - etc. Success schema: { "status": "success", "result": { "account_details": {...}, "subscriptions_details": {...} } } Error schema: { "status": "error", "error_code": "INVALID_HEADERS" | "INTERNAL_ERROR", "message": "<human-readable message>", "result": "<optional raw payload>" }

Return the available connections and accounts for one datasource. Use this tool before querying data when the caller needs to know: - which connections exist for the user; - which accounts/properties/sites belong to those connections; - the database schema for datasource `database`. Do not use this tool to execute a report. It is discovery only. Success schema: { "status": "success", "datasource": "<datasource_id>", "connections": [{"id": "<connection_id>"}], "accounts": [ { "id": "<account_id>", "name": "<account_name>", "connection_id": "<connection_id>" } ], "database_schema": {"<connection_id>": "<schema>"}, "log_link": "<optional login link>" } Error schema: { "status": "error", "error_code": "INVALID_HEADERS" | "SUBSCRIPTION_REQUIRED" | "QUOTA_EXCEEDED" | "INVALID_DATASOURCE", "message": "<human-readable message>" }

Return 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>" }

Return the canonical metrics, dimensions and options for one datasource. Use this tool for discovery only: - when the user wants to know which fields exist; - when another tool needs the canonical field IDs; - when the user has not yet chosen valid metrics or dimensions. To avoid very large payloads, prefer using the optional filters: - `field_type` to keep only metrics or dimensions - `category` to focus on one semantic group such as time, geo or device - `search_text` to shortlist likely candidates - `common_only` to keep only common fields - `limit` to bound the response size - `compact` to return a lighter payload Do not invent field IDs. The caller must use the `id` values returned here. Success schema: { "status": "success", "dimensions": [ { "id": "dimension_id", "aliases": ["alias_1", "alias_2"], "description": "dimension_description", }, ... ], "metrics": [ { "id": "metric_id", "aliases": ["alias_1", "alias_2"], "description": "metric_description", }, ... ], "options": [ { "name": "option_name", "id": "option_id", "description": "option_description", "possible_values": ["value_1", "value_2", ...], "type": "string" | "number" | "boolean" | "list", }, ... ] } Error schema: { "status": "error", "error_code": "INVALID_DATASOURCE" | "INTERNAL_ERROR", "message": "<human-readable message>", "dimensions": [], "metrics": [], "options": [] }

Ask and return the saved schedules for Google Sheets of the user in database. This is a read only tool. User cannot change or create new schedules from here. User can ask for two different services: Google Sheets and Excel Success schema: { "status": "success", "result": "<list of available schedules for this user>" } Notes: - Status should be always "success" even if there is no schedules for the user. - Show all the info returned for each schedule

Return the request-format hints for special datasources. Use this when the user asks how to structure a request for special datasources like Google Trends, Google PageSpeed, Google Keyword Planner, or AppLovin.

# Manage 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 **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>" }

Translate one marketing/analytics request into a structured query and execute it. Use this tool only for marketing or analytics questions that should return data. Rules: - Do not invent datasources, accounts, metrics, dimensions or dates. - If the user does not specify a required account, return an error asking for the account. - If the user does not specify any metric or dimension, do not infer one automatically. - If the question is outside marketing/analytics scope, return an out-of-scope error. - Show result values exactly as returned. Do not post-process, round, split or combine them. - If the user is iterating on a previous query, preserve prior accounts, metrics, dimensions and connections unless the user changes them. - When the task is "in-progress" return the result to the user informing that the task is taking too long and they can use the returned task id as a query to ask for the current status and the result of their query. Do not automatically keep doing requests using that task id. Prefer other tools for discovery: - `get_available_datasources` - `get_available_connections_and_accounts_info_by_datasource` - `get_available_fields_by_datasource` Success schema: { "status": "success", "parameters": "<resolved query parameters>", "result": { "ok": true, "result": [ ["Date", "Hub Account", "Active users"], ["2025-08-06", "my-hub-account1", 1113], ["2025-08-30", "my-hub-account1", 947] ] } } Non-success schema: { "status": "warning" | "error" | "in-progress", "error_code": "OUT_OF_SCOPE" | "MISSING_ACCOUNT" | "MISSING_FIELDS" | "INVALID_HEADERS" | "QUOTA_EXCEEDED" | "SUBSCRIPTION_REQUIRED" | "INTERNAL_ERROR" | "<datasource-specific code>", "message": "<human-readable message>", "details": "<optional structured details>", "parameters": "<optional resolved parameters>", "result": "<query result or task payload>" }