Two Minute Reports

List all accounts for a connector type across all its connections in a single call, with their enabled/disabled status. This is the preferred tool whenever you need accounts for a specific platform — use status='enabled' to get all active accounts ready for queries, goals, and dashboards without having to iterate individual connections. Use status='disabled' to find accounts still needing activation. If connectorId is omitted, returns accounts across all connectors. If there are multiple accounts returned, you must present the list and ask which accounts to use. Supports sortBy, filters, and limit.

get_connector_accounts

Get the full query schema for a connector — available fields, report modes, required params, and validation rules. Always call this before constructing any query for validate_query or run_query. For standard connectors (GA4, Google Ads, Facebook Ads, etc.) it returns grouped metrics and dimensions. For PSI, Amazon Seller, and Google Search Console it returns the full query schema including report modes, required params, allowed values, and rules you MUST follow when building the query. PSI rule: the 'urls' field MUST be provided by the user — never auto-generate, infer, or guess URLs. If the user has not explicitly provided URLs, ask them before calling run_query.

get_connector_query_schema

Get details of a specific dashboard. Omit outputFields to get everything including full widget definitions (e.g. before update_dashboard). For a lightweight overview without the widgetConfig payloads pass outputFields like ['id', 'name', 'pages.name', 'pages.widgetCount', 'pages.widgetTypes', 'theme', 'reportDefaults'] — ideal when you just need to understand what a dashboard contains or list its pages.

get_dashboard

Returns the structural spec for hand-building TMR dashboard widgets — every widget type, its widgetConfig shape, layout/grid rules, and data-field rules. (Theme/palette/typography are inherited from the existing dashboard, not covered here.) Call this ONCE before hand-building a dashboard/widget config (create_dashboard / update_dashboard), then REUSE it for the rest of the conversation — do NOT refetch on every call. NOT needed for the AI generators (generate_dashboard / generate_dashboard_page), nor for changing a metric/dimension/chart type on an existing widget (use get_connector_query_schema + validate_query for that). Hand-built dashboards that ignore these guidelines will have structural errors and render incorrectly.

get_dashboard_guidelines

Get full details of a specific goal including its performance metric, target value, date range, progress direction, and the connector accounts it is measured against. Use outputFields to select which response fields are returned.

get_goal

Get details for the team — plan name, usage limits, and member count.

get_team

List all members of the team, with the role each one holds and whether they have a seat. Every team has the same six standard roles — viewer, editor, data_manager, deputy_admin, admin, owner — and may define its own, in which case roleCode is null and roleName carries the team's name for it. A seat is separate from a role: a member without one sees everything their role allows and is refused every write. Supports sortBy, filters, and limit.

get_team_members

Get the current user's profile including name, email, and avatar.

get_user

List the connector accounts mapped to a specific client, optionally filtered by connector type. Use this when the user's question is about a named client and you need to know which accounts belong to them. The returned accountIds are what you pass to validate_query and run_query. If the user has not mentioned a specific client and just wants accounts for a connector, use get_connector_accounts(status='enabled') instead. Supports sortBy, filters, and limit.

list_client_accounts

List all clients for the team. A client represents a business or advertiser the team manages (e.g., an agency client). Clients group related connector accounts together and are used to scope goals and dashboards. Call this when the user refers to a client by name to resolve its clientId. Use outputFields to pick which response fields each item includes (e.g. ['id', 'name'] for name resolution); supports sortBy, filters, and limit.

list_clients

List all data source connections for the team. A connection is an authenticated link to an external platform (e.g., a Google Ads OAuth login or a Facebook Ads account). Use this for connection management tasks — checking OAuth status or troubleshooting a specific integration. To find accounts for data queries, dashboards, or goals, use list_connectors then get_connector_accounts(status='enabled') instead — it is faster and covers all connections in one call. Supports outputFields (pick which response fields each item includes, e.g. ['id', 'name', 'status'] to skip the config blob), sortBy, filters, and limit.

list_connections

List all connector types active for the team (e.g., GA4, Google Ads, Facebook Ads) with the count of connections and enabled accounts per connector. This is the first step when you need to discover what data sources are available — call this before get_connector_accounts to know which connectorIds to query. A connector is a platform type; a team can have multiple connections per connector (e.g., two separate Google Ads logins) but this tool aggregates them all into one row per platform. Supports sortBy, filters, and limit.

list_connectors

List the team's custom fields: metrics and dimensions the team defined itself, on top of the native connector fields. Their ids start with 'tmr_custom_' and are valid wherever a native field id is, in run_query metrics, dimensions and filters — the platform resolves them when the query runs. Each field says how it is computed: 'formula' (an expression over connector fields), 'join' (blending — one source field mapped per connector), or 'split' (a fragment taken out of a naming convention). Use outputFields to keep responses small — a full definition includes every formula item — and sortBy, filters and limit to narrow the list.

list_custom_fields

List all dashboards for the team. A dashboard is a collection of data visualisation widgets, each backed by an analytics query. Dashboards can be client-scoped (clientId is set — widgets can only use accounts mapped to that client) or team-wide (clientId is null — widgets can use any enabled account across any client or unmapped accounts). Dashboards render their own charts and do not require run_query. Full pages/theme payloads are returned unless narrowed — prefer outputFields like ['id', 'name', 'clientId', 'pageCount', 'widgetCount'] when browsing; supports sortBy, filters, and limit.

list_dashboards

List all performance goals for the team. A goal tracks a specific metric target (e.g., achieve 10,000 sessions, keep CPC below $2) over a defined period, measured against one or more enabled connector accounts. Goals can be client-scoped (clientId is set — only accounts mapped to that client can be used) or team-wide (clientId is null — any enabled account across any client can be used). Use outputFields to pick which response fields each item includes (e.g. pass ['id', 'name', 'entityType'] to check which goals are standalone); supports sortBy, filters, and limit.

