Dotfile

Assign every selected case, to the same member or to one per case. Runs 'set_assignee' once per selected case, as a durable background job under your own permissions: you need what 'set_assignee' needs, and its bulk permission when it has one. The call returns a `bulkActionId` as soon as the job is dispatched; follow its status and counters with get_bulk_action_result or list_bulk_actions, and stop the remaining invocations with cancel_bulk_action. An invocation that already ran is not undone. `args` holds the parameters of 'set_assignee' every invocation receives. 'set_assignee' gets `case_id` from the selected case; neither can be passed. Every invocation needs `assigneeId`, from `args` or from its item's args. A parameter 'set_assignee' does not take, or a missing required one, refuses the call before the job starts; a requirement that depends on another parameter is checked per invocation, which then fails. Select the cases with exactly one of: - `entity_ids`: the ids of the cases to target. - `filter`: a json-logic filter selecting every matching case, with the column keys of the console case table. Tell the user how many cases it matches before running a write they cannot take back. - `items`: one entry per invocation, with its own parameters merged over `args`, for a parameter that differs per case. The same case may appear more than once. About 'set_assignee': Change the assignee of the case identified by `case_id`. Use this tool to assign the case to a different team member or unassign it. Parameters: - case_id: The id of the case to assign - assigneeId: The user ID of the new assignee (or null to unassign) - assigneeName: Optional display name for confirmation Use this when the user wants to: - Assign the case to themselves - Assign the case to another team member - Unassign the case (make it available for others)

bulk_set_assignee

Attach the file of a completed document order to every selected document check, one order per check. Runs 'add_document_order_file_to_check' once per selected check, as a durable background job under your own permissions: you need what 'add_document_order_file_to_check' needs, and its bulk permission when it has one. The call returns a `bulkActionId` as soon as the job is dispatched; follow its status and counters with get_bulk_action_result or list_bulk_actions, and stop the remaining invocations with cancel_bulk_action. An invocation that already ran is not undone. `args` holds the parameters of 'add_document_order_file_to_check' every invocation receives. 'add_document_order_file_to_check' gets `check_id` from the selected check; neither can be passed. Every invocation needs `document_order_id`, from `args` or from its item's args. A parameter 'add_document_order_file_to_check' does not take, or a missing required one, refuses the call before the job starts; a requirement that depends on another parameter is checked per invocation, which then fails. Select the checks with exactly one of: - `entity_ids`: the ids of the checks to target. - `filter`: a json-logic filter selecting every matching check, with the column keys of the console check table. Tell the user how many checks it matches before running a write they cannot take back. - `items`: one entry per invocation, with its own parameters merged over `args`, for a parameter that differs per check. The same check may appear more than once. About 'add_document_order_file_to_check': Attach the file of a completed document order to a document check. Parameters: - document_order_id: The id of the document order whose file to attach (from list_document_orders); only completed orders have a file - check_id: The id of the document check to attach the file to; the check must accept new files (not approved or already under review) After the document analysis, the check is submitted for review so it becomes eligible for AI review.

bulk_add_document_order_file_to_check

Buy fresh company profile data for an existing company from a business data vendor, under the vendor contract the workspace is configured with (Dotfile's or the workspace's own), as a company data fetch from the console does. Every call is a new purchase request to the vendor. Once the vendor returns the data, the purchase is recorded as company data usage of the workspace and counts toward its plan limit; a call is refused once the limit is reached. On the workspace's own contract the vendor bills the workspace; on Dotfile's contract Dotfile bills the usage, except on trial and internal workspaces. There is no deduplication, so buying twice is a second purchase. This tool sells no Dotfile subscription, plan or credit. Check how recent the current data is before buying; the result includes when the previous data was fetched. Parameters: - company_id: The id of the company to buy data for - vendor: The vendor to buy from; omit to buy from the vendor of the company's most recent purchase After a purchase, use get_company_data_changes to compare the refreshed data with the previous snapshot.

buy_company_data

