Amperity

Delete one or more bridges. Automatically disconnects inbound syncs and removes outbound shares before deleting the bridge to prevent orphaned resources.

bridge_delete

Remove outbound share configuration from a bridge. Stops sharing tables via this bridge.

bridge_delete_share

Remove inbound sync configuration from a bridge. This removes the domain tables created by the sync.

bridge_disconnect

Download outbound Delta Sharing credential file (config.share) for a Databricks bridge. This file contains the credentials that external systems need to connect to Amperity's Delta Sharing endpoint. SECURITY: Credentials are written to a file, never returned in response. Attach the file in the Amperity UI instead: Destinations > Bridges > select the bridge > Credential.

bridge_download_credential

Get details for a specific bridge, including its derived connectivity status (connected/disconnected/null) and connection config (recipient ID, share name, or BigQuery coordinates) when available.

bridge_get

Get outbound share details for a bridge. Returns the tables currently being shared out via this bridge.

bridge_get_share

Get inbound sync details for a bridge. Returns domain tables synced from external sources. These tables can be transformed into CDTs using domain_transform_upsert.

bridge_get_sync

List all bridges configured in the tenant. Returns bridges for Databricks, Snowflake, and BigQuery data sharing. Use offset to paginate when has_more is true.

bridge_list

List the tables available on a Delta Sharing share. Provide exactly one of: 'file_path' (a local Delta Sharing profile, for pre-connection discovery after bridge_upload_credential), or 'bridge_id' (an already-connected bridge, listed via its stored credentials). The bridge_id mode is Databricks/Delta-Sharing only.

bridge_list_share_tables

Load Amperity's built-in Sample Data, Reference Data, or Training Data. Creates a pre-configured Databricks bridge with Amperity-hosted credentials and syncs data automatically. No external credentials needed. Use 'sample' for Sample Data (~10M demo customer records), 'reference' for Reference Data (lookup/enrichment tables like state codes, ZIP codes, country codes, and other standardization data), or 'training' for Training Data (student/training tenants). Each data_type creates its own separate bridge. Optionally specify which tables to sync; omit to sync all available tables.

bridge_load_amperity_data

Run a bridge sync to pull data from an external Delta Sharing endpoint. Triggers a workflow that syncs all mapped tables from the external source into Amperity domain tables. Use after configuring the bridge with bridge_connect. POLLING: Syncs typically take about 5 minutes. Wait 2 minutes, then poll every 2 minutes. Use Bash with run_in_background for sleep to let the user continue working.

bridge_run_sync

Update a bridge's name or description.

bridge_update

Update the inbound sync mapping for a connected bridge. Use this to add, remove, or rename table mappings, or to refresh the schema when upstream table fields have changed — all without disconnecting. Replaces the entire mapping. If any table no longer exists upstream, the request fails. Get the current mapping with bridge_get_sync first, then modify and submit the full mapping.

bridge_update_sync

Upload inbound Delta Sharing credential file for a Databricks bridge. This uploads a config.share file that Amperity uses to connect to an external Databricks Delta Sharing endpoint. SECURITY: Credentials are read from file, never passed through LLM. Attach the file in the Amperity UI instead: Sources > Bridges > select the bridge > Credential.

bridge_upload_credential

Build a deep-link URL to an Amperity UI page. Returns {"url": "..."}; constructed locally, no API call. Pass object_id for a detail page, omit it for a list page. On invalid input, the error lists valid object_types, variants, and sub_resources — call once and read the message to discover them. Note: seg-* IDs are object_type='segment' (defaults to the live route; pass variant='draft' for a draft-only query that was never activated); mx-seg-* are 'iq_segment'.

build_object_url

Create a new campaign draft. IMPORTANT: Treatments cannot be passed during creation (API limitation). Create the campaign first, then use campaign_update to add treatments.

campaign_create

Delete one or more campaigns. WARNING: This permanently removes the campaigns.

campaign_delete

Duplicate an existing campaign with a new name. Creates a copy as a draft, including treatments and sub-audiences.

campaign_duplicate

Create a new campaign folder. Use parent_folder_id to nest inside another folder.

campaign_folder_create

Delete a campaign folder. WARNING: This also deletes ALL campaigns and subfolders within it.

campaign_folder_delete

Get a campaign folder by ID. Returns folder name, parent relationship, and the campaign IDs within the folder.

campaign_folder_get

List all campaign folders. Returns folder IDs, names, parent relationships, and the campaign IDs within each folder.

campaign_folder_list

Update a campaign folder. Can rename or move to a different parent folder. Note: moving a nested folder to the top level is not supported by the API.

campaign_folder_update

Get detailed campaign configuration including sub-audiences and treatments. Note: is_draft indicates uncommitted config changes, not scheduling state.

