ai_system_prompt_get
ChatGPTGet the tenant's AI Assistant system prompt configured in Amperity — free-text business-logic guidance the tenant has given AI features (e.g. how to interpret their tables, naming conventions, domain rules). Returns {"prompt": null} if none is configured.
alert_get_subscription
ChatGPTGet details of a specific alert subscription including email recipients and filter criteria.
alert_list_subscriptions
ChatGPTList all workflow alert subscriptions with their email recipients. Shows subscription type (courier-group, orchestration-group, campaign, journey, per-journey, ad-hoc-workflow), subscribed email addresses, and filter criteria.
alert_subscribe
ChatGPTSubscribe email address(es) to workflow alerts. Subscription types: 'courier-group' (ingest alerts), 'orchestration-group' (send alerts), 'campaign' (campaign alerts), 'journey' (all journey alerts), 'per-journey' (specific journey, requires journey_id), 'ad-hoc-workflow' (specific workflow run, requires workflow_id).
alert_unsubscribe
ChatGPTRemove an alert subscription. Deletes the subscription and cleans up the associated audience if no other subscriptions reference it. Use alert_list_subscriptions to find subscription IDs.
amp_insights_ask
ChatGPTAsk Amperity's Amps usage assistant a question about the tenant's Amps consumption, usage, billing. Example: 'Why did my Amps increase last month?' Without session_id this starts a new Amp Insights conversation; pass the session_id from a previous answer to continue the conversation.
amp_insights_get_result
ChatGPTKeep waiting for an Amp Insights answer that amp_insights_ask reported as still running, using the session_id and task_id it returned.
bridge_connect
ChatGPTConfigure inbound sync for a bridge. Creates domain tables from external data sources. Platform-specific parameters: Databricks requires 'recipient_id'. Snowflake requires 'share_name'. BigQuery requires 'project_id' and 'dataset_location' (optionally 'exchange_id', 'listing_id').
bridge_create
ChatGPTCreate a new bridge for data sharing with external platforms. Bridges support Databricks (Delta Sharing), Snowflake, and BigQuery. Snowflake bridges require snowflake_account, snowflake_org, and snowflake_region. After creation, use bridge_connect for inbound sync or bridge_create_share for outbound sharing.
bridge_create_share
ChatGPTSet tables to share outbound via this bridge. Note: This replaces the full list of shared tables. To add/remove individual tables, get the current list first with bridge_get_share.
bridge_delete
ChatGPTDelete one or more bridges. Automatically disconnects inbound syncs and removes outbound shares before deleting the bridge to prevent orphaned resources.
bridge_delete_share
ChatGPTRemove outbound share configuration from a bridge. Stops sharing tables via this bridge.
bridge_disconnect
ChatGPTRemove inbound sync configuration from a bridge. This removes the domain tables created by the sync.
bridge_download_credential
ChatGPTDownload 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_get
ChatGPTGet 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_share
ChatGPTGet outbound share details for a bridge. Returns the tables currently being shared out via this bridge.
bridge_get_sync
ChatGPTGet 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_list
ChatGPTList 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_share_tables
ChatGPTList 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_load_amperity_data
ChatGPTLoad 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_run_sync
ChatGPTRun 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_update
ChatGPTUpdate a bridge's name or description.
bridge_update_sync
ChatGPTUpdate 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_upload_credential
ChatGPTUpload 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.
build_object_url
ChatGPTBuild 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'.
campaign_create
ChatGPTCreate 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_delete
ChatGPTDelete one or more campaigns. WARNING: This permanently removes the campaigns.
campaign_duplicate
ChatGPTDuplicate an existing campaign with a new name. Creates a copy as a draft, including treatments and sub-audiences.
campaign_folder_create
ChatGPTCreate a new campaign folder. Use parent_folder_id to nest inside another folder.
campaign_folder_delete
ChatGPTDelete a campaign folder. WARNING: This also deletes ALL campaigns and subfolders within it.
campaign_folder_get
ChatGPTGet a campaign folder by ID. Returns folder name, parent relationship, and the campaign IDs within the folder.
campaign_folder_list
ChatGPTList all campaign folders. Returns folder IDs, names, parent relationships, and the campaign IDs within each folder.
campaign_folder_update
ChatGPTUpdate 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_get
ChatGPTGet detailed campaign configuration including sub-audiences and treatments. Note: is_draft indicates uncommitted config changes, not scheduling state.
campaign_get_results
ChatGPTIdeally 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_query
ChatGPTRetrieval 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_list
ChatGPTList 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_move
ChatGPTMove 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_schedule
ChatGPTSchedule (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_start_results
ChatGPTRecommended 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_update
ChatGPTUpdate 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.
comp_graph_get
ChatGPTGet 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_dependencies
ChatGPTGet 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_dependents
ChatGPTGet 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).
compute_get_settings
ChatGPTGet 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_update_settings
ChatGPTUpdate 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.
config_history_diff_node
ChatGPTCompare 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_get_version_nodes
ChatGPTGet 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_search
ChatGPTSearch through tenant configuration version history. See what changed, when, and by whom. Filter by committer, affected types, or search text.
config_revert_compare_revert
ChatGPTPreview 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_revert
ChatGPTRevert tenant configuration to a previous version. Requires sys:admin permission. Use config_revert_compare_revert first to preview changes. When called without target_id, undoes the last change (undo). With target_id, reverts to that specific version.
context_documents_create
ChatGPTCreate a user-visible company context document with inline text content. The document will be immediately enabled and available to agents via context_documents_list and context_documents_get.
context_documents_create_admin
ChatGPTCreate an Amperity-managed internal company context document (analyst notes, join recipes, framing guidance). Hidden from end users, surfaced only to agents. Internal-only tool — requires tenant-asset:internal-write permission.
context_documents_delete_admin
ChatGPTDelete any company context document including internal Amperity-managed ones. Internal-only tool — requires tenant-asset:internal-write permission.
context_documents_get
ChatGPTGet the content of a company context document by ID. Use an ID returned by context_documents_list.
context_documents_get_admin
ChatGPTGet the content of any company context document by ID, including internal Amperity-managed ones. Internal-only tool — requires tenant-asset:internal-read permission.
context_documents_list
ChatGPTList enabled company context documents for the current tenant. Returns document IDs and metadata for knowledge files that agents may safely use.
context_documents_list_admin
ChatGPTList ALL company context documents for the current tenant including internal Amperity-managed ones (analyst notes, join recipes, framing guidance). Internal-only tool — requires tenant-asset:internal-read permission.
context_documents_update_admin
ChatGPTUpdate any company context document including internal Amperity-managed ones. All fields are optional — only provided fields are changed. Internal-only tool — requires tenant-asset:internal-write permission.
core_table_analyze
ChatGPTAnalyze a core table SQL query before creating. Validates syntax, resolves dependencies, and returns the inferred fields. Use this to check for errors before creating a core table.
core_table_delete
ChatGPTDelete one or more custom core tables. WARNING: This will break any database tables that reference these core tables. Ensure no databases depend on them before deleting.
core_table_get
ChatGPTGet a single core table by name, including its full SQL query, fields, and dependencies. Use this to inspect the SQL logic of a specific core table.
core_table_get_tenant_schema
ChatGPTGet all upstream tables available for core table queries. Returns domain tables, CDTs, stitch outputs, and existing core tables that can be referenced in SQL. Use this to understand what tables you can query when building core tables. Compact by default (table names + field_count); pass include_fields=true (ideally with namespace=) to include field names.
core_table_list
ChatGPTList custom core tables. Core tables exist after Stitch but before databases, providing a single source of truth for shared SQL logic across multiple databases. Use offset to paginate when has_more is true.
core_table_upsert
ChatGPTCreate or update a core table (Spark SQL) and activate it. Core tables centralize SQL logic that can be referenced by any database. For multi-database setups, include database_key in SELECT, GROUP BY, and PARTITION BY clauses. This tool analyzes, creates/updates, and activates the core table in one step.
courier_create
ChatGPTCreate a new courier definition. Couriers pull data from external sources (S3, SFTP, Snowflake, etc.) into Amperity. Requires plugin_id, credential_id, and load_operations mapping feed IDs (df-...) to load operations. Use feed_list to find feed IDs.
courier_delete
ChatGPTDelete one or more courier definitions. WARNING: This permanently removes the courier configurations.
courier_get
ChatGPTGet a courier by ID. Returns full details including plugin type, file pattern, format, compression, feeds, and timestamps.
courier_group_create
ChatGPTCreate a new courier group. Courier groups define schedules for running multiple couriers together to ingest data. Returns the new group ID and default_run_mode (Run Type in the UI).
courier_group_delete
ChatGPTDelete one or more courier groups. WARNING: This permanently removes the courier group configurations.
courier_group_get
ChatGPTGet a courier group by ID. Returns full details including default_run_mode (labeled Run Type in the UI), schedule, timezone, enabled status, and couriers.
courier_group_list
ChatGPTList all courier groups in the tenant. Returns group IDs, names, schedules, courier counts, and default_run_mode (labeled Run Type in the UI). Use offset to paginate when has_more is true.
courier_group_run
ChatGPTRun a courier group; returns a workflow ID to monitor. This is an external send: it requires confirm=true and safety mode 'unrestricted'. A full-workflow run may trigger downstream external sends. Polling: ingest-only takes 5-15 min (poll every 2 min); full-workflow takes 15-60+ min (poll every 5 min).
courier_group_update
ChatGPTUpdate an existing courier group. Pass a partial update object whose keys match courier_group_create params; default_run_mode is labeled Run Type in the UI and is returned after the update.
courier_list
ChatGPTList all couriers in the tenant. Couriers pull data from external sources (S3, SFTP, Snowflake, etc.) into Amperity. Returns courier IDs, names, plugin types, and feed counts. Use offset to paginate when has_more is true.
courier_load_summary
ChatGPTSummarize a courier's per-feed load strategy (truncate-and-load vs. update) without exposing credentials or plugin settings. Use this -- not courier_get, which returns ingress auth material -- to answer whether a courier's feeds truncate and reload or merge/update. Returns the courier id, name, and for each feed (feed is the feed ID) a normalized load_type ('truncate_and_load', 'update', or 'unknown') plus the raw operation_types.
courier_run
ChatGPTRun a courier to trigger data ingestion from its configured source. Missing source files fail the run unless skip_missing_files is true (default false, as in the UI). Returns a workflow ID to monitor progress. POLLING: Ingestion typically takes 5-15 minutes. Wait 2 minutes, then poll every 2 minutes. Use Bash with run_in_background for sleep to let the user continue working.
courier_update
ChatGPTUpdate an existing courier definition. Pass a partial update object using the field names courier_get returns: 'name' (also accepted as 'description'), 'plugin_id', 'credential_id', 'settings', 'load_operations', plus 'source_tags' and 'pgp_credential_id' as in courier_create. The 'load_operations' keys are feed IDs (from feed_list), not feed names.
credential_list
ChatGPTList the credentials configured in the tenant. Credentials hold the secrets a plugin authenticates with; destinations and couriers reference one by id. Returns id, name, type and description only -- never secret values. Use this to find the credential_id to pass to destination_create. Use offset to paginate when has_more is true.
database_activate
ChatGPTActivate a database draft. Makes the draft version become the live version. This validates the database configuration and may fail if there are errors.
database_create
ChatGPTCreate a new database. Use templates for pre-configured setups, or create empty and add tables manually.
database_create_table
ChatGPTCreate a new table in a database. Supports Spark SQL tables (with a SELECT query) or passthrough tables (linking to a domain table). By default, auto-activates the draft so the table is immediately live. Set activate=false to batch multiple changes before activating.
database_delete
ChatGPTPermanently delete an entire database and all its tables. This is irreversible. Use database_discard instead if you only want to revert draft changes.
database_delete_table
ChatGPTDelete a table from a database. Creates a draft that must be activated with database_activate, then rebuilt with database_run.
database_discard
ChatGPTDiscard a database draft. Reverts any uncommitted changes. If the database only has a draft (never activated), this deletes the entire database.
database_get_schema
ChatGPTGet the schema (columns) for a specific table. Returns column names, types, semantic tags, and activation IDs attached to those columns. Pass draft=true for the version including unactivated changes and its IDs.
database_get_table
ChatGPTGet a table definition from a database. Returns the table type (sql or passthrough), SQL query if applicable, source table if passthrough, fields, metadata, and whether the table is versioned. Pass draft=true for the version including unactivated changes.
database_get_validation_report
ChatGPTGet the C360 validation report for a database. Returns checks like Amperity ID completeness, required fields, data consistency, etc. By default shows only failures/warnings with a compact summary. Use validation_type to drill into a specific check.
database_list
ChatGPTList all databases in the Amperity tenant. Returns database IDs, names, whether each is marked as a Customer 360 database, whether the database is automated, its currency setting, live activation_ids, and pending draft_activation_ids when present. Draft databases are included: status is "draft" for one that was never activated, and has_draft marks one with unactivated changes. Use offset to paginate when has_more is true.
database_list_tables
ChatGPTList tables in a database. Pass draft=true for a database's unactivated changes.
database_list_validation_reports
ChatGPTList recent C360 validation report history for a database (past 90 days). Returns report IDs and timestamps.
database_run
ChatGPTRun/build one or more databases in a single workflow. Triggers a workflow to regenerate the database tables. Returns a workflow ID to monitor progress. When multiple databases are specified, they share CDT and Stitch stages, avoiding redundant work. IMPORTANT: Always ask the user which build mode they want before running. Default is 'express'. POLLING: Express builds take 5-15 minutes (poll every 2 min); normal/full take 15-60+ minutes (poll every 5 min). Use Bash with run_in_background for sleep to let the user continue working.
database_update
ChatGPTUpdate database-level settings: name, description, customer_360 flag, AmpIQ toggle (amp_iq), or replace activation_ids. Omit activation_ids to preserve existing IDs; pass [] or null to clear custom IDs. Each ID requires an existing table/field and nonblank friendly_name, singular_name, and plural_name. Creates a draft that must be activated with database_activate.
database_update_table
ChatGPTUpdate a table's Spark SQL query, description, or column metadata while preserving existing field descriptions and semantics. Use this after editing a C360 table to apply new SQL and optionally override metadata for specific fields via the fields array; all other columns are carried forward unchanged. By default, auto-activates the draft so changes are immediately live. Set activate=false to batch multiple changes before activating. For passthrough tables, fields replaces the full field list (only listed fields are selected). Use database_get_table first to see current fields. Providing SQL for a passthrough table returns an error.
dataset_get_catalog
ChatGPTGet the catalog of query datasets — the same surface the in-app Queries UI exposes. Returns each dataset's dataset_id (qd-*), name, and table count. Covers the two static system datasets ('Domain tables', 'Stitch Tables') plus one dataset per Customer 360 database. Hidden tables (journey/campaign summary tables and _versioned projections) are left out of the count by default; set include_hidden to include them.
dataset_get_table
ChatGPTGet a table's column schema. Returns table name, storage ID, format, and field definitions (name, type, semantics). Call dataset_get_catalog first to discover dataset_id values.
dataset_list_tables
ChatGPTList tables in a query dataset. Returns table names and storage IDs. Tables in a database dataset carry a source of 'file upload' or 'database'. Call dataset_get_catalog first to discover dataset_id values. Hidden tables are suppressed by default; set include_hidden to surface them.
destination_create
ChatGPTCreate a new plugin destination (SFTP, S3, Snowflake, etc.). Requires a plugin_id and activation_type. Most plugins require credential_id and settings (e.g., file-type, folder).
destination_create_attribute_set
ChatGPTCreate an attribute set for a destination — the fields it sends, and what each is called at the destination. Shown in the Amperity UI as the destination's default attributes.
destination_delete
ChatGPTDelete a plugin destination and its configuration. Warning: also removes associated orchestrations and attribute sets.
destination_delete_attribute_set
ChatGPTDelete an attribute set from a destination.
destination_get
ChatGPTGet detailed destination configuration including plugin settings and credentials. For a campaign destination this also returns attribute_sets — the field mappings it can send, ready to use as a campaign's or journey graph's attributes entry, each tagged source "tenant" or "amperity". Pass database_id to include the set Amperity builds for the destination type.
destination_list
ChatGPTList all plugin destinations in the tenant. Returns destination IDs, names, plugin types, and activation types. Use offset to paginate when has_more is true.
destination_update
ChatGPTUpdate a plugin destination's settings. At least one field must be provided.
domain_table_history_get_history
ChatGPTGet row count history for a domain table over time. Shows how row counts changed across ingestion runs. Useful for monitoring data freshness, detecting ingestion anomalies, and understanding data volume trends.
domain_transform_analyze
ChatGPTAnalyze a SQL query before creating a CDT. Validates syntax and returns table references and output fields.
domain_transform_delete
ChatGPTDelete one or more custom domain tables (CDTs). WARNING: This will break any database tables or other CDTs that reference these tables. Ensure no downstream dependencies exist before deleting.
domain_transform_get
ChatGPTGet a custom domain table by ID. Returns SQL query, fields, semantics, and metadata.
domain_transform_list
ChatGPTList custom domain tables (CDTs). Returns names, types, row counts, and draft status. Use offset to paginate when has_more is true.
domain_transform_upsert
ChatGPTCreate or update a CDT (Spark SQL) and activate it. Include semantic tags, especially 'pk' for primary key. For unpacking nested JSON in domain tables, read amperity://docs/json-unpacking for Spark SQL patterns (GET_JSON_OBJECT, FROM_JSON, EXPLODE).
event_stream_delete
ChatGPTDelete one or more event streams. WARNING: this stops ingestion and also deletes every event type on the stream.
event_stream_get
ChatGPTGet an event stream, including its Recognition method, timestamp expression, event ID expression, and which profile collections consume its events: - consuming_collections: one {id, name, title} entry per collection whose subscription covers this stream, capped at 100 with consuming_collections_truncated marking a cut list. - consuming_collection_count: the untruncated number of consumers. 0 means events ingest and reach nothing. - If the collections cannot be read, both fields are omitted rather than returned empty, and hint names the failure — consumers are then unknown, never none, and only the stream's own fields are authoritative.
event_stream_get_recent_events
ChatGPTGet recent sample events from a stream for debugging, newest first. Each event has a raw payload (the inbound event) and, when accepted, a processed coerced view; invalid/unknown/ignored events carry a validation_message explaining why they were not accepted.
event_stream_list
ChatGPTList event streams. Use offset to paginate when has_more is true.
event_stream_upsert
ChatGPTCreate or update an event stream. Resolution is ID-first: - When stream_id is supplied, update exactly that stream. stream_id takes precedence over name; name, if supplied, becomes its new name. - Without stream_id, name is lowercased and matched exactly. A match is updated; no match creates a new stream. A name typo can therefore create a new stream—use stream_id when updating a known stream. Creating requires name and title; omitted recognition_method defaults to no event recognition. Updating preserves every omitted field. Explicit null clears optional fields; recognition_method resets to no recognition. Read the amperity://docs/realtime-guide resource before building a real-time pipeline.
event_type_delete
ChatGPTDelete one or more event types. WARNING: Events referencing these types will no longer be processed.
event_type_get
ChatGPTGet an event type by (stream_id, name). Returns full details including field definitions and linking keys. Each field's data_type is a type name, or an object carrying the type's configuration and any nested types — the same shape event_type_upsert accepts, so a field can be edited and passed straight back.
event_type_list
ChatGPTList event types. Event types live underneath an owning stream and are keyed by (stream_id, name). Omit stream_id to enumerate types across all streams in the tenant. Use offset to paginate when has_more is true.
event_type_upsert
ChatGPTCreate or update an event type inside an event stream. The (stream_id, name) pair identifies the type: the first call creates it, later calls update it. The name and owning stream cannot be changed in place — to rename, create a new type and delete the old one. On the update path, omitted title/fields are preserved, as is the rest of the type's configuration. Each field's expression is usually just the source property name (e.g. "cart_total"); full AEL is only for transforms. Fields can set a linking_key (shown as "keychain key" in the Amperity UI) for profile matching. The amperity://docs/realtime-guide resource covers which fields need one and the anonymous-visitor trap.
feed_delete
ChatGPTDelete one or more feeds. WARNING: If a feed is the last one referencing a domain table, that table will also be deleted.
feed_get
ChatGPTGet a feed by ID. Returns full details including domain table, courier, record count, and field schemas with semantic tags. If fields contain nested JSON data, read amperity://docs/json-unpacking for how to flatten them into CDTs.
feed_list
ChatGPTList all feeds in the tenant. Feeds define the schema and field mappings for data ingested by couriers. Returns feed IDs, names, domain tables, and field counts. Use offset to paginate when has_more is true.
feed_upsert
ChatGPTCreate or update a feed. Feeds define the schema and field mappings for data loaded by couriers. Use feed_get to retrieve an existing feed's configuration as a template. The source_id must reference a real source (use source_list to find one or source_create to make one); a feed with an unknown source is rejected so it won't become invisible in the UI.
feedback_submit
ChatGPTSubmit user feedback about Amperity or this MCP server. Tenant and user identity are attached automatically.
get_semantic_vocabulary
ChatGPTGet everything needed to activate one kind of table: the steps to follow, how that kind links to customers, the reshaping its tags require, and the valid Amperity semantic tags with the datatype each needs and the constraints that cause a write to be rejected. Call this after get_table_kinds has let you classify the table, and before you apply any semantics — the tag fields accept free-form strings, so an unlisted value is silently wrong. Key semantics (pk, ck, fk-, sk-, bk-) are returned with every kind. Static; does not call the API.
get_table_kinds
ChatGPTList the kinds of table Amperity source activation knows, each with the columns it is recognizable by, the columns that rule it out, and how it links to customers. Call this after reading a bridged table's schema and five sample rows, then read the signals against those columns and values to decide what it holds. The kind you decide on is the input to get_semantic_vocabulary, which returns that kind's tags and the steps to apply them. Static; does not call the API.
journey_create
ChatGPTCreate a new journey. Journeys orchestrate multi-step customer engagement workflows. Call journey_get_authoring_reference first — it gives the ordered build sequence. Pass the full graph as graph to create the journey and its graph in one call, returning the persisted graph. Or create it without a graph — it starts empty and you fill it in later with journey_update — when you want the journey in place before its audience or destinations are settled.
journey_delete
ChatGPTDelete one or more journeys. WARNING: This permanently removes the journeys.
journey_folder_delete
ChatGPTDelete a journey folder. The folder must be empty — unlike a campaign folder this does not cascade, so move its journeys out with journey_update's folder_id and delete its subfolders first.
journey_folder_get
ChatGPTGet a journey folder by ID. Returns the folder name and parent relationship. Use journey_list with folder_id to list the journeys in it.
journey_folder_list
ChatGPTList journey folders. Returns folder IDs, names, parent relationships, and child_count (direct journeys + subfolders). Folder membership lives on the journey, so use journey_list with folder_id to see which journeys are in a folder. Use next_token to paginate when has_more is true.
journey_folder_upsert
ChatGPTCreate or update a journey folder. Returns action='created' or action='updated'. Pass folder_id to update that folder, plus a new name or parent_folder_id. Otherwise name is the upsert key: exactly one match is updated, no match creates a new folder, and several matches fail with the candidate IDs — retry with folder_id, since folder names are not unique. Use parent_folder_id to nest a new folder or move an existing one; moving a nested folder back to the top level is not supported by the API. Folders hold journeys via journey_update's folder_id, not through this tool.
journey_get
ChatGPTGet a journey by ID. Returns full details including name, timestamps, author information, folder_id, and the journey's graph (root, nodes, edges, segments) — the body journey_update takes back, so this is the read an edit starts from. Also reports kind (batch or real_time), status (active or paused), state (a real-time journey's exact state — currently active, draining, removing, or off, though a state added to the server later passes through under its own name; null for batch), and collection_id (the profile collection a real-time journey reads, null when unset).
journey_get_authoring_reference
ChatGPTThe complete journey authoring reference, returned inline: the ordered build sequence, the graph rules, the node-type schemas (activation, wait, conditional-split, percent-split, merge), the conditional-split criteria shapes — a segment reference, inline SQL, or a visual query — destination mappings, editing and scheduling rules, and the error table. Static; does not call the API. Call this once before composing a graph for journey_create(name=..., graph=...), naming every template you want in that same call. The reference is returned in full on every call, so batching costs less than calling again.
journey_list
ChatGPTList all journeys in the tenant. Returns each journey's ID, name, kind (batch or real_time), status (active or paused), real-time state, collection_id (the profile collection a real-time journey reads, null for batch or when unset), and folder_id (null when the journey is not in a folder). Call journey_get for a journey's graph. Use offset to paginate when has_more is true.
journey_run
ChatGPTTrigger a manual run of a batch journey. WARNING: this sends data to configured destinations and may contact real customers. Real-time journeys are started with real_time_journey_activate, not here. This is an external send: it requires confirm=true and safety mode 'unrestricted'.
journey_schedule
ChatGPTSchedule (activate) a journey to fire on a recurring cadence, or once. Required to flip a newly-created journey from 'paused' to 'active' — without this step the journey will not run on its own. Registering the schedule validates the journey's graph, so an unfinished one is rejected here. Cadence-only: continuous journeys (continuous? = true) are rejected, since they require realtime destinations and a different activation path. WARNING: this is an external send operation — places the journey on a recurring schedule that will contact real customers. This is an external send: it requires confirm=true and safety mode 'unrestricted'.
journey_unschedule
ChatGPTUnschedule (deactivate) a journey by clearing its planner + schedule fields. Read-modify-write — preserves the journey's graph, description, and other configuration. Returns the journey to 'paused' status.
journey_update
ChatGPTUpdate a journey's name, description, graph, and folder. At least one of name, description, graph, or folder_id must be provided. Pass graph to replace the journey's graph in the same call, returning the persisted graph. On a journey that is already active a graph change alters what the next scheduled run sends — call journey_get_authoring_reference for the editing rules.
label_create
ChatGPTCreate a new label. Labels are lightweight tags for organizing campaigns, queries, segments, and journeys. Returns the new label ID and details.
label_delete
ChatGPTDelete a label. Removes the label from all associated objects. WARNING: This permanently removes the label.
label_get
ChatGPTGet a label by ID. Returns full details including name, color, and description.
label_list
ChatGPTList all labels in the tenant. Labels are tags for organizing campaigns, queries, segments, and journeys. Returns each label with its label_id, name, color, and description. Use offset to paginate when has_more is true.
label_update
ChatGPTUpdate a label's name and/or color.
measure_id_overlap
ChatGPTMeasure how much a table's identifier columns share values with the identifier columns of other tables. Finds every id-shaped column on both sides from their sampled values, measures each compatible pair, and also compares against every existing CDT's fk- columns. Call it for a profile table, or any table that carries an fk- tag, before choosing its key or fk- names. Pass against with every other profile source on the inventory, including ones already built as CDTs, named by their bridged source table.
orchestration_create
ChatGPTCreate a new orchestration.
orchestration_delete
ChatGPTDelete one or more orchestrations. WARNING: This permanently removes the orchestrations.
orchestration_get
ChatGPTGet an orchestration by ID. Returns full details including group membership, destination, object type/ID, and plugin settings.
orchestration_group_create
ChatGPTCreate a new orchestration group. Orchestration groups define schedules for running multiple orchestrations together to send data to destinations.
orchestration_group_delete
ChatGPTDelete one or more orchestration groups. WARNING: This permanently removes the groups. The orchestrations themselves remain.
orchestration_group_get
ChatGPTGet an orchestration group by ID. Returns full details including schedule, timezone, enabled status, and constraints.
orchestration_group_list
ChatGPTList all orchestration groups in the tenant. Orchestration groups define schedules for running multiple orchestrations together to send data to destinations. Returns group IDs, names, schedules, and enabled status. Supports client-side filtering by name and enabled status. Use offset to paginate when has_more is true.
orchestration_group_update
ChatGPTUpdate an orchestration group. Only provided fields will be updated.
orchestration_list
ChatGPTList all orchestrations in the tenant. Returns orchestration IDs, names, destination info, group membership, and last execution status. Supports client-side filtering by name, state, destination_id, and group_id. Use offset to paginate when has_more is true.
orchestration_update
ChatGPTUpdate an existing orchestration. Only provided fields will be updated.
policy_list
ChatGPTList visible policies and their backend-computed assignable status.
prediction_create_model
ChatGPTCreate a prediction model. Use this when a user wants to target customers based on predicted behavior and no existing model covers their use case (check prediction_list_models first). Model types and when to use each: pclv — predicted customer lifetime value; use for 'high-value customers', 'likely to spend', 'customer worth', revenue-based targeting. Output table: Predicted{db}_{SymbolicName}_CLVAttributes. product_affinity — product recommendations; use for 'likely to buy product X', 'recommend products', 'cross-sell', 'upsell'. Best for targeting a single specific product or category; avoid it for dynamic personalization that must dedupe audiences across a set of products, because its per-category affinity scores overlap heavily (the same customers rank at the top of many categories, so the audiences cannot be cleanly split). Output table: Predicted_Affinity_{ProductGroup} (PascalCase of product_group). epm — event propensity model; use for ANY custom behavioral prediction: 'likely to sign up', 'likely to enroll', 'likely to convert', 'likely to cancel', 'likely to renew', 'likely to attend'. The target_event defines what you're predicting. Output table: Predicted_Propensity_{EventName} (PascalCase of event_name). Parameters vary by model_type — see parameter descriptions for which types use which fields. After creating, add a variant with settings via prediction_create_variant. Optionally validate it before activating.
prediction_create_variant
ChatGPTCreate a new variant under an existing model: one candidate set of features and settings for that model's prediction objective. The server applies per-type defaults for every setting you do not explicitly provide — pass only the ones you want to override, each as its own top-level parameter (the same names prediction_get_variant returns). Only parameters valid for the given model_type are accepted; passing one that belongs to a different type is rejected. Notes: - pclv/epm _model params take 'random_forest', 'gbt', 'logistic_regression', or 'kmeans'; pair each with its _hyperparameters map (that model's own params). - model_lookback_window is an integer number of days. Minimum 180 for all types, except pclv which requires at least 1460 (4 years). Per-type default: 1460 (pclv), 730 (epm), 450 (product_affinity). - EPM requires input_events: [{database.table/name:..., event-name:..., event-date-field:...}]. Each input event must reference a distinct table. Their relationship to the parent model's target event depends on its target_event_type: for one_time_event, NO input event may use the target event's table; for repeat_event, at least one input event must reuse the target event's table and event-date-field. Violations are rejected at save time. - exclusions: [{database.table/name:..., database.field/name:..., values:...}]. After creating, optionally run a validation workflow with prediction_validate_variant(model_id=..., variant_id=...) to evaluate the variant before selecting it.
prediction_delete_model
ChatGPTDelete a predictive model and its associated database tables and variants.
prediction_delete_variant
ChatGPTSoft-delete a variant. Training artifacts are preserved and the variant is hidden from future listings.
prediction_get_model
ChatGPTGet a predictive model's full configuration by ID. Returns model type, database ID, and all model-specific settings (input tables, parameters, etc.).
prediction_get_variant
ChatGPTGet a single variant with its full raw settings payload. Use this to inspect exactly what settings a variant will train with.
prediction_get_variant_metrics
ChatGPTReturn successful validation events for a single variant. Each event contains the full validation metrics from that run. Only completed validations are included — for failed or in-progress validations, check workflow_state and workflow_error in prediction_list_variants, or use workflow_get_status with the workflow_id. Useful when comparing variants or auditing one variant's history.
prediction_list_models
ChatGPTList predictive models. Call this FIRST when a user wants to target or list customers based on predicted behavior, propensity, or likelihood — e.g., 'likely to churn', 'likely to sign up', 'likely to purchase', 'high lifetime value', 'customers who might buy X', 'product recommendations', 'personalization'. If the customer asks about customer value or churn without specifically mentioning predictions, still call this tool first. If no matching model exists, guide the user through prediction_create_model to set one up. Model types and when to use each: pclv — predicted customer lifetime value & churn; use for 'high-value customers', 'likely to spend', 'customer worth', 'likely to churn', revenue-based targeting. product_affinity — product recommendations; use for 'likely to buy product X', 'recommend products', 'cross-sell', 'upsell'. Best for targeting a single specific product or category. Avoid it for dynamic personalization that must dedupe audiences across a set of products: its per-category affinity scores overlap heavily, so the same high-affinity customers rank at the top of many categories and the resulting audiences cannot be cleanly split. epm — event propensity model; use for ANY custom behavioral prediction: 'likely to sign up', 'likely to enroll', 'likely to convert', 'likely to cancel', 'likely to renew', 'likely to attend'. Returns model IDs, types, active status, and timestamps. Use prediction_get_model for full configuration.
prediction_list_variants
ChatGPTList a model's variants — the competing candidates trained for that one prediction objective, each holding a named set of features and settings. Variants coexist and are meant to be compared, not superseded. The response is enriched with validation metrics (when a validation run has completed), the most recent workflow state, workflow_id (for use with workflow_get_status), and workflow_error (failure reason if the workflow failed), so it's the one call to drive a 'compare variants' view. The variant currently serving predictions is marked with is_selected=true.
prediction_run_model
ChatGPTRun a model once: training, inference, then the database rebuild that publishes the predictions into the database tables. The model's schedule and active status are left untouched, so this is how to score a model that should not run on a cadence. The model must already have a variant selected — set selected_variant_id with prediction_update_model first, otherwise this returns an error. To put the model on a recurring schedule instead, use prediction_update_model with active=true. The launched workflow is NAMED 'Activation predictive workflow ...' because a run reuses the activation plan, and its workflow type is 'predictive'. That name does not mean the model was activated or scheduled — it stays inactive and unscheduled. Each call launches another full run and nothing deduplicates them, so before calling again for the same model, check workflow_list for a running workflow with that name. The workflow_state field on prediction_list_variants does NOT track these runs. Use workflow_get_status to track progress. POLLING: runs typically take 1-3 hours. Wait 5 minutes, then poll every 5 minutes.
prediction_update_model
ChatGPTUpdate model settings: description, active status, selected variant, courier group, and training/inference cadences. This is also how you promote a variant — set selected_variant_id to the one that should serve predictions. ACTIVATION REQUIREMENTS: Setting active=true requires that selected_variant_id, courier_group_id, training_cadence, and inference_cadence are all set (either in this call or previously). If any are missing, the commit will fail with a validation error. You can set them all in one call. ACTIVATION WORKFLOW: When active transitions from false to true, or selected_variant_id changes while the model is already active, the server auto-launches a model-activation workflow that runs training, inference, and database builds (typically 1-3 hours). Once complete, prediction results are available in the database. Use workflow_get_status to track progress, or the user can use alert_subscribe to be notified when it completes.
prediction_validate_variant
ChatGPTTrain a variant and score it against held-out data, so its metrics can be compared with the model's other variants before one is selected. Both model_id and variant_id are required. Use workflow_get_status to track progress. POLLING: Validation workflows typically take 1-3 hours. Wait 5 minutes, then poll every 5 minutes.
profile_collection_delete
ChatGPTDelete one or more profile collections. WARNING: this permanently removes the profiles and the entire configuration — every attribute and category goes with it, and recreating the collection does not bring any of it back.
profile_collection_delete_attribute
ChatGPTDelete an attribute from a profile collection.
profile_collection_get
ChatGPTGet a profile collection by ID with full details: attributes (each with its assigned category: {id, label}), a collection-level categories list ({id, label}), and batch integration config. include_stats and include_history add live counts, showing whether real-time data is landing: 0 profiles, or a count flat across buckets, means nothing new was counted.
profile_collection_list
ChatGPTList the profile collections (real-time profile configurations): id, name, title, description. Configuration detail comes from profile_collection_get. Use offset to paginate when has_more is true.
profile_collection_run
ChatGPTLaunch the profile import workflow for a collection, recomputing profiles from its configured batch integration. The source dataset and tables come from the collection's own configuration. POLLING: Profile import typically takes 5-15 minutes. Wait 2 minutes, then poll every 2 minutes. Use Bash with run_in_background for sleep to let the user continue working.
profile_collection_set_attribute
ChatGPTAdd or update profile attributes (create-or-update by name). Takes a list, so define every attribute you need in one call — it is one backend write, all-or-nothing. Three types: - 'fact' (UI 'Database'): pulls a batch column onto the profile — pass 'source' (source_dataset/source_table/source_column); no AEL. - 'aggregation' (UI 'Event'): aggregates over events — pass 'aggregation' with an aggregator + 'target' AEL string. - 'computed': an AEL 'expression' over other attributes. AEL expressions are SQL-like strings with CALL-FORM functions — contains(x, 'y') not x contains 'y' — and single-quoted strings; full syntax in the amperity://docs/ael resource. Attributes only aggregate events received AFTER creation. Optionally set 'category' to group the attribute in the UI. The amperity://docs/realtime-guide resource covers attribute ordering, the aggregator list, and when a backfill run is and is not needed.
profile_collection_upsert
ChatGPTCreate or update a profile collection for real-time profiles. Resolution is ID-first: - When collection_id is supplied, update exactly that collection. It takes precedence over name, and an ID that no longer exists fails rather than creating anything. - Without collection_id, name is lowercased and matched against the symbolic names. One match is updated; no match creates a new collection. Nothing enforces name uniqueness, so several matches error and list the colliding IDs — pass collection_id to pick one. Creating requires name, title, dataset_name and subscribed_streams. Updating preserves every omitted field; explicit null clears optional fields. subscribed_streams and state cannot be cleared; set state to off to disable automatic refresh. The symbolic name and dataset_name are fixed at creation, so passing a different value for either on the update path is an error. Read the amperity://docs/realtime-guide resource before building a real-time pipeline.
profile_list_segments
ChatGPTList the real-time segments a profile currently belongs to — the natural next question after profile_lookup when asking why someone is or is not being targeted. Requires PII read permissions.
profile_lookup
ChatGPTLook up one individual's live profile in a profile collection, by profile ID or by a keychain key such as an email or loyalty ID. Use it to confirm an event configuration landed: read back the attribute an aggregation should have written. Returns links (the profile's keychain) and attributes (computed by the event pipeline; unset ones are null). Returns real customer PII and requires PII read permissions.
queries_activate
ChatGPTActivate a query draft. Makes the draft version become the live version.
queries_create
ChatGPTCreate a saved Presto SQL query (seg-xxx). Use for 'query', 'visual query', or 'report'. For 'segment' or 'audience', use segment_create. Criteria uses VQL v2 (AND-only; no complex clauses or segment/upload sources). Activate with queries_activate.
queries_delete
ChatGPTDelete one or more saved SQL queries. WARNING: This permanently removes the queries.
queries_discard
ChatGPTDiscard a query draft. Reverts to the live version. If the query only has a draft (never activated), this deletes the query.
queries_get
ChatGPTGet a saved query by ID. Returns full query details including SQL/criteria and orchestration_ids. Only works with 'seg-xxx' IDs. For IQ segments ('mx-seg-xxx'), use segment_get.
queries_list
ChatGPTList saved queries (seg-xxx). Use for 'query', 'visual query', or 'report'. For 'segment' or 'audience', use segment_list. Use next_token to paginate when has_more is true (cursor pagination is unavailable when filters are set — refine the filter or raise limit instead). Includes orchestration_ids by default (set include_orchestration_ids=false to skip the extra API call).
queries_move
ChatGPTMove a query to a folder, or to root (unfolder). Does not create a draft — takes effect immediately.
queries_run
ChatGPTRun a saved SQL query and return results. Executes the query's SQL and returns rows directly. The query must be activated first. A '-' in a column marked redacted:true means the value is redacted, not missing. Redaction covers columns computed from PII this credential can't read, or from expressions the check can't trace; filters still run on real values, so COUNT(*) ... WHERE col IS NOT NULL gives a real count. If a rewrite is still redacted, simplify the expression. Redacted results mean this credential lacks PII access: don't probe with PII filters or try to reconstruct values, use aggregates. Unredacted results mean the user has access: run the lookup they asked for.
queries_update
ChatGPTUpdate an existing saved query. Can update Presto SQL (query parameter), criteria JSON, or visual_query (raw VQL). IMPORTANT: Criteria compiles to VQL v2 which only supports AND between filter groups (no OR) and rejects source.complex/mxs_id/upload_id. For complex boolean logic use raw SQL; for complex clauses use segment_update. Creates/updates a draft that must be activated with queries_activate.
query_folder_create
ChatGPTCreate a new query folder. Use parent_folder_id to nest inside another folder.
query_folder_delete
ChatGPTDelete a query folder. WARNING: This also deletes ALL queries, segments, and subfolders within it.
query_folder_get
ChatGPTGet a query folder by ID.
query_folder_list
ChatGPTList all query folders. Folders organize saved queries (seg-xxx). For IQ segment folders (mx-seg-xxx), use segment_folder tools. Nested folders have a folder_id pointing to their parent. Use offset to paginate when has_more is true.
query_folder_update
ChatGPTUpdate a query folder. Can rename or move to a different parent folder. Set remove_parent to true to move a folder to the top level.
query_get_column_stats
ChatGPTGet column statistics: row count, null rate, distinct count, min/max, and is_unique. Use is_unique to validate that a column can be used as a primary key. Target options: (1) 'Domain tables' - analyze raw source data from feeds/bridges and CDTs (pre-Stitch). (2) 'Stitch tables' - analyze Stitch outputs. (3) database_id - analyze C360 database tables.
query_get_results
ChatGPTFetch the results of a previously-run query execution by its execution_id. Use this to re-read a query's output later in a conversation instead of re-running the same SQL — e.g. after query_run returned an execution_id you want to reference again. Results are read from the query's durable output, so use limit/offset to page through a large result set without re-running the SQL. If the query is still running, this returns its state and no rows rather than an error; call again later. Results may expire; if the execution_id is no longer available, re-run the original query. A '-' in a column marked redacted:true means the value is redacted, not missing. Redaction covers columns computed from PII this credential can't read, or from expressions the check can't trace; filters still run on real values, so COUNT(*) ... WHERE col IS NOT NULL gives a real count. If a rewrite is still redacted, simplify the expression. Redacted results mean this credential lacks PII access: don't probe with PII filters or try to reconstruct values, use aggregates. Unredacted results mean the user has access: run the lookup they asked for.
query_run
ChatGPTExecute an ad-hoc Presto SQL query and return results. Target options: (1) 'Domain tables' - query raw source data from feeds/bridges and Custom Domain Tables (CDTs) BEFORE Stitch processing. Useful for data quality investigations, debugging unexpected results, comparing source vs. transformed data, and inspecting JSON columns. If you find columns containing JSON strings, read amperity://docs/json-unpacking for how to flatten them into CDTs. (2) 'Stitch tables' - query Stitch outputs including unified_coalesced, unified_preprocessed_raw, stitch_scores, unified_changes_clusters, unified_changes_pks, unified_compliance, and distribution tables (phone_distribution, email_distribution, address_distribution, fk_distribution). (3) database_id - query a C360 database's tables.
real_time_journey_activate
ChatGPTActivate an off real-time journey. This validates the current graph and all referenced destinations before setting the journey active. Only off -> active is supported; batch, already-active, draining, and removing journeys are rejected. Use real_time_journey_pause to stop further sends; in-flight travelers finish by default. This is an external send: it requires confirm=true and safety mode 'unrestricted'.
real_time_journey_create
ChatGPTCreate a real-time journey — the tool to use for one. Real-time journeys admit travelers continuously, entering them on real-time segment membership. Prefer this over journey_create for a real-time journey: it is the collection-aware path, and it is where the real-time graph rules and the profile-collection check live. Call real_time_journey_get_authoring_reference first — it gives the ordered build sequence, the node schemas, and the graph rules. The new journey is created off and sends nothing until real_time_journey_activate validates and activates it. Branch on result: "incomplete" means the journey committed and read back fine but has no profile collection, so it processes nobody and cannot be activated safely until one is set with real_time_journey_update.
real_time_journey_get_authoring_reference
ChatGPTThe complete real-time journey authoring reference, returned inline: the ordered build sequence, the graph rules, the entry trigger (inclusion_segments), the node-type schemas, the profile-collection requirement, and the error table. Static; does not call the API. Call this once before composing a graph for real_time_journey_create(name=..., graph=...). The reference is returned in full on every call, so one call is enough.
real_time_journey_pause
ChatGPTPause an active real-time journey by draining or removing its travelers. Pass traveler_handling='drain' (default) to let existing travelers finish, or 'remove' to discard in-flight travelers. The returned state is draining or removing; handling is asynchronous and the journey does not transition to off automatically. Remove always requires confirm=true, including on a sandbox.
real_time_journey_traveler_status
ChatGPTWhere a profile is in real-time journeys. Pass journey_id to ask where it sits inside that one journey — every concurrent traveler instance it holds, each with the node it is waiting at, when that wait expires, and its entry and exit times. An event-keyed journey can run one profile several times at once, and those instances are reported separately rather than merged. Pass collection_id instead to ask which real-time journeys it is traveling at all, including ones that are draining or removing travelers. Read-only, and real-time only: a batch journey keeps no per-profile traveler state. For whole-journey counts rather than one profile, use journey_get(include_traveler_counts=true).
real_time_journey_update
ChatGPTUpdate a real-time journey's name, description, graph, folder, or profile collection. At least one of them must be provided. graph is a full replacement, not a merge. A batch journey is rejected up front, pointing you at journey_update. Call real_time_journey_get_authoring_reference for the graph rules and the editing constraints — on a journey already activated in the UI a graph change alters what it sends to the next traveler who enters. Branch on result: "incomplete" means the update committed and read back fine but the journey has no profile collection, so it processes nobody even once activated, until one is set.
real_time_segment_delete
ChatGPTDelete one or more real-time segments.
real_time_segment_folder_get
ChatGPTGet a real-time segment folder by ID.
real_time_segment_folder_list
ChatGPTList real-time segment folders. Returns folder IDs, names and parent relationships. Folder membership lives on the segment, so read a segment's folder_id from real_time_segment_get or real_time_segment_list, and set it with real_time_segment_upsert. The route returns every folder at once, so there is no pagination. Creating, renaming and deleting these folders is only possible in the app.
real_time_segment_get
ChatGPTGet a real-time segment by ID. Returns the segment query (AEL expression). Set include_state to also return member_count and backfill_status, or include_members to also return a sample of the member profile IDs.
real_time_segment_list
ChatGPTList all real-time segments. Real-time segments evaluate against profile attributes using AEL expressions (different from SQL segments). Returns one page per call — pass next_token to page when it is non-null.
real_time_segment_upsert
ChatGPTCreate or update a real-time segment with an AEL query expression. Only segment_id selects an existing segment: - With segment_id, update exactly that segment. An ID that no longer exists fails rather than creating anything. - Without segment_id, this only ever creates, and name, collection_id and query are all required. The name is not an identity key — nothing enforces uniqueness within a collection, so a name already in use creates a second segment unless the backend rejects it. To edit an existing segment, look its ID up with real_time_segment_list first. Updating preserves every omitted field. Both the name and the collection are mutable: a different collection_id moves the segment there. The amperity://docs/realtime-guide resource covers segment query patterns and the null-comparison traps.
safety_get_mode
ChatGPTGet the current safety mode for write operations. Modes: 'unrestricted' (no restrictions), 'confirm' (require confirmation on production), 'strict' (sandbox-only writes), 'read_only' (no safety-gated writes).
safety_set_mode
ChatGPTSet the safety mode for write operations. Modes: 'unrestricted' - no warnings or confirmations, full send; 'confirm' - require confirm=true for writes on production tenants; 'strict' - writes only work on sandbox tenants; 'read_only' - block safety-gated writes on all tenants.
sandbox_compare
ChatGPTCompare sandbox configuration with parent tenant. Detects changes and conflicts. Use direction='pull' to see what would be pulled from parent, direction='push' to see what would be pushed to parent. Returns changes, conflicts, and whether merge is safe.
sandbox_create
ChatGPTCreate a new sandbox from the current tenant. The current tenant becomes the parent. The sandbox inherits the parent tenant's billing automatically. Returns a job ID to poll for completion. Use tenant_info to verify you're on the parent tenant before creating a sandbox. IMPORTANT: This is a write operation that creates a new tenant.
sandbox_create_admin
ChatGPTInternal: create a sandbox with an explicit billing type. Same as sandbox_create but adds billing control for Amperity employees. Omit billing to inherit the parent tenant's billing. IMPORTANT: This is a write operation that creates a new tenant.
sandbox_delete
ChatGPTDelete (depose) one or more sandboxes. Sets the sandbox tenant state to 'deposed'. IMPORTANT: This must be called from the PARENT tenant, not the sandbox itself. Use tenant_use to switch to the parent tenant first.
sandbox_get_create_status
ChatGPTPoll for sandbox creation job status. Use the job_id returned from sandbox_create to check if creation is complete. Returns state: pending, running, succeeded, or failed.
sandbox_get_merge_warnings
ChatGPTGet pre-merge warnings. Checks for conditions that might affect merge, such as workflows currently running in parent tenant.
sandbox_get_status
ChatGPTGet sandbox sync status. Returns count of updates available to pull from parent and count of unmerged local changes. ONLY works on sandbox tenants. Use tenant_info to check if current tenant is a sandbox.
sandbox_pull
ChatGPTPull changes from parent tenant into sandbox. Merges parent configuration into this sandbox. Use sandbox_compare direction='pull' first to preview changes and detect conflicts. If conflicts exist, provide resolutions parameter.
sandbox_push
ChatGPTPush sandbox changes to parent tenant. Promotes sandbox configuration to production. CAUTION: This modifies the parent tenant. Use sandbox_compare direction='push' first to preview changes. Requires authorization on parent tenant.
segment_activate
ChatGPTActivate an IQ segment draft, making it live. The segment's SQL query is validated before activation - it must return exactly one column (the activation ID's field, amperity_id by default) and reference valid tables. The database must be built.
segment_create
ChatGPTCreate an IQ segment (mx-seg-xxx). Use for 'segment' or 'audience'. NOT for 'query' or 'visual query' - use queries_create for those. IQ segments return a single identifier column: the field of the segment's activation ID. Set activation_id to key the segment on something other than amperity_id (e.g. households); it is not inferred from the query. Provide Presto SQL (statement), criteria JSON, or visual_query (raw VQL). Criteria uses VQL v5 (full boolean AND/OR). Activate with segment_activate. Before writing criteria for a visual segment, call visual_segment_get_authoring_reference: it lists every operator, value shape, source, and complex clause. If that tool isn't available, read amperity://docs/criteria-format. Example criteria: {"results": {"database_id": "db-xxx", "table": "Customer360"}, "include": {"between_filters": "and", "filters": [{"within_filter": "and", "clauses": [{"predicate": {"field": {"name": "FirstName", "type": "string"}, "op": "is", "value": "Derek"}}]}]}}
segment_delete
ChatGPTDelete one or more IQ segments. Deletes both draft and activated segments.
segment_folder_create
ChatGPTCreate a new IQ segment folder. These folders organize IQ segments (mx-seg-xxx) on the Segments page, separate from query_folder (which organizes saved queries). Use parent_folder_id to nest inside another folder.
segment_folder_delete
ChatGPTDelete an IQ segment folder. WARNING: This also deletes ALL IQ segments and subfolders within it.
segment_folder_get
ChatGPTGet an IQ segment folder by ID.
segment_folder_list
ChatGPTList all IQ segment folders. Folders organize IQ segments (mx-seg-xxx) on the Segments page. Returns id, name, and parent folder_id for each folder. Use segment_list to see which segments are in each folder (returns folder_id on each segment).
segment_folder_update
ChatGPTUpdate an IQ segment folder. Can rename or move to a different parent folder. Set remove_parent to true to move a folder to the top level.
segment_get
ChatGPTGet an IQ segment by ID. Returns full segment details including statement/criteria, database info, folder, and status. For general-purpose queries (seg-xxx), use queries_get instead.
segment_list
ChatGPTList IQ segments (mx-seg-xxx). Use for 'segment' or 'audience'. NOT for 'query' or 'visual query' - use queries_list for those. Use offset to paginate when has_more is true.
segment_update
ChatGPTUpdate an IQ segment. Can update Presto SQL (statement), criteria JSON, or visual_query (raw VQL). Criteria uses VQL v5 (full boolean logic); call visual_segment_get_authoring_reference before writing it, or read amperity://docs/criteria-format if that tool isn't available. Use segment_get first to retrieve existing criteria if modifying. For draft segments, changes are saved to the draft. For activated segments, changes are applied directly.
session_start
ChatGPTStart an MCP session in multi-user hosted mode and get a session_token. When session_token is advertised, call session_start before tenant_use and tenant_use before tenant_info; tenant_list may be called before or after session_start. If session_token is not advertised, session_start is unnecessary. Pass the returned session_token to every subsequent tool that advertises session_token. The token scopes your tenant selection and safety mode to this conversation, so separate conversations under one login stay isolated. In multi-user hosted mode, returns {"session_token": "<opaque string>"}.
signal_board_delete
ChatGPTDelete one Signal board by id, and every card on it. A card's board is fixed at creation, so cards cannot outlive their board. Destructive; confirm with the user first. Revertable via the tenant's config history.
signal_board_get
ChatGPTGet one Signal board's full config (title, position, viz_ids) by id. viz_ids is the board's cards in render order.
signal_board_list
ChatGPTList the tenant's Signal dashboard boards (tabs), in tab order. Start here when the user asks about or wants to change the dashboard. The dashboard renders solely from these boards and their cards, so an empty list means an empty dashboard; create a board, then add cards to it.
signal_board_upsert
ChatGPTCreate or update a Signal board using ID-first resolution. Pass board_id to update an existing board (only the fields you pass change); omit it to create a new one, which requires title and position. position is not unique and tabs at the same position order arbitrarily, so call signal_board_list first and pick one no board is using. A board is created empty, so viz_ids is only meaningful on update, where it reorders the cards already on the board and is written whole. saved_filters are the board's own filters, applied to every card on it and anded with whatever the viewer picks in the filter bar — they narrow a board's scope and cannot be widened from the dashboard. They are written whole; pass null to clear them, omit to leave them unchanged. fiscal_calendar names the table a board's fiscal grains are measured on and the columns to read it by, for a tenant whose year is twelve fiscal months of four or five weeks rather than twelve calendar months; a fiscal grain is offered only where its column is named. It is written whole and clears the same way, null for a board coming off its fiscal calendar. Boards are tabs behind a switcher and the page opens the tenant's default -- its first by position -- so call signal_get_authoring_reference before adding one. The result's url opens this board. Outside the in-product Signal chat, tell the user to reload the dashboard afterward.
signal_get_authoring_reference
ChatGPTThe Signal dashboard authoring reference, returned inline. mode="setup" (default) is the full build reference, for an empty dashboard or a build or rebuild. mode="edit" is the card contract, validation and catalog, for any other change. Static; does not call the API. Call it before writing Signal config, and again after any turn that dropped it from context: wrong config commits silently, so cards written without it save and then fail at render.
signal_viz_delete
ChatGPTDelete one Signal card by id, dropping it from its board's layout. Destructive; confirm with the user first. Revertable via the tenant's config history.
signal_viz_get
ChatGPTGet one Signal card's full config (viz_type, title, board_id, database_id, table, date_column, dimension, measure, filter, format) by id. Fetch this before editing so you author from the authoritative definition, not just the rendered chart.
signal_viz_list
ChatGPTList a Signal board's cards, in the order the board lays them out. Without a viz_type every kind on the board comes back. Use signal_board_list to find the board.
signal_viz_upsert
ChatGPTCreate or update a Signal card using ID-first resolution. Pass viz_id to update an existing card (fetch it first with signal_viz_get; only the fields you pass change); omit it to create a new one, which needs viz_type, title, board_id, database_id, table, and the fields that kind declares — measure for a metric, dimension and measure for a stacked bar. A card's windows restrict on order_datetime unless it names a date_column; a table keyed on anything else must name one, and every card on one table must name the same one. A card's board is fixed at creation, so board_id is not accepted on update; to move a card, delete it and create it on the other board. Write real column names from the card's table — read them with database_get_schema. No field takes a token, a date predicate, SELECT/FROM, or a leading AND: the service builds the statement, wrapping the measure in the period windows, ANDing the filter bar in, and ranking a stacked bar's bands. Nothing validates measure at write time — a typo commits and renders blank — so run it with query_run first. Always pass a description: it is what the reader sees the card as, and an update that changes what the card measures must rewrite it in the same call. Call signal_get_authoring_reference before composing cards: it carries the identity-trap rules and the card catalog. The result's url opens the card's board. Outside the in-product Signal chat, tell the user to reload the dashboard afterward.
slice_create
ChatGPTCreate a database export slice. A slice defines which tables from a database should be exported. Use the returned slice_id to create an orchestration with object_type='slice'.
slice_delete
ChatGPTDelete a database export slice. Any orchestrations using this slice will need to be updated or deleted.
slice_get
ChatGPTGet a database export slice by ID. Returns the slice name, source database, and list of tables included.
slice_list
ChatGPTList database export slices (data exports). Slices define which tables from a database to export. Use with orchestrations (object_type='slice') to send table data to destinations. Use offset to paginate when has_more is true.
slice_update
ChatGPTUpdate an existing database export slice. Can change name, tables, or even source database (within same resource group).
source_create
ChatGPTCreate a data source and return its server-generated id (starts with 'ds-'). Create or select a source before feed_upsert so the feed is visible in the UI. Names are not deduped — each call makes a new source.
source_delete
ChatGPTDelete one or more data sources. A source that still has feeds is refused; delete its feeds with feed_delete first (feed_list shows each feed's source_id).
source_list
ChatGPTList data sources. Sources are the simple objects feeds attach to (id prefix 'ds-'); the UI groups feeds under their source. Use this to find an existing source before feed_upsert.
spark_get_application
ChatGPTResolve a build run_id to a Spark application ID. Works for database builds and CDT (Custom Domain Table) builds. The run_id comes from table_run_history (e.g., 'db-gen-20260223-69227-Ab7ffWDESt6'). Returns the app_id needed for spark_list_jobs, spark_list_stages, and spark_get_stage. Note: Spark History Server data is semi-ephemeral — older completed jobs may return 404.
spark_get_environment
ChatGPTGet Spark configuration with key performance settings highlighted. Shows spark.sql.shuffle.partitions, autoBroadcastJoinThreshold, AQE settings, executor memory/cores, and driver memory. Requires run_id and app_id from spark_get_application.
spark_get_sql
ChatGPTGet full SQL execution detail including physical plan. Returns the physical plan text that shows the query execution strategy, plus the stage IDs involved. Use this to understand WHY a stage is slow. Requires run_id and app_id from spark_get_application, execution_id from spark_list_sql.
spark_get_stage
ChatGPTGet aggregated task metrics for a Spark stage with skew detection. Returns pre-aggregated quantile metrics (p5, p25, p50, p75, p95) for duration, shuffle read/write, spill, and GC time. Also computes diagnostic indicators: skew ratios (p95/p50), spill flags, and GC pressure. High skew_ratio (>10x) suggests data skew. Non-zero spill indicates memory pressure. Requires run_id and app_id from spark_get_application, and stage_id from spark_list_jobs.
spark_list_executors
ChatGPTList Spark executors with health metrics and failure detection. Shows memory utilization, GC ratio, failed tasks, and excluded executors. Failed or excluded executors indicate memory pressure — consider increasing cluster size. Requires run_id and app_id from spark_get_application.
spark_list_jobs
ChatGPTList Spark jobs for a build application (database or CDT builds). Returns jobs sorted by duration (descending) by default, with pagination. Includes computed duration_ms and table names extracted from job descriptions. Use this to identify which tables are slow. Requires run_id and app_id from spark_get_application.
spark_list_sql
ChatGPTList SQL executions for a Spark application with durations, stage mappings, and table names. Maps stage IDs to SQL operations — use this to find which SQL query caused a slow stage. Requires run_id and app_id from spark_get_application.
spark_list_stages
ChatGPTList Spark stages for a build application (database or CDT builds). Returns stages sorted by executor runtime (descending) by default, with pagination. Use this to identify the slowest stages before drilling into task-level metrics. There can be thousands of stages — use limit/offset to paginate. Requires run_id and app_id from spark_get_application.
spark_list_storage
ChatGPTList cached RDDs with partition counts and memory usage. Flags high partition counts (from unions) and partial caches. Only shows currently-cached RDDs — run during an active build for best results. Requires run_id and app_id from spark_get_application.
stitch_explain_pair
ChatGPTExplain why two records were or were not clustered together by Stitch. This is the MCP equivalent of the Stitch clustering explainer UI tool. Returns diagnostic info including: whether records were found, if they're in the same cluster, pairwise score (if Unified_Scores is enabled), and interpretation hints explaining the result. Use this to investigate identity resolution decisions.
stitch_get_benchmark_examples
ChatGPTGet example clusters for a Stitch benchmark. Returns sample clusters demonstrating the benchmark test case (e.g., records with multiple surnames). Use for QA grading. Requires PII read permissions.
stitch_get_benchmark_history
ChatGPTGet historical values for a benchmark across recent Stitch runs. Returns values from the 5 most recent reports to track quality trends over time.
stitch_get_report
ChatGPTGet a Stitch report with deduplication metrics. Returns the report state, job info, and detailed results including dedupe rates, cluster statistics, and quality metrics. Use without report_id to get the latest report.
stitch_get_settings
ChatGPTGet Stitch identity resolution settings, list persisted identity graphs, or list manual bad values. Use view='id_graphs' to discover graph IDs, then view='settings' with id_graph_id to read one graph. The id_graphs view returns id_graphs: [{id, sql_name, friendly_name, description?, identifier_entity_name?}]. The manual_badvalues view returns the default graph's hand-entered bad values (manual_badvalues: [{semantic, value, is_preprocessed}]); the values are customer PII and require the pii:read permission. is_preprocessed=true means Stitch uses that value as-is instead of normalizing it like record values. The settings view returns id_graph_id when selected plus current configuration including: ignore_jitter (jitter alert suppression), badvalues_config (automatic blocklist thresholds), threshold (match score), blocking_strategies, available_tables (tables being stitched), rules (custom match/conflict rules including predicates and scoring base model), compound_blocking_strategies (saved multi-field blocking keys only; Stitch adds further strategies from match-if rules when it runs, including the bk-rule-N ones, and those never appear here), and other Stitch parameters.
stitch_list_benchmarks
ChatGPTList available benchmarks for a Stitch report. Returns benchmark names like 'multiple-surnames', 'shared-name-email', etc. Use these names with get_benchmark_examples. Use offset to paginate when has_more is true.
stitch_list_recent_reports
ChatGPTList recent successful Stitch reports. Returns recent reports with their IDs and completion timestamps. Use this to find report IDs for detailed analysis. Use offset to paginate when has_more is true.
stitch_lookup_record
ChatGPTLook up a record's Amperity ID by its datasource and primary key. Returns the cluster assignment and whether it's in a supersized cluster. Use this for quick lookups; use stitch_explain_pair for detailed clustering analysis.
stitch_run
ChatGPTTrigger a Stitch run to process identity resolution. Returns a workflow_id that can be used to track job progress. Use this after configuring Stitch settings and CDTs to execute identity resolution. Monitor the job with workflow_get_status. POLLING: Stitch runs typically take 10-60+ minutes. Wait 5 minutes, then poll every 5 minutes. Use Bash with run_in_background for sleep to let the user continue working.
stitch_set_table_availability
ChatGPTMake domain tables available (or unavailable) to Stitch for identity resolution. IMPORTANT: After creating and activating CDTs, you MUST call this to make them available to Stitch before running a Stitch job. Tables must be activated CDTs. This always updates the default graph; secondary graphs are read-only through this tool.
stitch_update_settings
ChatGPTUpdate Stitch identity resolution settings. Use ignore_jitter=true during initial setup to suppress jitter alerts, then set to false after go-live. Use badvalues_config to set automatic blocklist thresholds (e.g., block email if it appears with >20 given names). Use force=true to enable 'Force Stitch to Run' (forces a full Stitch run even when no new data has been ingested). Use manual_badvalues to add or remove specific email, phone, given-name or surname values Stitch must never match on, the same list as the Bad values tab in Stitch settings; this requires the pii:read permission. Values already present are skipped, and removing a value that is not present fails before anything is written. Send manual_badvalues on its own: a call sets either manual_badvalues or the other settings, not both. These settings always update the default graph; secondary graphs are read-only through this tool.
support_ticket_create
ChatGPTFile an Amperity support ticket when the user asks for one, or when a problem needs Amperity staff to act and no tool can resolve it. Summarize the issue in the description: what was expected, what happened, when it started, and the names of the affected resources. Tenant and user identity are attached automatically, and the ticket is stamped as agent-filed, so do not write that into the description yourself. Existing tickets are not visible here: send the user to https://help.amperity.com to view and manage the tickets they have submitted.
survey_bridged_tables
ChatGPTList every table the tenant's bridges bring in and return each one's columns with example values from 5 sampled rows, in one call. Use it whenever a request covers the tenant's bridged data as a whole rather than tables the user names: planning how to implement the data sources, taking an inventory, or finding a kind of data. Call it before grouping or planning anything. The result leads with how many tables are in the inventory, how many were sampled, and which could not be, with why. Pass tables to sample only those, such as to retry the ones reported as unchecked.
table_run_history_get_run
ChatGPTGet details for a specific run including tables, build times, and Spark utilization %. Use for build performance analysis. By default, tables with status='skipped' (reused from a prior run) are filtered out and counted under each group's 'reused_count'.
table_run_history_get_table_history
ChatGPTGet run history for a specific database table or CDT. Returns build events with edit tracking between runs. Use for performance trending and to see when tables were modified.
table_run_history_list_runs
ChatGPTList recent table run history runs (database / CDT builds). Returns run IDs, entity info, workflow IDs, and timestamps. Use this to find runs for performance analysis. Use offset to paginate when has_more is true.
tenant_info
ChatGPTGet information about the current Amperity tenant. Returns tenant id and display name, environment (dev/prod), whether this is a sandbox tenant, and the parent tenant id if applicable. To find the parent tenant of a sandbox, call this tool and read the parent_id field — it is reported authoritatively; never infer the parent from the tenant name. parent_id is present only when the current tenant is a sandbox with a parent. In multi-user hosted mode, when session_token is advertised, call session_start before tenant_use and tenant_use before tenant_info; tenant_list may be called before or after session_start. IMPORTANT: Call this BEFORE making any write operations to understand if you're operating on a production tenant or a sandbox. Sandbox tenants are safe for experimentation; production tenants require more caution.
tenant_list
ChatGPTList Amperity tenants. Parent tenants only by default (test-flagged excluded), paginated with lean fields. Use tenant for one tenant and its sandboxes, name_filter to search by id/display name, limit/offset to page, verbose=true for billing/expiry/flags.
tenant_resync
ChatGPTRefresh the local tenant cache from the Amperity API. Use this to discover newly created tenants or sandboxes that aren't showing up in tenant_list. Syncs from all authenticated environments (dev/prod). Dev always has tenants — 0 means auth issue (resync) or missing VPN (dev requires VPN, prod does not). Prod tenants require ConductorOne access requests.
tenant_use
ChatGPTSwitch to a different Amperity tenant. Use tenant_list to see available tenants first. RECOMMENDED: Switch to a sandbox tenant before making experimental changes, then switch back to production for read-only operations. Result may include tenant_instructions — this customer's own data conventions; follow them when analyzing their data.
training_setup_semantic_tags
ChatGPTSet up semantic tags for a training tenant using AI inference. IMPORTANT: Requires intent='setup-training-tenant' to execute. This is a wrapper for training tenant automation that: (1) lists available tabletops, (2) runs AI autoconfig to detect and apply semantic tags (given-name, surname, email, phone, address, etc.), and (3) verifies the results. Use after syncing training data via bridge_load_amperity_data. Returns tabletop status before and after tagging.
user_create
ChatGPTCreate a global user identity in the selected tenant. Does not grant access. Invitations additionally require unrestricted safety mode and confirm=true.
user_delete
ChatGPTPermanently delete one exact global identity by user_id from a parent tenant. Pass the exact selected tenant_id and stack as stale-route guards. The backend deletes the identity first, then cleans its policy attachments, so an error can occur after the identity is gone. Always requires confirm=true. Returns result, scope=global, and user_id. Failures can have outcome=unknown; do not retry until independent admin tooling verifies identity deletion, attachment residue, and the deletion event. Identity absence alone is insufficient.
user_grant_policy
ChatGPTAttach one exact direct policy to a user in the selected tenant.
user_list
ChatGPTList visible global users. Caps at 1,000; narrow filters if total exceeds it.
user_revoke_policy
ChatGPTDetach one exact direct policy from a user in the selected tenant. Pass the exact selected tenant_id and stack as stale-route guards. Returns result, user_id, and policy_id. A failed response can have outcome=unknown if the backend committed before later work failed. MCP cannot reconcile the exact attachment tuple; do not retry until independent admin tooling verifies it.
visual_segment_get_authoring_reference
ChatGPTThe complete visual segment authoring reference, returned inline: the order of operations, the criteria shape, every operator and its value shape, dates, sources (other tables, segment/query/upload membership), complex clauses for purchase and journey behavior, editing rules, and validated examples. Static; does not call the API. Call this once before writing criteria for segment_create or segment_update. Not for SQL segments or real_time_segment_* tools.
workflow_cancel
ChatGPTCancel a running workflow. Returns the workflow in 'canceling' state. Use workflow_get_status to poll for final state.
workflow_get_status
ChatGPTGet workflow status with all tasks: state, timestamps, errors, and task_state_counts. The workflow and each task carry duration_seconds (elapsed-so-far while running, final once ended), measured against the backend clock so callers can report run time without a local clock. Pass ingest_details={} for ingest_details.tables[] (table_name, feed_id, state, started_at, ended_at, duration_seconds, records_read, deduplicated, inserted, updated, errors). Add a feed_id for ingest_details.files (feed_id, items[], count, total, offset, has_more); each item has file_id, feed_id, records_read, and errors. File pagination bounds the returned rows, not the upstream report read. Per-task inputs are omitted — fetch with workflow_get_task.
workflow_get_task
ChatGPTGet one task's full detail, including inputs and full error (workflow_get_status omits inputs). Returns duration_seconds (backend-clock run time) for run-time reporting. Use to read a task's inputs before workflow_resolve_task.
workflow_list
ChatGPTList recent workflows. Filter by state, type, or search; paginate with offset when has_more. Each entry includes duration_seconds (backend-clock run time).
workflow_resolve_task
ChatGPTResolve a failed workflow task. Use workflow_get_status first to see failed tasks with their task_instance_id, inputs, and error details. Actions: - retry: Retry with same inputs. Pass 'inputs' to override for domain-specific retries (e.g., remove feeds from ingest inputs, set allow-empty-tables for stitch, adjust table-parallelism for db builds). - retry_updated: Retry with current configuration. Use when credentials or destination settings have been updated since the workflow launched. - skip: Skip this task and let the workflow continue. - relaunch: Abandon this workflow and start a fresh one from scratch. - retry_resource: Retry a failed infrastructure resource (e.g., Spark cluster). Requires resource_instance_name and resource_instance_type. - succeed: Force-mark the task as succeeded (operator-level, use with caution). Common input modifications for retry: - Ingest failures: Remove problematic feeds from inputs, or adjust max error rate - Stitch failures: Add 'allow-empty-tables?: true' to inputs - Stitch jitter: Add 'expect-jitter-for' acknowledgment to inputs - DB gen failures: Set 'table-parallelism' to disable parallel execution