Buy fresh company profile data from a business data vendor for every selected company, one billed vendor request per company. Runs 'buy_company_data' once per selected company, as a durable background job under your own permissions: you need what 'buy_company_data' needs, and its bulk permission when it has one. The call returns a `bulkActionId` as soon as the job is dispatched; follow its status and counters with get_bulk_action_result or list_bulk_actions, and stop the remaining invocations with cancel_bulk_action. An invocation that already ran is not undone. `args` holds the parameters of 'buy_company_data' every invocation receives. 'buy_company_data' gets `company_id` from the selected company; neither can be passed. A parameter 'buy_company_data' does not take, or a missing required one, refuses the call before the job starts; a requirement that depends on another parameter is checked per invocation, which then fails. Select the companies with exactly one of: - `entity_ids`: the ids of the companies to target. - `filter`: a json-logic filter selecting every matching company, with the column keys of the console company table. Tell the user how many companies it matches before running a write they cannot take back. - `items`: one entry per invocation, with its own parameters merged over `args`, for a parameter that differs per company. The same company may appear more than once. About 'buy_company_data': Buy fresh company profile data for an existing company from a business data vendor, under the vendor contract the workspace is configured with (Dotfile's or the workspace's own), as a company data fetch from the console does. Every call is a new purchase request to the vendor. Once the vendor returns the data, the purchase is recorded as company data usage of the workspace and counts toward its plan limit; a call is refused once the limit is reached. On the workspace's own contract the vendor bills the workspace; on Dotfile's contract Dotfile bills the usage, except on trial and internal workspaces. There is no deduplication, so buying twice is a second purchase. This tool sells no Dotfile subscription, plan or credit. Check how recent the current data is before buying; the result includes when the previous data was fetched. Parameters: - company_id: The id of the company to buy data for - vendor: The vendor to buy from; omit to buy from the vendor of the company's most recent purchase After a purchase, use get_company_data_changes to compare the refreshed data with the previous snapshot.

bulk_buy_company_data

Cancel a bulk action you dispatched earlier, by its `bulkActionId`. Only a pending or running bulk action can be cancelled — already-settled items keep their outcome. Items still waiting are cancelled; items already in flight finish on their own.

cancel_bulk_action

Close the case identified by `case_id`. Records a closing decision and moves the case to the closed status. Parameters: - case_id: the id of the case to close - comment: optional note explaining the decision (the workspace may require one)

close_case

Close every selected case. Runs 'close_case' once per selected case, as a durable background job under your own permissions: you need what 'close_case' needs, and its bulk permission when it has one. The call returns a `bulkActionId` as soon as the job is dispatched; follow its status and counters with get_bulk_action_result or list_bulk_actions, and stop the remaining invocations with cancel_bulk_action. An invocation that already ran is not undone. `args` holds the parameters of 'close_case' every invocation receives. 'close_case' gets `case_id` from the selected case; neither can be passed. A parameter 'close_case' does not take, or a missing required one, refuses the call before the job starts; a requirement that depends on another parameter is checked per invocation, which then fails. Select the cases with exactly one of: - `entity_ids`: the ids of the cases to target. - `filter`: a json-logic filter selecting every matching case, with the column keys of the console case table. Tell the user how many cases it matches before running a write they cannot take back. - `items`: one entry per invocation, with its own parameters merged over `args`, for a parameter that differs per case. The same case may appear more than once. About 'close_case': Close the case identified by `case_id`. Records a closing decision and moves the case to the closed status. Parameters: - case_id: the id of the case to close - comment: optional note explaining the decision (the workspace may require one)

bulk_close_cases