campaign_get

Ideally instead of using this tool, use campaign_start_results, then campaign_get_results_query. This synchronous tool remains available for existing integrations. Get campaign results: recipient counts and revenue/profit metrics per treatment. Set aggregate=true to get one row per treatment aggregated over the whole measurement window with recipients de-duplicated across days (use this for the unique recipient count over a multi-day window — per-day counts cannot be summed). Set aggregate=false (default) for one row per treatment per delivery date. results_start is required; when results_days is omitted the window defaults to 30 days; the response echoes the supplied values as window_start/window_days. When the tenant's transactions table or column names differ from the canonical Unified_Transactions, supply the optional transaction_table / col_* args; otherwise omit them to use the auto-resolved Unified_Transactions table and the default column names. When a column cannot be resolved, the affected metrics are dropped and the response lists them in omitted_metrics.

campaign_get_results

Retrieval step for queries started with campaign_start_results. Check a started campaign results query. Returns state while running and the same structured, capped rows as campaign_get_results when complete. Repeat the parameters returned by campaign_start_results.

campaign_get_results_query

List all campaigns in the tenant. Returns campaign IDs, names, status, cadence, referenced_segment_ids (the union of segment_ids, exclusion_segment_ids, and sub-audience segment IDs), and nullable ISO 8601 created_at and updated_at timestamps. Response includes `total` (total campaigns in the tenant, unfiltered) alongside `count` (campaigns in this response). Note: is_draft indicates uncommitted config changes, not scheduling state. Use offset to paginate when has_more is true.

campaign_list

Move a campaign to a folder, or to root (unfolder). Note: move-to-root (null) only works for live campaigns; draft campaigns retain their folder.

campaign_move

Schedule (activate) or unschedule (deactivate) a campaign. Requires an attached IQ segment and, within each sub-audience: at least one treatment, at most one control treatment, and weights summing to 100%. There is always an implicit 'default' sub-audience consisting of treatments not assigned to any sub-audience, and the same rules apply. WARNING: This is an external send: it requires confirm=true and safety mode 'unrestricted'.

campaign_schedule

Recommended for campaign results queries: start the query and return its execution ID promptly. Pass the returned parameters and ID to campaign_get_results_query.

campaign_start_results

Update a campaign. Only provide the fields you want to change — omitted fields are preserved automatically (read-modify-write). Treatments and sub-audiences replace the full set when provided. For adding sub-audiences or treatments, read amperity://docs/campaign-management first.

campaign_update

Get the computation graph (data lineage) showing how tables relate to each other. Returns nodes representing tables with their dependencies. Use this to understand data lineage across databases, domain tables, and CDTs.

comp_graph_get

Get upstream dependencies (tables that the given table depends on). Useful for understanding data lineage - where does this table's data come from. Searches by table name, namespace/table format (e.g., 'amperity.cdt/CDT_Name'), or exact node ID.

comp_graph_get_dependencies

Get downstream consumers (tables that depend on the given table). Useful for impact analysis - understanding what would be affected if this table changes. Searches by table name, namespace/table format (e.g., 'amperity.cdt/CDT_Name'), or exact node ID. On very large tenants the full downstream set can't be computed in time; the response then sets partial=true and returns only database-layer dependents (query/segment/journey/campaign consumers omitted).

comp_graph_get_dependents

Get current Spark compute settings (cluster sizes) for all job types. Returns sizes for bridge, ingest, domain_transform, query, stitch, stitch_report, and databases. Sizes can be: x-small, small, medium, large, x-large, xx-large. For bridge/ingest, 'x-small' means 'Heuristics Enabled' (auto-scaling). A null value indicates legacy custom overrides requiring migration.

compute_get_settings

Update Spark cluster sizes for specified job types. Only standard sizes are allowed (no custom resource overrides). Sizes: x-small, small, medium, large, x-large, xx-large. Job types: bridge, ingest, domain_transform, query, stitch, stitch_report, databases. For bridge/ingest, 'x-small' enables auto-scaling heuristics. Changes take effect on the next job run.

compute_update_settings

Compare a configuration node (CDT, database table, segment, etc.) across two versions to see exactly what changed. Returns the diff showing SQL changes, field additions/removals. Use config_history_search first to find version IDs and node paths from affected_objects.

config_history_diff_node

Get all affected node data for a configuration version. Returns actual config values for all nodes that changed - the most efficient way to see what changed in a version.

config_history_get_version_nodes

Search through tenant configuration version history. See what changed, when, and by whom. Filter by committer, affected types, or search text.

config_history_search

Preview what a config revert would change before executing it. Shows diff summary, domain table side effects, and whether engineering migrations would be undone. Always call this before config_revert_revert.

config_revert_compare_revert