Cube

Get a Cube dashboard by ID, including tabs, widgets, layout, and range dimensions

get_dashboard

Browse direct children of a dimension when chart-of-accounts children were truncated. Use after get_chart_of_accounts returns a node with _children_truncated. Dimension IDs must come from get_chart_of_accounts in this session. Paginate with offset/limit; optionally filter with name_contains for wide lists (hundreds of children). Args: dimension_id: Parent dimension ID from get_chart_of_accounts. ctx: The context of the request. This is used to get the user company from the request context. offset: Zero-based index into the filtered child list (default 0). limit: Max children to return per page (default 100). name_contains: Optional case-insensitive substring filter on child names. Returns: JSON envelope with parent_id, parent_name, total, offset, limit, has_more, and children.

get_dimension_children

Use this for TRANSACTION-LEVEL auditing. This is the lowest level of detail available. Use this when a user asks for "source data," "specific transactions," or "the details behind this number." A header will be present for each dimension the company has, the value of the data point, as well as any additional metadata that is stored about that data point. IMPORTANT: The IDs for 'filter_dimension_ids' MUST be retrieved first using the 'get_chart_of_accounts' tool. Do not guess these IDs. All dimensions must be represented in this dictionary. Prefer using 'get_financial_slice_of_data' for aggregated reporting. Only use this tool when transaction-level detail is specifically requested. The tool parameters are exactly filter_dimension_ids, operation, and operation_parameters (plus the framework context). Do NOT use alternate parameter names like account_ids, start_date, or end_date. Keys in filter_dimension_ids must be exact dimension names from the chart of accounts (e.g. "Account", "Department", "Time"). For a date or period range, pick the appropriate child IDs under the company's Time dimension from get_chart_of_accounts—do not pass raw calendar dates as separate parameters. Example call (IDs are illustrative; always use real IDs from get_chart_of_accounts): filter_dimension_ids: {"Account": 65002, "Department": 12, "Time": 88} operation: "head" operation_parameters: {"n": 20} Args: filter_dimension_ids: A dictionary where each key is a dimension name and each value is the ID of a single child from that dimension in the Chart of Accounts. All dimensions must be represented in this dictionary. Keys must be dimension names, not numeric indices like "0" or "1". operation: A pandas DataFrame operation to run on the drilldown data (required). Common operations: - 'head': Returns first N rows (e.g., {'n': 10}). Use to preview the data structure. - 'sort_values': Find outliers (e.g., {'by': 'Value', 'ascending': False}). - 'query': Filter further (e.g., {'expr': 'Value > 10000'}). - 'sum': Aggregate a column (e.g., {'numeric_only': True}). operation_parameters: The parameters to pass to the pandas operation as a JSON object (dict), not a string. See pandas DataFrame documentation for operation-specific parameters. ctx: The context of the request. This is used to get the user company from the request context. Returns: The result of the pandas operation as a string. If the resulting DataFrame exceeds 500 rows, it will be automatically truncated with a warning. If you see a truncation warning, refine your 'operation_parameters' to be more specific (e.g., use more filters or aggregation operations like 'sum()', 'mean()', etc.).

get_drilldown_data