Compare the two latest company data snapshots of every selected company. Runs 'get_company_data_changes' once per selected company, as a durable background job under your own permissions: you need what 'get_company_data_changes' needs, and its bulk permission when it has one. The call returns a `bulkActionId` as soon as the job is dispatched; follow its status and counters with get_bulk_action_result or list_bulk_actions, and stop the remaining invocations with cancel_bulk_action. Each invocation's result is kept on its item of the bulk action, in the Dotfile console; it does not come back through this connector. `args` holds the parameters of 'get_company_data_changes' every invocation receives. 'get_company_data_changes' gets `company_id` from the selected company; neither can be passed. A parameter 'get_company_data_changes' does not take, or a missing required one, refuses the call before the job starts; a requirement that depends on another parameter is checked per invocation, which then fails. Select the companies with exactly one of: - `entity_ids`: the ids of the companies to target. - `filter`: a json-logic filter selecting every matching company, with the column keys of the console company table. - `items`: one entry per invocation, with its own parameters merged over `args`, for a parameter that differs per company. The same company may appear more than once. About 'get_company_data_changes': Compare the two most recent purchased data snapshots of a company and return the changes as categorized old/new value pairs (same categories as company monitoring alerts). The comparison is computed deterministically in code; nothing is purchased and nothing is billed. Parameters: - company_id: The id of the company to compare snapshots for - vendor: Compare the two latest snapshots from this vendor; omit to use the vendor of the most recent snapshot Use after buy_company_data to detect discrepancies between the previous and the refreshed profile.

bulk_get_company_data_changes

Create a new case for a company (KYB) or an individual (KYC). Parameters: - entity_type: company or individual - search_ref / company: for a company, provide exactly one of the two. `search_ref` is a searchRef from a search_company_data result: this tool then fetches detailed company data and creates the case with its beneficial owners and affiliated companies. `company` is the company's own fields, for data you already hold (a spreadsheet, a user's input): only `name` is required, and the case holds that company alone. Prefer `search_ref` whenever the company can be found, it yields a far richer case - first_name / last_name: required for individual - birth_date (yyyy-MM-dd), birth_country (ISO 3166-1 alpha-2), email: optional, individual only - case_name: optional custom case name. Defaults to "KYB - {companyName}" or "KYC - {firstName} {lastName}" - template_id: optional case template ID

create_case

Create a check on an individual or company. Supports 10 check types with entity compatibility validation. Check types: - aml (AML screening) — AML screening against PEP, sanctions, and adverse-media watchlists. Individual or company. - company_monitoring (Company monitoring) — Ongoing monitoring of a company's legal and financial status. Company only. - id_verification (Identity verification) — Automated identity verification of an individual, completed in the identity verification vendor's own hosted flow. Individual only. - id_document (Identity document) — Upload and review of a government-issued identity document. Individual only. - document (Document) — Upload and review of a specific document type required for the case. Individual or company. - ekyc (eKYC) — Comprehensive electronic KYC flow combining identity document verification, identity verification and watchlist screening in a single journey hosted by the vendor. Individual only. - electronic_signature (Electronic signature) — Electronic signature collection on a document template. Individual only. - email_phone_verification (Email & Phone verification) — Verification of an individual's email address and phone number, with the fraud and trust signals the vendor returns alongside them. Individual only. - fraud_database (Fraud Database) — Screening against fraud databases (bank-account, identity-fraud lists). Individual or company. - online_reputation (Online Reputation) — Analysis of a company's public online presence and reputation. Company only. Identity verification and eKYC checks send the individual to the vendor's hosted flow, which collects the document and face capture: this tool never receives images or biometric data. Parameters: - type: The type of check to create. Pick the exact type the user asked for; never substitute a similar-sounding or related type. - entityId: The ID of the individual or company to run the check on. - entityType: Whether the entity is an individual or a company. - settings: Optional check-type-specific settings.

create_check