list_goals

Execute analytics queries for one or more connectors and return data rows. Supports multiple connectors in a single call — pass one entry per connector in the 'connectors' array. Required flow: get_connector_query_schema → construct query → validate_query → run_query. Queries must be validated via validate_query before execution. Before executing: must show the query to the user, explain what it will fetch, and ask if they want any changes. Only call run_query after they confirm. All queries across all connectors run in parallel. Use this only for ad-hoc data insights where the user wants actual numbers returned in the conversation. For dashboard widgets do NOT call run_query — embed the validated query object directly as the widget's widgetConfig instead. FIELD IDs: always raw, no connector prefix (e.g. 'sessions' not 'ga4_sessions'). connectorId is per-entry, NOT a prefix. Account IDs: pass raw account IDs without prefix (e.g. '123456789' not 'ga4_123456789'). CUSTOM FIELDS (list_custom_fields) are the exception to the raw-id rule: pass the full 'tmr_custom_*' id unchanged in metrics, dimensions, filters or sort. A blended custom field ('join') returns only the queried connector's share, not its cross-platform total — each connectors entry runs one connector. Sum the per-connector results to state a total. After returning the results, suggest the next step that fits what the user is trying to do — keep it on a dashboard (create_dashboard), track it as a goal (create_goal), or turn a calculation they asked about into a reusable custom field (create_custom_field). SORTING: use query.sort ([{sortField, direction: 'asc'|'desc'}]) to order result rows — e.g. for 'top campaigns by clicks' sort by 'clicks' desc. sortField must be one of the query's own metrics/dimensions. Default when omitted: ascending by dimensions. REPORT CONNECTORS — some connectors use query.reportParams instead of (or alongside) metrics/dimensions. Always call get_connector_query_schema first for the connector — it tells you required reportParams fields, which metrics to pass, and any rules.

run_query

Update a client's name or domain. Only send the fields that should change. If domain is updated, the logo is automatically re-fetched from the domain (unless a custom logo has been uploaded from the hub).

update_client

Change an existing custom field's definition. Send only the keys that change; anything omitted keeps its current value. Each key is replaced whole, never merged: join, formulaItems, conditionRules and splitConfig discard their previous value, so send the complete new one. Get customFieldId from list_custom_fields. This edits a definition other things already depend on: every dashboard widget, goal and saved query that selected this field starts computing the new definition, including for periods already reported. A field cannot change between metric and dimension, because whatever already references it selected it as one or the other. Sending configurationMethod switches the field to that method and discards the configuration the previous method used, so send the new method's own config in the same call. Field ids inside formulaItems, conditionBlocks and mappings are connector-prefixed, exactly as get_connector_query_schema returns them for that connector.

update_custom_field

⚠ Hand-building pages/widgets? Read get_dashboard_guidelines first (once per conversation — reuse it, don't refetch) for widget types, layout rules, and data field rules. (Skip it for the generate_* tools and for simple metric/dimension tweaks to existing widgets.) Update an existing dashboard — rename, change scope, replace pages/widgets, update reportDefaults or theme. Only provided fields are updated; omit the rest. Always call get_dashboard first (without outputFields, so full pages are returned) to read current pages before modifying. Pages are replaced wholesale — partial page updates are not supported. Do NOT call run_query for dashboard widgets.

update_dashboard

Update an existing goal's fields. Only send the fields that should change — all fields are optional. Do NOT change entityType or performanceMetric to an incompatible type (e.g. swapping from a spend metric on a budget_goal). Use get_goal first if you need to confirm current values before updating.

update_goal

Update the current user's first and last name. Both are required.

update_user_name

Validate queries for one or more connectors before executing them. Supports multiple connectors in a single call — pass one entry per connector in the 'connectors' array. Query construction flow: (1) Call get_connector_query_schema for each connector to discover field IDs. (2) Construct each query: choose metrics and dimensions by raw 'id' values, set date range, add filters. For report connectors, leave metrics/dimensions empty and populate query.reportParams instead. (3) Call this tool — each query is validated independently and errors name exact field IDs or rule violations. (4a) If the user wants data: pass the same connectors array to run_query. (4b) If for a dashboard widget: convert field IDs to connector-prefixed format before embedding. PREFIXING RULE — validate_query / run_query use RAW IDs; dashboard widget configs use PREFIXED IDs: validate_query / run_query → accountIds: ['123456789'] metrics: ['sessions'] dimensions: ['date'] widget widgetConfig → accounts: ['ga4_123456789'] metrics: ['ga4_sessions'] dimensions: ['ga4_date'] Prepend '<connectorId>_' to EVERY field and account when moving from query to widget. CUSTOM FIELDS (list_custom_fields) are the exception: pass the full 'tmr_custom_*' id unchanged.

validate_query

Verify the user's identity and retrieve the teams they belong to. Always call this first — every other tool requires a teamId. Each team includes a planStatus field. Plan status values: - 'active', 'in_trial', 'non_renewing' → plan is active; all tools are available. - 'cancelled' → the team's plan is not active Do NOT call any create, update, delete, validate_query, or run_query tools for a cancelled team. If the user belongs to multiple teams, you must present the list and ask which team to work with — note any cancelled teams so the user can pick an active one. Store the chosen teamId for all subsequent tool calls. WORKFLOW — discovering accounts for data queries, dashboards, or goals: 1. list_connectors — see which platform types (GA4, Google Ads, etc.) the team has active. 2. get_connector_accounts(connectorId, status='enabled') — get all enabled accounts for that platform in one call. Do NOT use list_connections → get_connection_accounts for this — it makes one extra call per connection and returns the same information less efficiently.

verify_team_details