Use this function to get a slice of financial data for this company. This function acts like a pivot table in a spreadsheet and will show a slice of financial data. The row and column headers will be on the top and left side of the grid. The filters will be applied to the data in the grid. Think of this as building a Summary Table. It aggregates data into a grid based on the dimensions you provide. IMPORTANT: The IDs for 'filters', 'row_header_dimension_ids', and 'column_header_dimension_ids' MUST be retrieved first using the 'get_chart_of_accounts' tool. Do not guess these IDs. Optional time_aggregations: map each Time dimension ID (integer) to a time shortcut string so rollups are computed server-side by the cube engine. Do not fetch many separate time periods and sum them in the client; use one anchor Time ID plus a shortcut instead. Shortcut examples include YTD (year-to-date), QTD (quarter-to-date), LTD (lifetime-to-date), ROY (rest of year), T2M/T3M (trailing N months, digit 1-365), N6M (next N months), T2Q/N3Q (trailing/next N quarters), T2Y/N1Y (trailing/next N years). Anchor level: for month-level shortcuts (T2M, T3M, N6M, QTD, etc.) use the specific month or period Time dimension ID, not a year or quarter ID. For quarter-level shortcuts (T2Q, N3Q) use the quarter ID. For year-level shortcuts (T2Y, N1Y) use the year ID. Every key in time_aggregations must also appear in row_header_dimension_ids or column_header_dimension_ids, not in filters. When using time_aggregations, do not also pass a separate Time filter; put the Time ID on a row or column axis so the rollup appears in the grid. If arguments are invalid (wrong dimension IDs, Time ID not on an axis, shortcut vs level mismatch, etc.), the response is a JSON string with an 'error' field and a human-readable 'message' describing the fix. Example call — Revenue by Department for Q1 2025 months (IDs are illustrative; always use real IDs from get_chart_of_accounts): filters: {"Account": 5010, "Scenario": 301} row_header_dimension_ids: [120, 121, 122] # Department children: Sales, Marketing, Engineering column_header_dimension_ids: [800, 801, 802] # Time children: Jan-25, Feb-25, Mar-25 Example call with time_aggregations — YTD Revenue by Department as of Mar 2025: filters: {"Account": 5010, "Scenario": 301} row_header_dimension_ids: [120, 121, 122] # Department children: Sales, Marketing, Engineering column_header_dimension_ids: [802] # Time child: Mar-25 (month-level anchor for YTD) time_aggregations: {802: "YTD"} Args: filters: A dictionary where each key is a dimension name and each value is the ID of a single child from that dimension in the Chart of Accounts. If a dimension is included in the filters, it should not be included in the row or column headers. These are global constraints on the data. row_header_dimension_ids: A list of IDs of children from a single dimension. This dimension IDs must be from the company's Chart of Accounts. This cannot be empty. column_header_dimension_ids: A list of IDs of children from a single dimension. This dimension IDs must be from the company's Chart of Accounts. This cannot be empty. ctx: The context of the request. This is used to get the user company from the request context. time_aggregations: Optional map from Time dimension ID to shortcut. Omit or pass null when not needed. Returns: A slice of financial data comprised of a grid of values with their corresponding row and column header dimension names added in the first row and column.

get_financial_slice_of_data

Get full Cube formula syntax: IF, functions, SKIP, intersections, TABLE_LOOKUP, and constraints

get_formula_syntax

Get the 2D data grid for a planning table in a specific scenario. Planning tables store typed columnar data (text, number, dimension, calculated columns) used for strategic planning such as headcount. Call list_planning_tables first to discover available table IDs. Scenario IDs must come from get_chart_of_accounts (Scenario dimension). Returns JSON with planning_table_name, scenario_id, headers (column names), and rows (2D array of cell values). Rows the user cannot access due to dimension permissions are excluded. Args: planning_table_id: The ID of the planning table from list_planning_tables. scenario_id: The Scenario dimension member ID from get_chart_of_accounts. ctx: The context of the request. This is used to get the user company from the request context. Returns: JSON string with headers and filtered data rows for the planning table dataset.

get_planning_table_data

Get valid planning table column types, attributes, formats, and the company top-level dimensions for dimension columns. Call before create_planning_table.

get_planning_table_schema_options

Get available widget settings fields and valid values for dashboard widgets

get_widget_settings_schema