Create a check on every selected company. Runs 'create_check' once per selected company, as a durable background job under your own permissions: you need what 'create_check' needs, and its bulk permission when it has one. The call returns a `bulkActionId` as soon as the job is dispatched; follow its status and counters with get_bulk_action_result or list_bulk_actions, and stop the remaining invocations with cancel_bulk_action. An invocation that already ran is not undone. `args` holds the parameters of 'create_check' every invocation receives. 'create_check' gets `entityId` from the selected company and `entityType` = `company` from this tool; neither can be passed. Every invocation needs `type`, from `args` or from its item's args. A parameter 'create_check' does not take, or a missing required one, refuses the call before the job starts; a requirement that depends on another parameter is checked per invocation, which then fails. Select the companies with exactly one of: - `entity_ids`: the ids of the companies to target. - `filter`: a json-logic filter selecting every matching company, with the column keys of the console company table. Tell the user how many companies it matches before running a write they cannot take back. - `items`: one entry per invocation, with its own parameters merged over `args`, for a parameter that differs per company. The same company may appear more than once. About 'create_check': Create a check on an individual or company. Supports 10 check types with entity compatibility validation. Check types: - aml (AML screening) — AML screening against PEP, sanctions, and adverse-media watchlists. Individual or company. - company_monitoring (Company monitoring) — Ongoing monitoring of a company's legal and financial status. Company only. - id_verification (Identity verification) — Automated identity verification of an individual, completed in the identity verification vendor's own hosted flow. Individual only. - id_document (Identity document) — Upload and review of a government-issued identity document. Individual only. - document (Document) — Upload and review of a specific document type required for the case. Individual or company. - ekyc (eKYC) — Comprehensive electronic KYC flow combining identity document verification, identity verification and watchlist screening in a single journey hosted by the vendor. Individual only. - electronic_signature (Electronic signature) — Electronic signature collection on a document template. Individual only. - email_phone_verification (Email & Phone verification) — Verification of an individual's email address and phone number, with the fraud and trust signals the vendor returns alongside them. Individual only. - fraud_database (Fraud Database) — Screening against fraud databases (bank-account, identity-fraud lists). Individual or company. - online_reputation (Online Reputation) — Analysis of a company's public online presence and reputation. Company only. Identity verification and eKYC checks send the individual to the vendor's hosted flow, which collects the document and face capture: this tool never receives images or biometric data. Parameters: - type: The type of check to create. Pick the exact type the user asked for; never substitute a similar-sounding or related type. - entityId: The ID of the individual or company to run the check on. - entityType: Whether the entity is an individual or a company. - settings: Optional check-type-specific settings.

bulk_create_company_checks

Create a check on every selected individual. Runs 'create_check' once per selected individual, as a durable background job under your own permissions: you need what 'create_check' needs, and its bulk permission when it has one. The call returns a `bulkActionId` as soon as the job is dispatched; follow its status and counters with get_bulk_action_result or list_bulk_actions, and stop the remaining invocations with cancel_bulk_action. An invocation that already ran is not undone. `args` holds the parameters of 'create_check' every invocation receives. 'create_check' gets `entityId` from the selected individual and `entityType` = `individual` from this tool; neither can be passed. Every invocation needs `type`, from `args` or from its item's args. A parameter 'create_check' does not take, or a missing required one, refuses the call before the job starts; a requirement that depends on another parameter is checked per invocation, which then fails. Select the individuals with exactly one of: - `entity_ids`: the ids of the individuals to target. - `filter`: a json-logic filter selecting every matching individual, with the column keys of the console individual table. Tell the user how many individuals it matches before running a write they cannot take back. - `items`: one entry per invocation, with its own parameters merged over `args`, for a parameter that differs per individual. The same individual may appear more than once. About 'create_check': Create a check on an individual or company. Supports 10 check types with entity compatibility validation. Check types: - aml (AML screening) — AML screening against PEP, sanctions, and adverse-media watchlists. Individual or company. - company_monitoring (Company monitoring) — Ongoing monitoring of a company's legal and financial status. Company only. - id_verification (Identity verification) — Automated identity verification of an individual, completed in the identity verification vendor's own hosted flow. Individual only. - id_document (Identity document) — Upload and review of a government-issued identity document. Individual only. - document (Document) — Upload and review of a specific document type required for the case. Individual or company. - ekyc (eKYC) — Comprehensive electronic KYC flow combining identity document verification, identity verification and watchlist screening in a single journey hosted by the vendor. Individual only. - electronic_signature (Electronic signature) — Electronic signature collection on a document template. Individual only. - email_phone_verification (Email & Phone verification) — Verification of an individual's email address and phone number, with the fraud and trust signals the vendor returns alongside them. Individual only. - fraud_database (Fraud Database) — Screening against fraud databases (bank-account, identity-fraud lists). Individual or company. - online_reputation (Online Reputation) — Analysis of a company's public online presence and reputation. Company only. Identity verification and eKYC checks send the individual to the vendor's hosted flow, which collects the document and face capture: this tool never receives images or biometric data. Parameters: - type: The type of check to create. Pick the exact type the user asked for; never substitute a similar-sounding or related type. - entityId: The ID of the individual or company to run the check on. - entityType: Whether the entity is an individual or a company. - settings: Optional check-type-specific settings.

