Monte Carlo
Data + AI observability — monitor and troubleshoot production-grade agents and the context they use.
Community: Submitted by a user or imported; check the owner before granting accessOnlineAPI key requiredGlobalFreeRead-only
What it can do
- Search: What it does: Find assets by name/metadata matching. Results show references to search terms, not confirmed data dependencies. Use lineage tools to verify actual data flows. The tool matches t
- Create Comparison Monitor Mac: Create a comparison monitor (MaC - Monitors as Code) in dry-run mode. Returns YAML that can be used for monitors as code. The YAML should be used as-is, stored in a YAML
- Create Custom Sql Monitor Mac: Create a custom SQL monitor (MaC - Monitors as Code) in dry-run mode. Returns YAML that can be used for monitors as code. The YAML should be used as-is, stored in a YAML
What data it sees
Do you need an account
An API key from the service settings is required
Data + AI observability — monitor and troubleshoot production-grade agents and the context they use.
Server tool list (28)
Raw names from tools/list. Only developers need these.
| search | What it does: Find assets by name/metadata matching. Results show references to search terms, not confirmed data dependencies. Use lineage tools to verify actual data flows. The tool matches the asset display name, which can include the table name, database name, and schema name. The format is database:schema.table for tables, or just an ID for other asset types. Allows searching for tables, views, dashboards, reports, and other data assets in your data catalog. Results are sorted by importance and relevance, with key assets and tables first. When to call it: * When you want to get the most important tables in your catalog. * When you need to search for a specific table, view, dashboard, or other data asset in your catalog by name. How to paginate: * This tool uses offset-based pagination. Use the `offset` and `limit` parameters to paginate through results. How to use it: * To prevent access/authorization errors, try passing the current domain_id to scope the request to the specific domain the user has access to. |
| create_comparison_monitor_mac | Create a comparison monitor (MaC - Monitors as Code) in dry-run mode. Returns YAML that can be used for monitors as code. The YAML should be used as-is, stored in a YAML structure like: montecarlo: comparison: - <returned yaml> You can add this structure in a new or existing MaC file, or under the 'meta' property of a dbt model YAML schema file. |
| create_custom_sql_monitor_mac | Create a custom SQL monitor (MaC - Monitors as Code) in dry-run mode. Returns YAML that can be used for monitors as code. The YAML should be used as-is, stored in a YAML structure like: montecarlo: custom_sql: - <returned yaml> You can add this structure in a new or existing MaC file, or under the 'meta' property of a dbt model YAML schema file. |
| create_metric_monitor_mac | What it does: Create a metric monitor (MaC - Monitors as Code) in dry-run mode. Returns YAML that can be used for monitors as code. The YAML should be used as-is, stored in a YAML structure like: montecarlo: metric: - <returned yaml> You can add this structure in a new or existing MaC file, or under the 'meta' property of a dbt model YAML schema file. How to use it: * Use the RELATIVE_ROW_COUNT metric to alert on anomalous changes in the distribution of a field. You must ALWAYS use segmentation with this metric. You must ALWAYS use AUTO operator with this metric. * Use the ROW_COUNT_CHANGE metric to alert on anomalous changes in the total row count. You must ALWAYS use AUTO operator with this metric. * Use the TIME_SINCE_LAST_ROW_COUNT_CHANGE metric to alert when the table has not been updated for an anomalous amount of time. You must ALWAYS use AUTO operator with this metric. * For the other metrics, you can use AUTO operator to alert on anomalous changes, or any of the other operators to alert on specific threshold crossings. You must ALWAYS pass fields for field-level metrics. |
| create_or_update_alert_comment | Create or update a comment on an alert. |
| create_table_monitor_mac | Create a table monitor (MaC - Monitors as Code) in dry-run mode. Returns YAML that can be used for monitors as code. Table monitors watch groups of tables for freshness anomalies, schema changes, and volume changes. They use asset selection to define which tables to monitor at the database/schema level. The YAML should be used as-is, stored in a YAML structure like: montecarlo: table: - <returned yaml> You can add this structure in a new or existing MaC file. How to use it: * Table monitors are best for broad monitoring of many tables at once (e.g., all tables in a schema). * For monitoring a single table's specific field-level metrics, use create_metric_monitor_mac instead. * Alert conditions default to freshness, schema changes, and volume monitoring if not specified. * The operator for table monitor alert conditions is always AUTO. |
| create_validation_monitor_mac | What it does: Create a validation monitor (MaC - Monitors as Code) in dry-run mode. Returns YAML that can be used for monitors as code. The YAML should be used as-is, stored in a YAML structure like: montecarlo: validation: - <returned yaml> You can add this structure in a new or existing MaC file, or under the 'meta' property of a dbt model YAML schema file. When to call it: When you want to create a validation monitor for a specific table. Validation monitors specify the conditions when an alert must be triggered. They match INVALID data. |
| get_alerts | What it does: Get alerts from Monte Carlo based on specified filters. Alerts with severity assigned are called incidents. So if a user asks for incidents look for alerts with SEV_1, SEV_2, SEV_3 or SEV_4. Alerts are created by monitors when they detect an issue. Monitors and alerts are different concepts. How to use it: * Pass alert IDs to fetch specific alerts. * Pass a time range to fetch alerts created within that range. If the range exceeds 60 days, it will be auto-clamped to the most recent 60 days and the response will include a `truncation_note` explaining what happened and how to fetch the remaining data. Always check for `truncation_note` in the response and inform the user when results were truncated. * If no time range or alert IDs are provided, the tool will default to fetching alerts created in the last 7 days. * Pass other filters to narrow down the results. * Use the cursor from the previous response to get the next page of results. * The tool returns a maximum of 100 alerts per page. When to call it: When you need to fetch alerts, or incidents, based on specific criteria, such as time range, status, severity, or other filters. How to paginate: * This tool uses cursor-based pagination. Use the `cursor` and `first` parameter to paginate through results. |
| get_asset_lineage | What it does: Get the asset lineage information from Monte Carlo using the v4 API. Trace data flow relationships. Returns empty results if no lineage is tracked. Absence of lineage does NOT confirm absence of data usage. IMPORTANT: When has_relationships is false, this means NO dependencies are tracked in that direction - do not keep searching for non-existent relationships. DO NOT fill any gaps in the lineage with assumptions. How to paginate: * This tool uses offset-based pagination. Use the `offset` and `limit` parameters to paginate through results. |
| get_audiences | Get notification audiences from Monte Carlo. Audiences are used for routing notifications and grouping monitors. They help organize who should be notified about data quality issues. |
| get_current_time | Get the current time in ISO format compatible with Monte Carlo API tools. Returns the current UTC time in ISO 8601 format (YYYY-MM-DDTHH:MM:SS+00:00), which is compatible with date parameters used in other Monte Carlo API tools like getAlerts. |
| get_domains | Get domains from Monte Carlo. |
| get_downstream_bi_reports | What it does: Finds all downstream BI assets (Tableau workbooks/worksheets, Looker dashboards/looks, Power BI reports, etc.) that transitively depend on the given source tables. Traverses the full lineage graph (up to 40 hops) and returns only BI report nodes with structured metadata. When to use: Use this instead of getAssetLineage when you specifically need to find BI reports that depend on a table. This tool handles the full graph traversal and filtering — no need to manually walk lineage edges. How to paginate: * This tool uses offset-based pagination. Use the `offset` and `limit` parameters to paginate through results. * Check `has_more` and use `next_offset` for the next page. |
| get_field_metric_definitions | Get valid metric names for a warehouse, optionally filtered by field type. Use this before creating metric monitors to discover which metrics are available. |
| get_monitors | What it does: Gets monitors from Monte Carlo based on specified filters. Returns a list of monitors with their metadata. Monitors generate alerts when they detect an issue. Monitors and alerts are different concepts. IMPORTANT: By default, the expensive 'config' field is EXCLUDED for performance. To get monitor configuration details (JSON or YAML monitor-as-code format), you MUST explicitly pass include_fields=["config"]. When to call it: When you need the configuration or runtime details of a specific monitor (by filtering using its UUID), or to query monitors based on other criteria. How to paginate: * This tool uses offset-based pagination. Use the `offset` and `limit` parameters to paginate through results. Usage Examples: Use case: fetch monitor WITH configuration details { "name": "get_monitors", "arguments": { "monitor_ids": ["<the monitor UUID>"], "include_fields": ["config"] } } Use case: fetch all monitors that reference a specific table { "name": "get_monitors", "arguments": { "mcons": ["<the table MCON>"] } } |
| get_queries_for_table | What it does: Get query logs and execution metadata for a table between a time range, filtered by type and optional facets. When to call it: - To find out the queries that create or update a table (destination) or read from a table (source). - To find out the users that are querying a table. - To find out the performance of queries that are running against a table. What it returns: Pagination metadata and query list: - `total` (int): Total queries available - `count` (int): Queries returned in this page - `offset` (int): Page offset used - `has_more` (bool): More queries exist after this page - `next_offset` (int|null): Offset for next page, or null if none - `queries` (array<object>): Query records with fields such as `query_id`, `query_hash`, `timestamp`, `user_name`, `status`, `query_snippet`, `rows_inserted`, `rows_produced`, `rows_updated`, `runtime`, `sub_category`, and `query_length`. How to paginate: * This tool uses offset-based pagination. Use the `offset` and `limit` parameters to paginate through results. |
| get_query_data | What it does: Get query metadata and time-series for a specific query occurrence day. One of query_id, query_hash, or group_id is required. When to call it: After using getQueriesForTable tool to get the full query, as the query snippets returned by getQueriesForTableare truncated. How to paginate: * This tool uses offset-based pagination. Use the `offset` and `limit` parameters to paginate through results. |
| get_table | Get the table information (ie. schema, table name, capabilities, warehouse, stats, domains, etc.) by MCON. |
| get_unmonitored_tables_with_anomalies | Find unmonitored tables that have muted table monitor anomalies in a time window. Results are ordered by importance score (descending). Use this to discover monitoring coverage gaps. |
| get_use_case_table_summary | What it does: Get table criticality counts for a specific use case. Returns the number of tables at each criticality level (HIGH, MEDIUM, LOW). When to call it: - Get a quick overview of table distribution by criticality for a use case - Before drilling into specific tables, to understand the scope **Output Schema:** Returns a dictionary with: - `totalTablesHigh` (integer): Number of HIGH criticality tables - `totalTablesMedium` (integer): Number of MEDIUM criticality tables - `totalTablesLow` (integer): Number of LOW criticality tables |
| get_use_case_tables | What it does: Get all tables associated with a specific use case. Returns tables with their criticality levels, reasoning, and golden table status. **Important:** Golden tables are the most business-critical tables in a use case. Always start by returning only golden tables (golden_tables_only=true) unless the user explicitly asks for all tables. This keeps results focused on what matters most. When to call it: - List tables that belong to a specific use case (start with golden tables only) - Find high-criticality tables for a use case - Identify golden tables within a use case How to paginate: * This tool uses cursor-based pagination. Use the `after` parameter with the `endCursor` value from the previous response's `pageInfo` to get the next page. **Output Schema:** Returns a relay connection with: - `totalCount` (integer): Total number of tables matching the query - `pageInfo`: Pagination info with `hasNextPage` and `endCursor` - `edges`: List of table edges, each containing: - `cursor` (string): Edge cursor for pagination - `node`: Table object with: - `mcon` (string): Unique table identifier (MCON) - `criticality` (string): Table criticality (HIGH, MEDIUM, LOW) - `reasoning` (string): Explanation for the criticality assessment - `isGoldenTable` (boolean): Whether this table is a golden table |
| get_use_cases | What it does: Get all use cases for a warehouse. Use cases represent business-critical data flows and help identify monitoring opportunities for data products. Each use case includes a name, description, criticality level, and the number of associated tables. When to call it: - Discover monitoring opportunities across a warehouse - List business-critical data flows and their criticality - Get an overview of use cases before drilling into specific tables How to paginate: * This tool uses cursor-based pagination. Use the `after` parameter with the `endCursor` value from the previous response's `pageInfo` to get the next page. **Output Schema:** Returns a relay connection with: - `totalCount` (integer): Total number of use cases - `pageInfo`: Pagination info with `hasNextPage` and `endCursor` - `edges`: List of use case edges, each containing: - `cursor` (string): Edge cursor for pagination - `node`: Use case object with: - `id` (string): Stable use case identifier - `name` (string): Human-readable use case name - `description` (string): Use case description - `criticality` (string): Business-level criticality (HIGH, MEDIUM, LOW) - `tableCount` (integer): Number of tables assigned to this use case |
| get_user | Get current user information from Monte Carlo. |
| get_warehouses | List all warehouses the user can access. Returns the UUID, name, and connection type for each warehouse. |
| get_validation_predicates | Get the list of supported predicates for validation monitors from Monte Carlo. Returns all available predicates that can be used when creating validation monitors, including their arity, supported types, SQL syntax, and compatibility information. |
| set_alert_owner | Set the owner for an alert. Pass an email to set, or omit owner to clear. |
| test_connection | Test the connection to Monte Carlo API with a simple query. |
| update_alert | Update an alert or incident. Only supplied fields will be updated. Declares an incident when the severity is set. Use this tool to update the status of an alert or incident or to declare an incident. |