Start a data import for a connection's data table. Prefer reusing parameters from list_connections recent_imports: start_time_dimension_id, end_time_dimension_id, scenario_dimension_id, and other_dimensions (flat leaf IDs for defaults such as Department). Dimension IDs may also come from get_chart_of_accounts. When other_dimension_ids is omitted, the tool reuses defaults from the most recent successful import for that connection. If there is no prior successful import, you must pass other_dimension_ids explicitly. If a prior initiate_import failed with "Sync source dimensions before importing", confirm with the user first, then retry with sync_dimensions_first=True. If the response has status DIMENSION_SYNC_BACKGROUNDED, tell the user to wait for the background sync to finish, then call initiate_import again without sync_dimensions_first. Args: data_table_id: The data_table_id from list_connections for the connection to import. Match the user's connection name to the list_connections name field, then pass that connection's data_table_id. Confirm with the user when more than one connection matches or none does. scenario_id: Scenario dimension member ID to import into. start_time_dimension_id: Start of the Time range to import. end_time_dimension_id: End of the Time range to import. ctx: The context of the request. This is used to get the user company from the request context. other_dimension_ids: Optional list of default leaf dimension IDs for non-mapped TLDs (e.g. Department). Exclude Scenario and Time; Scenario is passed separately. sync_dimensions_first: When True, sync source dimensions before starting the import. Use only after confirming with the user when a prior attempt required a sync. Returns: The started import object as JSON (id, status, time/scenario dimensions, etc.), or a DIMENSION_SYNC_BACKGROUNDED status when the sync was started in the background.

initiate_import

List all companies the user has access to

list_companies

List the company's data connections. Each connection includes name (the name shown on the Connections page), data_table_id (the connection ID initiate_import accepts), source, type, recent imports, and scheduled-import configuration. Match the user's connection name against the name field. Confirm with the user when more than one connection matches or none does.

list_connections

List Cube dashboards the user has access to

list_dashboards

List planning tables the user has access to

list_planning_tables

List all tags and their members for this company

list_tags

List tasks for a workflow the user has access to. Call list_workflows first to discover workflow IDs. workflow_id is required. Args: workflow_id: The workflow (process) ID from list_workflows. ctx: The context of the request. This is used to get the user company from the request context. status: Optional task status filter. Valid values: DRAFT, TODO, DONE. Returns: JSON list of tasks with id, name, description, status, due_date, assignee_id, and process_id.

list_tasks

List workflows (processes) the user has access to, with optional status filter

list_workflows

Publish financial data to an AI-managed Scenario in the cube. IMPORTANT: Call get_chart_of_accounts first and enumerate this cube's actual TLDs and leaf members. Only Account, Time, Scenario, and Department are guaranteed; all other TLDs are customer-defined and vary by cube (Entity, Market, Product, Vendor, Region, etc. — or none). All dimension references (row headers, column headers, filter values) must be IDs from that response — never hardcode names or reuse IDs from memory or a previous session/company. PERFORMANCE: Each publish triggers formula recalculations and is a heavy operation. Minimize the number of publish calls by batching as much data as possible into each one. Use multiple row headers and column headers to publish a wide matrix in a single call rather than making many small publishes. For example, publish all accounts x all time periods in one call instead of one call per account or per period. COMPLETENESS AND LEAF-LEVEL RULE: Every TLD the cube has must appear on a row/column axis in data or as a key in filters. Data is stored only at child (leaf) members — parents, formula members, and tag members cannot be written to (they recalculate from inputs). Write leaf driver accounts and let formula rollups (Net Income, EBITDA, Gross Margin, etc.) recompute. Filters pin exactly one leaf per dimension for the whole call. NESTED ROW AXES: Multiple dimensions nest on the row axis (stacked header columns, one per dimension) with Time across the columns. A fully-dimensional dataset publishes as a single range. Do not loop one publish per dimension-combination — batch all intersections and periods into one wide payload. Example with Account and Department on rows, Time on columns, Scenario in filters (IDs illustrative; use real IDs from get_chart_of_accounts; pivot cells in the top-left are empty strings): [["", "", time_id_1, time_id_2], [acct_id_1, dept_id_1, 100, 200], [acct_id_1, dept_id_2, 300, 400], [acct_id_2, dept_id_1, 150, 250]] DISTRIBUTE HIGH-LEVEL CHANGES: Changes are usually described at a high level ("grow platform revenue 8%", "hold S&M flat"), but the cube stores at leaf intersections. Don't collapse a high-level change onto an arbitrary or single leaf — look at how the baseline scenario the change builds on is broken down across dimensions and distribute in a way that respects that shape. Read real joint intersections via get_financial_slice_of_data where possible rather than reconstructing from marginals or assuming; reason per line, since different lines break down differently. This is default behavior, not a hard rule: explicit user guidance on how a change should land overrides it. Be transparent that any dimensional detail so introduced is inferred from the baseline, not user-specified. The Scenario dimension must be included in filters and must target an AI-managed scenario (write_protection = 'AI'). Args: data: 2D array. Column headers (Time IDs) occupy the first row after empty pivot cells. Nested row-axis dimensions occupy leading columns of each data row (one cell per TLD), then numeric values. Include as many rows and columns as possible to minimize total publish calls. filters: TLD name -> member dimension ID. Must include Scenario and all other TLDs not represented in row/column headers. Each value must be a writable leaf member ID. message: Changelog description for the publish. ctx: MCP context. Returns: A summary of values updated and an audit trail link, validation errors, or a background-processing message if the publish is still running after monitoring completes (publishes always run via a background worker with up to ~3 minutes of status polling before returning).