bulk_create_individual_checks

Add a tag to the workspace tag list. Create, rename or delete a tag in the workspace tag list. Parameters: - label: the tag label (max 100 characters, must be unique in the workspace) — required for create and update - tag_id: the id of the tag to rename or delete (use list_tags to find it) — required for update and delete Use list_tags first: create only what does not exist yet, and resolve the id of what does. Deleting a tag also detaches it from every case it was on. This writes the tag list itself. To put an existing tag on a case, use add_case_tags or remove_case_tags.

create_tag

Create a case template. Create, update or delete a case template. A template with rules cannot be deleted; delete its rules first. The key is immutable after creation.

create_template

Create one or several rules of the same kind on a template. Create, update or delete a template rule. An update changes only the fields you pass: activation_json_logic (null removes the condition) on every kind, deduplication and variants (the list you pass replaces all existing variants) on a check rule, auto_purchase_settings on an auto-purchase rule. check_target, check_type, check_settings and control_id are fixed once the rule exists; delete and recreate the rule to change them. To create several rules of the same kind on one template, pass them in "rules" in a single call instead of calling this tool once per rule: the user approves them together and they are created atomically. A rule only decides which check a case gets: for identity verification and eKYC checks, the vendor collects the document and face capture in its own hosted flow, and none of it passes through this tool.

create_template_rule

Delete the case identified by `case_id`. This soft-deletes the case and everything attached to it. Use with care — prefer rejecting or closing a case over deleting it.

delete_case

Delete a check. Parameters: - check_id: the id of the check to delete (use query_entities to find it)

delete_check

Delete every selected case. Runs 'delete_case' once per selected case, as a durable background job under your own permissions: you need what 'delete_case' needs, and its bulk permission when it has one. The call returns a `bulkActionId` as soon as the job is dispatched; follow its status and counters with get_bulk_action_result or list_bulk_actions, and stop the remaining invocations with cancel_bulk_action. An invocation that already ran is not undone. `args` holds the parameters of 'delete_case' every invocation receives. 'delete_case' gets `case_id` from the selected case; neither can be passed. A parameter 'delete_case' does not take, or a missing required one, refuses the call before the job starts; a requirement that depends on another parameter is checked per invocation, which then fails. Select the cases with exactly one of: - `entity_ids`: the ids of the cases to target. - `filter`: a json-logic filter selecting every matching case, with the column keys of the console case table. Tell the user how many cases it matches before running a write they cannot take back. - `items`: one entry per invocation, with its own parameters merged over `args`, for a parameter that differs per case. The same case may appear more than once. About 'delete_case': Delete the case identified by `case_id`. This soft-deletes the case and everything attached to it. Use with care — prefer rejecting or closing a case over deleting it.

bulk_delete_cases

Delete every selected check. Runs 'delete_check' once per selected check, as a durable background job under your own permissions: you need what 'delete_check' needs, and its bulk permission when it has one. The call returns a `bulkActionId` as soon as the job is dispatched; follow its status and counters with get_bulk_action_result or list_bulk_actions, and stop the remaining invocations with cancel_bulk_action. An invocation that already ran is not undone. `args` holds the parameters of 'delete_check' every invocation receives. 'delete_check' gets `check_id` from the selected check; neither can be passed. A parameter 'delete_check' does not take, or a missing required one, refuses the call before the job starts; a requirement that depends on another parameter is checked per invocation, which then fails. Select the checks with exactly one of: - `entity_ids`: the ids of the checks to target. - `filter`: a json-logic filter selecting every matching check, with the column keys of the console check table. Tell the user how many checks it matches before running a write they cannot take back. - `items`: one entry per invocation, with its own parameters merged over `args`, for a parameter that differs per check. The same check may appear more than once. About 'delete_check': Delete a check. Parameters: - check_id: the id of the check to delete (use query_entities to find it)

bulk_delete_checks

Delete a note from a case. Create, update or delete notes and note comments (replies) on the case identified by `case_id`. Parameters: - case_id: the id of the case the note belongs to - content: the note or comment text — required for add_note, update_note (max 10,000 characters) and add_comment, update_comment (max 3,000 characters) - note_id: required for update_note, delete_note and add_comment (use list_notes to find it) - comment_id: required for update_comment and delete_comment (use list_notes to find it) Use notes to document observations, findings, decisions or rationale on the case; use comments to reply to an existing note.

delete_note

Delete a comment from a note. Create, update or delete notes and note comments (replies) on the case identified by `case_id`. Parameters: - case_id: the id of the case the note belongs to - content: the note or comment text — required for add_note, update_note (max 10,000 characters) and add_comment, update_comment (max 3,000 characters) - note_id: required for update_note, delete_note and add_comment (use list_notes to find it) - comment_id: required for update_comment and delete_comment (use list_notes to find it) Use notes to document observations, findings, decisions or rationale on the case; use comments to reply to an existing note.

delete_note_comment

Delete a note comment on every selected case, one comment per invocation. Runs 'delete_note_comment' once per selected case, as a durable background job under your own permissions: you need what 'delete_note_comment' needs, and its bulk permission when it has one. The call returns a `bulkActionId` as soon as the job is dispatched; follow its status and counters with get_bulk_action_result or list_bulk_actions, and stop the remaining invocations with cancel_bulk_action. An invocation that already ran is not undone. `args` holds the parameters of 'delete_note_comment' every invocation receives. 'delete_note_comment' gets `case_id` from the selected case and `action` = `delete_comment` from this tool; neither can be passed. Every invocation needs `comment_id`, from `args` or from its item's args. A parameter 'delete_note_comment' does not take, or a missing required one, refuses the call before the job starts; a requirement that depends on another parameter is checked per invocation, which then fails. Select the cases with exactly one of: - `entity_ids`: the ids of the cases to target. - `filter`: a json-logic filter selecting every matching case, with the column keys of the console case table. Tell the user how many cases it matches before running a write they cannot take back. - `items`: one entry per invocation, with its own parameters merged over `args`, for a parameter that differs per case. The same case may appear more than once. About 'delete_note_comment': Delete a comment from a note. Create, update or delete notes and note comments (replies) on the case identified by `case_id`. Parameters: - case_id: the id of the case the note belongs to - content: the note or comment text — required for add_note, update_note (max 10,000 characters) and add_comment, update_comment (max 3,000 characters) - note_id: required for update_note, delete_note and add_comment (use list_notes to find it) - comment_id: required for update_comment and delete_comment (use list_notes to find it) Use notes to document observations, findings, decisions or rationale on the case; use comments to reply to an existing note.

bulk_delete_note_comment

Delete a note from every selected case, one note per invocation. Runs 'delete_note' once per selected case, as a durable background job under your own permissions: you need what 'delete_note' needs, and its bulk permission when it has one. The call returns a `bulkActionId` as soon as the job is dispatched; follow its status and counters with get_bulk_action_result or list_bulk_actions, and stop the remaining invocations with cancel_bulk_action. An invocation that already ran is not undone. `args` holds the parameters of 'delete_note' every invocation receives. 'delete_note' gets `case_id` from the selected case and `action` = `delete_note` from this tool; neither can be passed. Every invocation needs `note_id`, from `args` or from its item's args. A parameter 'delete_note' does not take, or a missing required one, refuses the call before the job starts; a requirement that depends on another parameter is checked per invocation, which then fails. Select the cases with exactly one of: - `entity_ids`: the ids of the cases to target. - `filter`: a json-logic filter selecting every matching case, with the column keys of the console case table. Tell the user how many cases it matches before running a write they cannot take back. - `items`: one entry per invocation, with its own parameters merged over `args`, for a parameter that differs per case. The same case may appear more than once. About 'delete_note': Delete a note from a case. Create, update or delete notes and note comments (replies) on the case identified by `case_id`. Parameters: - case_id: the id of the case the note belongs to - content: the note or comment text — required for add_note, update_note (max 10,000 characters) and add_comment, update_comment (max 3,000 characters) - note_id: required for update_note, delete_note and add_comment (use list_notes to find it) - comment_id: required for update_comment and delete_comment (use list_notes to find it) Use notes to document observations, findings, decisions or rationale on the case; use comments to reply to an existing note.