publish_data

Selects which company of the ones the user has access to is used for requests. Args: company_id: The ID of the company to select. ctx: The context of the request. This is used to get information about the user's session. Returns: A message indicating the company has been selected.

select_company

Update an existing Cube dashboard by replacing its metadata, tabs, widgets, and layouts. IMPORTANT: Call get_dashboard first if you need to preserve existing tabs or widgets. This tool applies the submitted dashboard definition to the existing dashboard. Args: dashboard_id: The ID of the dashboard to update. name: The updated dashboard name. Must be unique within the company. ctx: The context of the request. This is used to get the user company from the request context. description: Optional updated description. filters: Optional global dashboard filters where each key is a top-level dimension name and each value is a member dimension ID from that hierarchy. tabs: Optional list of tab definitions. Each tab can include a name and widgets. Widget definitions use the same structure as create_dashboard. type must be RANGE (data widget) or TEXT (text block). visual_type must be DATA_TABLE, LINE, BAR, ROW, COMBO, PIE, DONUT, METRIC, TREND, WATERFALL, or TEXT. Do not put a visual_type such as BAR or DATA_TABLE in type. Returns: A message with the updated dashboard ID or a validation error explaining what needs to be fixed.

update_dashboard

Replace the full dataset for a planning table in a specific scenario. IMPORTANT: Always call get_planning_table_data first, modify the returned rows, and resend the complete set of rows. Omitted rows are deleted from the caller's accessible data. Rows the caller cannot see due to dimension permissions are preserved automatically. This check is scoped to the exact (planning_table_id, scenario_id) pair you're about to write. Checking one scenario does not clear you to write to a different scenario — if the target scenario changes for any reason (including mid-conversation redirection by the user), call get_planning_table_data again for that specific scenario_id before writing, even if empty/no-data was already confirmed elsewhere. The Scenario must have AI write protection (write_protection = 'AI'). Scenario IDs must come from get_chart_of_accounts. Column order and count must match the headers from get_planning_table_data / list_planning_tables. Dimension cells may be member IDs (as returned by get) or member names. Args: planning_table_id: The ID of the planning table from list_planning_tables. scenario_id: The Scenario dimension member ID from get_chart_of_accounts (must be AI-managed). rows: Full 2D array of cell values (no header row). Same shape as get_planning_table_data rows. ctx: The context of the request. This is used to get the user company from the request context. Returns: JSON summary of the write (created/updated, rows written) or a rejection message describing validation/permission failures to fix before retrying.

write_planning_table_data