bulk_delete_note

Delete a tag from the workspace tag list, detaching it from every case. Create, rename or delete a tag in the workspace tag list. Parameters: - label: the tag label (max 100 characters, must be unique in the workspace) — required for create and update - tag_id: the id of the tag to rename or delete (use list_tags to find it) — required for update and delete Use list_tags first: create only what does not exist yet, and resolve the id of what does. Deleting a tag also detaches it from every case it was on. This writes the tag list itself. To put an existing tag on a case, use add_case_tags or remove_case_tags.

delete_tag

Delete a case template that has no rules. Create, update or delete a case template. A template with rules cannot be deleted; delete its rules first. The key is immutable after creation.

delete_template

Delete a template rule. Create, update or delete a template rule. An update changes only the fields you pass: activation_json_logic (null removes the condition) on every kind, deduplication and variants (the list you pass replaces all existing variants) on a check rule, auto_purchase_settings on an auto-purchase rule. check_target, check_type, check_settings and control_id are fixed once the rule exists; delete and recreate the rule to change them. To create several rules of the same kind on one template, pass them in "rules" in a single call instead of calling this tool once per rule: the user approves them together and they are created atomically. A rule only decides which check a case gets: for identity verification and eKYC checks, the vendor collects the document and face capture in its own hosted flow, and none of it passes through this tool.

delete_template_rule

List the columns of an entity: their key, type, whether they can be filtered or sorted, the operators they accept and, when they have a fixed option list, their allowed values. Includes this workspace's custom properties, so the keys differ from one workspace to the next. These keys are the ones an entity filter takes. Columns of relation kind (assignee, template, tags) filter on the ids of workspace members, templates or tags, and carry no option list here. Custom property columns appear as the keys to filter on.

describe_entity_columns

Describe the analytic datasets available for charts: their dimensions (with type and allowed values), the named counts and numerics their measures can reference, and whether they support a state snapshot, a per-bucket as-of series, or a first-event-per-group restriction. These are the exact keys an analytics query takes. A dimension that is not `groupable` cannot be used as a breakdown; one that is not `filterable` cannot appear in filters.

describe_analytic_datasets

Fetch the current status and item counters of any bulk action by its `bulkActionId`, including pending and terminal jobs. Status `partial` means processing completed with failed or skipped items, not full success. `failed` and `cancelled` are terminal failures; `pending` and `running` are not terminal. Missing or inaccessible jobs return an error, never success. For an AI review (`start_ai_review`) this returns each reviewed check's decision (approved / rejected) with the reviewer's reasoning, plus the aggregate counts. Use job status and item counters to wait for completion; the review fields (`total`, `approved`, `rejected`, `undecided`, `items`) describe only linked AI reviews, not overall job progress. Returns at most 50 per-item rows (the counts always reflect the full set).

get_bulk_action_result

Get a temporary download link for one file attached to a check, such as the back of an identity document or a signed document. Parameters: - check_id: the id of the check the file is attached to - file_id: the id of the file, as listed in the check's files The link expires after one hour.

get_check_file_download_link

Read one client portal's editable form: its setting, ordered steps, blocks, field options and conditional logic. By default translations include only language and completeness metadata; set include_wording to include the raw per-language wording dictionary. Use list_client_portals to find the id.

get_client_portal_form

Compare the two most recent purchased data snapshots of a company and return the changes as categorized old/new value pairs (same categories as company monitoring alerts). The comparison is computed deterministically in code; nothing is purchased and nothing is billed. Parameters: - company_id: The id of the company to compare snapshots for - vendor: Compare the two latest snapshots from this vendor; omit to use the vendor of the most recent snapshot Use after buy_company_data to detect discrepancies between the previous and the refreshed profile.

get_company_data_changes

Get a temporary download link for a completed document order. Parameters: - document_order_id: The id of the document order to download (from list_document_orders) Only completed orders have a downloadable file; the link expires after a short time.

get_document_download_link

Read the text content of a completed document order (PDF or scanned image, via OCR). Parameters: - document_order_id: The id of the document order to read (from list_document_orders) Only completed orders have a file to read. Use this to inspect what a purchased document actually contains. Long documents can be read only in part: the result then says which pages and how many characters it covers, and links the full PDF.

get_document_text

Read the activity journal of one case, company, individual, case control or check — the same feed the console shows on the entity. Returns the events newest first, each with its date, its author and, when the event changed fields, the previous and next value of each one. Use this to reconstruct a history and attribute it: who created the case, who applied the template and when, every status the case went through, who approved or rejected a check, why a communication was cancelled. The author is named whenever the platform knows it: a workspace member or a business contact by their name, an API key by its name. Events the platform performed on its own are attributed to the system, and an event an AI agent performed says so. Filter with source_events to follow one thread of the history — the status changes, the check decisions — and leave it out to read everything. Events recorded before the platform started storing which event produced them carry no source event, so a filtered read skips that older history. Pass a check id for a check, not the id of its result data. Ids come from query_entities for a case, company, individual or check, and from list_case_controls for a control.

get_entity_timeline

Read one version of a risk engine: its code, and whether that code is the one currently scoring cases. The code is the rules. It reads the case through `$.input`, and reaches a level by calling `$.set_risk` with it. Read it to explain why a case got the level it did, or to see what a level depends on before changing it. Parameters: - version_id: the id of the version to read — use list_risk_engines to find it

get_risk_engine_version

Read the configuration of the current workspace — the defaults and policies that change how the product behaves for this customer. Returns the whole settings tree as JSON, in the exact shape update_workspace_settings accepts, so you can read a value, change it and write it back without guessing field names. It covers the check policies (automatic approval, rejection and expiration per check type, and each check's vendor), AML screening, risk levels and review periods, per-country company-data vendors and UBO thresholds, communication senders and reminders, data retention, MFA, SSO and IP allowlist. Vendor credentials are not returned: OAuth tokens, API key ids, DNS proof records and external provider ids are left out. Feature flags are not part of workspace settings and are not returned here.

get_workspace_settings

List the AML screening profiles available to this workspace, including their IDs, archive/default status and stored screening settings. Without profile_id, this returns local snapshots without refreshing Mesh. Before updating a profile, call again with its profile_id to fetch only that profile's current provider settings and expected_version. Profiles unavailable for edit do not include an expected_version. Read-only collections are managed in Mesh and preserved automatically; omit them from updates. Use this tool before updating, archiving or unarchiving.

list_aml_screening_profiles

List the workspace's assignment rules — the rules that decide who a case, company or individual gets assigned to. Returns each rule with its position, status, scope, strategy, condition and the user ids it assigns to. Use it to explain why something was assigned the way it was, and before create_assignment_rule, update_assignment_rule or delete_assignment_rule to get a rule's id. The pool is user ids only. Put a name to one with list_workspace_members, which lists the colleagues you are allowed to see. How the rules run: only `enabled` rules are evaluated, in ascending `position` order, and the first rule whose condition matches wins — later rules are not considered. A case that already has an assignee is skipped entirely. It also returns the field paths a condition may reference, per scope, including this workspace's custom properties. Read them before writing a condition: a path that is not in that list is rejected.

list_assignment_rules

List the official documents that can be ordered for a company from the registry vendors. Parameters: - company_id: The id of the company to list available documents for Each result includes a productRef, the vendor, a price tier and the expected delivery time. The productRef identifies the document in an order.

list_available_documents