MCP Tools
The Red Sift MCP Server exposes the following tools. Most product-specific tools accept an optional instance_id parameter — if omitted, the default instance is used.
Account & IAM tools
Section titled “Account & IAM tools”iam_account_info
Section titled “iam_account_info”Retrieve the authenticated user’s account information and available Red Sift product instances. Returns a JSON object containing: ‘email’ (user’s email address), ‘instances’ (available product instances by product name, where each instance includes ‘id’, ‘name’, and ‘description’ fields), and ‘default_instances’ (currently selected default instance for each product). Use this tool first to discover which Red Sift products and instances are available before making product-specific API calls. Products include: Brand Trust, Certificates, OnDMARC.
Parameters: None required.
iam_invite_user
Section titled “iam_invite_user”Invite a new user to a Red Sift product instance by email address. Creates an invitation that grants the specified user access to the product instance. Returns invitation details including invitationId, invitationCode, and status. By default, an invitation email is automatically sent to the recipient - set skip_email=True to generate the invitation without sending email (useful for programmatic access or custom invitation workflows). Valid products: ‘ondmarc’, ‘brandtrust’, ‘certificates’, ‘pulse’. Valid roles: ‘owner’, ‘superadmin’, ‘superreader’. If roles are not specified, defaults to ‘superreader’ role. Use ‘iam_account_info’ first to discover available products and instance IDs. Use ‘iam_list_sift_users’ to check existing access before inviting. The invitation is created immediately and can be used to access the instance once accepted.
| Parameter | Type | Required | Notes |
|---|---|---|---|
product | string | Yes | — |
instance | string | Yes | — |
email | string | Yes | — |
roles | array | No | — |
skip_email | boolean | No | — |
iam_update_instance_metadata
Section titled “iam_update_instance_metadata”Updates the name and description metadata for a Red Sift product instance. This allows you to set friendly names and descriptions for your instances to help organize and identify them. Call ‘iam_account_info’ first to discover available products and instance IDs. Valid products: ‘ondmarc’, ‘brandtrust’, ‘certificates’, ‘pulse’. Both name and description are optional - provide only the fields you want to update.
| Parameter | Type | Required | Notes |
|---|---|---|---|
product | string | Yes | — |
instance | string | Yes | — |
name | string | No | — |
description | string | No | — |
Brand Trust tools
Section titled “Brand Trust tools”brandtrust_activity_summary
Section titled “brandtrust_activity_summary”Get a summary report from your Brand Trust account. Returns information about image detection (logos, faces, and keywords), priority review items (high risk rating and highest similarity matches), potential assets, and lookalike domains. Use this for a quick overview of your brand protection status.
Parameters: None required.
brandtrust_list_domains
Section titled “brandtrust_list_domains”Lists all domains being monitored in your Brand Trust account. Returns both active domains (actively scanned for lookalikes) and inactive domains (registered but not monitored).
Parameters: None required.
brandtrust_add_domain
Section titled “brandtrust_add_domain”Adds a new domain to Brand Trust monitoring. By default, domains are added with ‘inactive’ status (registered but not scanned). Set status to ‘active’ to enable lookalike detection and monitoring for that domain. If the domain exists as a lookalike already, it won’t be added automatically and an error will be returned — use the brandtrust_add_lookalike_as_domain tool in this case.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
status | string | No | inactive, active |
brandtrust_list_takedown
Section titled “brandtrust_list_takedown”Lists all takedown requests tracked in your Brand Trust account. Shows the status and details of domains or content you have requested to be taken down for brand infringement.
Parameters: None required.
brandtrust_list_lookalikes
Section titled “brandtrust_list_lookalikes”Retrieves lookalike domains detected by Brand Trust monitoring with their security assessment and metadata. Returns domains similar to your protected brands based on risk ratings. Filter by risk_level to prioritize investigation: ‘high-risk’ indicates a high threat level, ‘low-risk’ indicates a minimal threat, ‘unclassified’ for newly discovered domains awaiting analysis. Supports pagination for large result sets.
| Parameter | Type | Required | Notes |
|---|---|---|---|
risk_level | string | No | unclassified, low-risk, high-risk |
page | number | No | — |
page_size | number | No | — |
brandtrust_read_lookalike
Section titled “brandtrust_read_lookalike”Sets one or more lookalike domains as read or unread. Use this to track which lookalikes have been reviewed. The domains parameter should be a list of full domain names (e.g., [‘suspicious-domain.com’]). Setting status=‘read’ indicates the domain has been reviewed, ‘unread’ resets it.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domains | string[] | Yes | — |
status | string | No | read, unread |
brandtrust_classify_lookalike
Section titled “brandtrust_classify_lookalike”Classifies one or more lookalike domains by risk level. Moves domains between unclassified, low-risk, and high-risk categories. The current classification is auto-detected. Use this after reviewing a lookalike to indicate its threat level.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domains | string[] | Yes | — |
classify_as | string | Yes | unclassified, low-risk, high-risk |
brandtrust_get_lookalike_details
Section titled “brandtrust_get_lookalike_details”Retrieves detailed metadata for a specific lookalike domain including web presence data, screenshot metadata, logo detection locations, text detection locations, and visual similarity indicators. Does not include the actual screenshot image (use brandtrust_get_lookalike_screenshot for that). The domain parameter should be the full domain name (e.g., suspicious-domain.com).
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
brandtrust_get_lookalike_screenshot
Section titled “brandtrust_get_lookalike_screenshot”Retrieves the screenshot image for a specific lookalike domain. Returns visual evidence of the domain’s appearance. Use brandtrust_get_lookalike_details to retrieve metadata about logo/text detection locations. The domain parameter should be the full domain name (e.g., suspicious-domain.com).
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
brandtrust_list_logos
Section titled “brandtrust_list_logos”Lists all logos configured in your Brand Trust account. Returns logo metadata including ID, name, brand class, MIME type, and training status. Use this to see which logos are being monitored for detection on lookalike domains.
Parameters: None required.
brandtrust_get_logo
Section titled “brandtrust_get_logo”Retrieves the logo image file for a specific logo UUID. Use brandtrust_list_logos to get available logo UUIDs and brand names. The logo_uuid should be the UUID from list_logos, and brand should be the brand class name.
| Parameter | Type | Required | Notes |
|---|---|---|---|
logo_uuid | string | Yes | — |
brand | string | Yes | — |
brandtrust_add_logo
Section titled “brandtrust_add_logo”Validates a logo image, checks for duplicates and image quality, then uploads the valid logo image to Brand Trust for monitoring. Logo images must be JPEG, PNG, BMP, or SVG format, less than 1MB, with minimum 128px width and height. Include all logo variants (wordmark, logomark, composite). The brand parameter specifies which brand class to add the logo to. The logo_base64 parameter should be the base64-encoded image content.
| Parameter | Type | Required | Notes |
|---|---|---|---|
logo_base64 | string | Yes | — |
brand | string | Yes | — |
filename | string | No | — |
brandtrust_add_lookalike_as_domain
Section titled “brandtrust_add_lookalike_as_domain”Add a lookalike domain and its related subdomains to your monitored domains. Takes a lookalike domain, finds its apex and all related lookalikes, then adds them as monitored domains. The apex is added to domains and all related lookalikes are added to subdomains.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
brandtrust_list_faces
Section titled “brandtrust_list_faces”Lists all face images configured in your Brand Trust account for person detection in lookalike content. Returns face records with metadata including IDs, person IDs, and totals.
Parameters: None required.
brandtrust_list_person_faces
Section titled “brandtrust_list_person_faces”Lists all face images for a specific person in your Brand Trust account. Use brandtrust_list_faces to get available person IDs. Returns all face records associated with the given person.
| Parameter | Type | Required | Notes |
|---|---|---|---|
person_id | string | Yes | — |
brandtrust_get_face_image
Section titled “brandtrust_get_face_image”Retrieves the face image file for a specific person and face ID. Use brandtrust_list_faces or brandtrust_list_person_faces to get available person and face IDs.
| Parameter | Type | Required | Notes |
|---|---|---|---|
person_id | string | Yes | — |
face_id | string | Yes | — |
brandtrust_upload_face
Section titled “brandtrust_upload_face”Validates and uploads a face image to Brand Trust for person detection in lookalike content. Supported formats: PNG, JPG, JPEG, BMP. The face_base64 parameter should be the base64-encoded image content. The person_id groups faces belonging to the same person. Returns the API response (for example, a face UUID) if provided, otherwise a generic success message.
| Parameter | Type | Required | Notes |
|---|---|---|---|
person_id | string | Yes | — |
face_base64 | string | Yes | — |
filename | string | No | — |
brandtrust_delete_face
Section titled “brandtrust_delete_face”Deletes a specific face image from Brand Trust. Use brandtrust_list_faces or brandtrust_list_person_faces to get available person and face IDs.
| Parameter | Type | Required | Notes |
|---|---|---|---|
person_id | string | Yes | — |
face_id | string | Yes | — |
brandtrust_list_detectable_keywords
Section titled “brandtrust_list_detectable_keywords”Lists all detectable keywords configured in your Brand Trust account. These keywords are used to detect lookalike content containing specific text. Returns keyword strings and total count.
Parameters: None required.
brandtrust_set_detectable_keywords
Section titled “brandtrust_set_detectable_keywords”Replaces all detectable keywords in your Brand Trust account with the provided list. These keywords are used to detect lookalike content containing specific text. This operation overwrites all existing keywords.
| Parameter | Type | Required | Notes |
|---|---|---|---|
keywords | string[] | Yes | — |
Certificates tools
Section titled “Certificates tools”certificates_search_describe
Section titled “certificates_search_describe”Returns the allowlist for certificate searches — the exact dimensions you can group/filter by, the metrics (aggregations) available, the filter operators, the date intervals and relative-time tokens, and the request limits. ALWAYS call this first, then build a certificates_search_query (counts/breakdowns/trends) or certificates_search_fetch (listing individual certificate records) request using only the names it returns. Do not hardcode the allowlist; it can evolve over time. Note: certificates and endpoints are separate schemas with different fields — use certificates_endpoints_search_describe for endpoint searches.
Parameters: None required.
certificates_search_query
Section titled “certificates_search_query”Aggregates certificates into counts, breakdowns, and trends — use this for “how many”, “top N by”, “breakdown of”, and time-series questions, NOT for listing individual records (use certificates_search_fetch for that). Call certificates_search_describe first to learn the allowed dimensions, metrics, and filters. Build a request with: dimensions (0–3 group-by fields, or a date histogram for trends), metrics (1–5 aggregations such as count/distinct_count/min/max/avg/sum — ALWAYS set an explicit alias on each), filters (AND-ed conditions including computed fields like status, pqsafe, ca, and expiry-window/date ranges), and optional sort/limit. Groupable/filterable fields include issuerCa, keyAlg, keyLen, validation, sigAlg, ownership, active, managed, wildcard, eku, groupNames, label, notBefore, notAfter, effectiveNotAfter, lifetimeDays, plus computed status (revoked|expired|critical|overdue|due|valid), hierarchy, effective, ca, pqsafe. Each result row has one key per dimension and one per metric alias; a missing dimension value appears as “(unknown)”. Watch meta.total_buckets and meta.truncated — if truncated is true, more buckets existed than your limit, so narrow filters or raise limit (≤1000). distinct_count is approximate.
| Parameter | Type | Required | Notes |
|---|---|---|---|
dimensions | any[] | No | — |
metrics | object[] | Yes | — |
filters | object[] | No | — |
sort | object[] | No | — |
limit | number | No | — |
timeout_ms | number | No | — |
certificates_search_fetch
Section titled “certificates_search_fetch”Lists individual certificate records matching your filters, with cursor pagination — use this when the user wants the actual certificates (e.g. “list third-party certs expiring within 30 days”), NOT counts or breakdowns (use certificates_search_query for those). Call certificates_search_describe first to learn the allowed filter fields and output fields. Build a request with: filters (AND-ed conditions, same operators/fields as the query tool, including computed fields like status and expiry-window/date ranges), optional fields (which columns to return; defaults to a standard set — computed values arrive under a per-row “fields” object), optional sort, and limit (≤200). Paginate by re-sending the SAME body with cursor set to meta.next_cursor from the previous response, until next_cursor is null or rows is empty. meta.total_hits is the match count; if meta.partial is true, treat total_hits as a lower bound (approximate).
| Parameter | Type | Required | Notes |
|---|---|---|---|
filters | object[] | No | — |
fields | string[] | No | — |
sort | object[] | No | — |
limit | number | No | — |
timeout_ms | number | No | — |
cursor | string,null | No | — |
certificates_endpoints_search_describe
Section titled “certificates_endpoints_search_describe”Returns the allowlist for endpoint searches (where certificates are actually served — service/hostname/port/address combinations) — the dimensions you can group/filter by, the available metrics, filter operators, date intervals, relative-time tokens, and request limits. ALWAYS call this first, then build a certificates_endpoints_search_query (counts/breakdowns) or certificates_endpoints_search_fetch (listing individual endpoint records) request using only the names it returns. Endpoints are a SEPARATE schema from certificates with different fields — do not reuse certificate field names here.
Parameters: None required.
certificates_endpoints_search_query
Section titled “certificates_endpoints_search_query”Aggregates endpoints (where certificates are served) into counts and breakdowns — use this for “how many endpoints”, “endpoints by service”, and similar questions, NOT for listing individual endpoint records (use certificates_endpoints_search_fetch for that). Call certificates_endpoints_search_describe first to learn the allowed dimensions, metrics, and filters. Build a request with dimensions (0–3 group-by fields), metrics (1–5 aggregations — ALWAYS set an explicit alias on each), filters (AND-ed conditions), and optional sort/limit. Groupable/filterable fields include serviceHostname, hostname, service, port, address, addressIsPrivate, hostClassificationStatus, hostClassificationTags, groupNames, mtls, effectiveNotAfter, plus computed status (expired|critical|overdue|due|unknown). Note: HEALTHY endpoints emit no status (they fall in the “(unknown)“/missing bucket) — to find healthy ones, filter by expiry date instead. Each result row has one key per dimension and one per metric alias. Watch meta.truncated — if true, narrow filters or raise limit (≤1000). distinct_count is approximate.
| Parameter | Type | Required | Notes |
|---|---|---|---|
dimensions | any[] | No | — |
metrics | object[] | Yes | — |
filters | object[] | No | — |
sort | object[] | No | — |
limit | number | No | — |
timeout_ms | number | No | — |
certificates_endpoints_search_fetch
Section titled “certificates_endpoints_search_fetch”Lists individual endpoint records (where certificates are served — service/hostname/port/address) matching your filters, with cursor pagination — use this when the user wants the actual endpoints (e.g. “list endpoints whose served cert is expiring, with mTLS required”), NOT counts (use certificates_endpoints_search_query for those). Call certificates_endpoints_search_describe first to learn the allowed filter fields and output fields. Build a request with filters (AND-ed conditions, same operators as the query tool, including computed status and expiry-window/date ranges), optional fields (which columns to return; computed values arrive under a per-row “fields” object), optional sort, and limit (≤200). Paginate by re-sending the SAME body with cursor set to meta.next_cursor, until next_cursor is null or rows is empty. If meta.partial is true, treat meta.total_hits as a lower bound.
| Parameter | Type | Required | Notes |
|---|---|---|---|
filters | object[] | No | — |
fields | string[] | No | — |
sort | object[] | No | — |
limit | number | No | — |
timeout_ms | number | No | — |
cursor | string,null | No | — |
certificates_list_hosts
Section titled “certificates_list_hosts”Lists hosts (domains and subdomains) currently monitored for certificate discovery and tracking. Some accounts monitor millions of hosts, so this returns only limit hosts (default 100, max 1000) per call — narrow with filters, and page with offset to walk past 1000 rather than assuming a single call returns everything. To get only apex domains, set regRegistry:true (registry/IANA-suffix apexes, e.g. example.com but not sub.example.com) or regPublic:true (broader — also includes public suffixes like co.uk). These are direct filter params that the server applies for you; combine with offset+totalCount to walk every apex domain in the account. For richer filtering (registrar, registrant, creation/expiry date, exact/partial hostname match, group/tag set membership), use the filter array — a separate mechanism whose clauses are AND-ed by default (OR via filterConnector). By default each host is returned as a compact summary (hostname plus key metadata) so even limit=1000 fits in one response — no need to page or post-filter for a plain domain list. IMPORTANT: in compact mode the response envelope carries compact: true and non-summary fields (certificates, ips, nameservers, assessment blobs, etc.) are DROPPED from each host record — set verbose:true only when you specifically need the full raw host records.
| Parameter | Type | Required | Notes |
|---|---|---|---|
limit | number | No | — |
hostname | string | No | — |
status | string | No | monitored, idle, archived |
subdomains | boolean | No | — |
regRegistry | boolean | No | — |
regPublic | boolean | No | — |
nx | boolean | No | — |
origin | string | No | — |
internal | boolean | No | — |
group | string | No | — |
tag | string | No | — |
filter | object[] | No | — |
filterConnector | string | No | AND, OR |
sort | string | No | — |
offset | number | No | — |
totalCount | boolean | No | — |
totalCountLimit | number | No | — |
verbose | boolean | No | — |
certificates_add_hosts
Section titled “certificates_add_hosts”Adds new hosts (domains or subdomains) to monitor for SSL/TLS certificates. The system will automatically discover and track certificates associated with these hosts. Hosts must be valid domain names. Pass multiple hosts as a list to add them in a single operation.
| Parameter | Type | Required | Notes |
|---|---|---|---|
hosts | string[] | Yes | — |
certificates_exclude_hosts
Section titled “certificates_exclude_hosts”Prevents specific hosts from being automatically added during certificate discovery. Exclusions only affect newly discovered hosts; existing monitored hosts are not removed. Useful for filtering out third-party or irrelevant subdomains. Pass multiple hosts as a list to exclude them in a single operation.
| Parameter | Type | Required | Notes |
|---|---|---|---|
hosts | string[] | Yes | — |
certificates_list_discoveries
Section titled “certificates_list_discoveries”Lists CERTIFICATE discoveries — certificates observed for your monitored hosts (e.g. from Certificate Transparency logs), including certs found on related subdomains, so you can spot certificates you did not issue. Each record is one discovered certificate. Some accounts have large discovery backlogs, so this returns only limit discoveries per call (default 100, max 1000) — narrow with status/since. Per the OpenAPI spec (listCertDiscoveries), this endpoint accepts ONLY these three query params plus tool-side verbose/instance_id; it does NOT support generic filter/sort/offset/totalCount pagination like list_hosts/list_issues, and it does NOT accept an escalated query param (escalated is a response field on each discovery — filter on it client-side after fetching). Each discovery is returned as a COMPACT summary by default: the certificate metadata (certSummary — label, key, issuer, validity), its status (triage/open/closed), resolution and escalated state, and matchedHosts (which of your monitored hosts appear in the cert — the actionable field). IMPORTANT: in compact mode the response envelope carries compact: true and each record is trimmed: the full SAN list (certSummary.hosts, often 100+ entries for wildcard/shared certs like *.a.run.app) is truncated to a small sample plus hostsCount + hostsTruncated:true; the certSummary.extras blob is dropped; matchedHosts is reduced to a small hostname sample plus matchedHostsCount (+ matchedHostsTruncated:true when trimmed) — wildcard/shared certs can match thousands of monitored hostnames, and the underlying record can also carry per-host CAA/DNS metadata that is dropped in compact mode. Set verbose:true only when you need the full SAN list, full matchedHosts detail, and raw records. Use certSummary.sha256/certDiscoveryId to drill into a specific certificate.
| Parameter | Type | Required | Notes |
|---|---|---|---|
limit | number | No | — |
status | string | No | open, closed |
since | string | No | — |
verbose | boolean | No | — |
certificates_stats
Section titled “certificates_stats”Retrieves comprehensive certificate statistics and analytics for your account. Returns detailed counts including: certificate status (active_or_non_expired, active), ownership (own, third_party), expiration status (active_expired, own_expired, third_party_expired), and time-based expiration categories based on days until expiration: ‘critical’ (days 30-34, next 4 days requiring immediate attention), ‘overdue’ (days 34-44, 14-day window for overdue renewals), ‘due’ (days 44-90, 60-day window for upcoming renewals). Also includes service-level breakdowns by protocol type (service_http, service_smtp, service_others), scanned_domains (total monitored domains/subdomains being scanned for discovery), and ca_count (number of distinct certificate authorities represented in your certificate inventory). Useful for certificate inventory overview, compliance reporting, and identifying certificates requiring immediate renewal action.
Parameters: None required.
certificates_list_issues
Section titled “certificates_list_issues”Lists security/config issues Hardenize auto-detects across your monitored hosts — each a problem worth fixing (expiring cert, weak key, broken trust chain, TLS/HSTS/CAA/DNS/DNSSEC/DANE misconfiguration, registration problem), auto-opened when detected and auto-closed when it stops manifesting. By default returns only ACTIVE issues (status=active: open, unresolved — the issues customers actually care about), across the certificate/PKI/transport categories (TLS, PKI, HSTS, CAA, DANE). When you rely on these defaults, say so in your answer (e.g. “showing active TLS/PKI/HSTS/CAA/DANE issues”). Widen scope with the categories param (e.g. add DNS, DNSSEC, WWW, DMARC), and set status (or the simpler open boolean) to inspect other lifecycle states. Each result is a COMPACT summary by default: issueId (pass to certificates_get_issue for full evidence — the type-tagged details object), title/description (the problem), category, severity, affected asset (subject/subjectDomain), root cause (cause/causeDomain/causeIp), open (true = needs work, false = closed), status, and createdOn/lastUpdated. IMPORTANT: in compact mode the large details/evidence/evidenceText payloads are DROPPED from each record and the response envelope is stamped with compact: true — if you need those fields, set verbose:true (returns full raw records) or call certificates_get_issue for one issue. Sorted by severity then status ascending by default (override with sort). The Issues subsystem is under active development; response fields may evolve. To filter by affected host/domain, use the hostname param (exact match — internally translated to a subjectDomain:equals filter clause) or, for partial matches, a filter clause on subjectDomain (e.g. { field: “subjectDomain”, op: “contains”, value: “example.com” }). Use offset to page past a single limit-sized batch — offset always pairs with the current sort for deterministic paging. For richer filtering (by issueId, definitionId, title, subjectDomain, category, severity, status, or groups) use the filter array, AND-ed by default (OR via filterConnector). Unknown top-level keys are rejected (strict schema) — typos surface as validation errors instead of silently unfiltered pages.
| Parameter | Type | Required | Notes |
|---|---|---|---|
categories | string | No | — |
status | string | No | active, snoozed, completed, ignored, bogus, orphaned, abandoned, deprecated |
open | boolean | No | — |
severity | any | No | — |
group | any | No | — |
hostname | string | No | — |
limit | number | No | — |
offset | number | No | — |
updatedSince | string | No | — |
filter | object[] | No | — |
filterConnector | string | No | AND, OR |
sort | string | No | — |
totalCount | boolean | No | — |
totalCountLimit | number | No | — |
verbose | boolean | No | — |
certificates_get_issue
Section titled “certificates_get_issue”Retrieves the complete record for one Hardenize issue by issue_id (from certificates_list_issues). Returns the list-summary fields plus the full details object — a problem-specific, type-tagged payload (read details[“@type”]) with the supporting evidence. Key fields: subject/subjectDomain (affected asset / impact), cause/causeDomain/causeIp (root cause), severity (info < low < medium < high < critical < urgent) and category, title/description (the problem), createdOn/lastUpdated/lastConfirmed (timing). Lifecycle: open (true = needs work, false = closed) plus status — open: ‘active’ (unresolved), ‘snoozed’ (deferred, auto-reverts to active); closed: ‘completed’ (no longer manifesting), ‘ignored’ (accepted risk), ‘bogus’ (false-positive), ‘orphaned’ (affected asset gone or unmonitored), ‘abandoned’ (monitoring stopped), ‘deprecated’ (detection logic no longer applies). Use after certificates_list_issues to diagnose/remediate a specific certificate, TLS/PKI, or DNS issue. The Issues subsystem is under active development; fields may evolve.
| Parameter | Type | Required | Notes |
|---|---|---|---|
issue_id | string | Yes | — |
certificates_list_identities
Section titled “certificates_list_identities”Lists Hardenize identities linked to the Certificates account. Supports pagination via limit and offset, and returns both identities and totalCount.
| Parameter | Type | Required | Notes |
|---|---|---|---|
limit | number | No | — |
offset | number | No | — |
certificates_enable_identity
Section titled “certificates_enable_identity”Enables a Hardenize identity linked to the Certificates account.
| Parameter | Type | Required | Notes |
|---|---|---|---|
identity_id | number | Yes | — |
certificates_disable_identity
Section titled “certificates_disable_identity”Disables a Hardenize identity linked to the Certificates account.
| Parameter | Type | Required | Notes |
|---|---|---|---|
identity_id | number | Yes | — |
certificates_complete_onboarding_setup
Section titled “certificates_complete_onboarding_setup”Completes the initial onboarding setup for a Certificates account. Creates a Hardenize organization, configures host defaults, and sets the owner and notification email to the provided address. After successful completion, all other Certificates API endpoints become available, including bulk host creation.
| Parameter | Type | Required | Notes |
|---|---|---|---|
email | string | Yes | — |
OnDMARC tools
Section titled “OnDMARC tools”ondmarc_list_sources
Section titled “ondmarc_list_sources”Lists all sources (IP addresses, domains, and mail servers) sending email on behalf of the specified domain, based on DMARC aggregate reports from the last 7 days. Use optional start and end parameters (format: YYYY/MM/DD) to analyze a different time period. Useful for identifying authorized and unauthorized email sources.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
start | string | No | — |
end | string | No | — |
ondmarc_compliance_report
Section titled “ondmarc_compliance_report”Retrieves aggregated DMARC validation reports for the specified domain covering the last 7 days. Shows pass/fail rates for SPF and DKIM authentication, message volumes, sending sources, geographic distribution, and reasons for any authentication overrides. Use optional start and end parameters (format: YYYY/MM/DD) to analyze a different time period.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
start | string | No | — |
end | string | No | — |
ondmarc_dns_guardian_get_issues
Section titled “ondmarc_dns_guardian_get_issues”Retrieves DNS security issues detected by DNS Guardian monitoring. Returns details about dangling DNS records, nameserver problems, SPF subdomain takeover risks, and other DNS vulnerabilities across your monitored domains. Use this to identify and remediate DNS-based security risks.
Parameters: None required.
ondmarc_list_domains
Section titled “ondmarc_list_domains”Retrieves all domains managed by the OnDMARC account. Returns comprehensive domain information including domain names, DMARC policy configuration (policy status, validation issues, warnings), associated tags, notes, and Dynamic SPF activation status (hasDynamicSpf). Use this to get an overview of all monitored domains, check their DMARC compliance status, identify domains with configuration issues, or manage domain organization through tags.
Parameters: None required.
ondmarc_add_domain
Section titled “ondmarc_add_domain”Adds a new domain to the OnDMARC instance for monitoring and DMARC compliance tracking. Optionally auto-identify and classify sources that are recognized in the domain’s existing SPF record.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
auto_identify_sources | boolean | No | — |
ondmarc_get_tags
Section titled “ondmarc_get_tags”Retrieves a list of all tags created for this OnDMARC account. Returns tag objects with their IDs, titles, descriptions, and colors.
Parameters: None required.
ondmarc_add_domain_tags
Section titled “ondmarc_add_domain_tags”Adds tags to a domain in the OnDMARC instance. Tags help organize and categorize domains for better management and filtering. Provide tag titles as a list of strings.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
tags | string[] | Yes | — |
ondmarc_remove_domain_tags
Section titled “ondmarc_remove_domain_tags”Removes tags from a domain in the OnDMARC instance. Provide tag titles as a list of strings. The tool will automatically look up the corresponding tag IDs.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
tags | string[] | Yes | — |
ondmarc_activate_dynamic_services
Section titled “ondmarc_activate_dynamic_services”Activates OnDMARC’s Dynamic Services (Dynamic SPF) for the specified domain. Dynamic Services helps you stay within SPF lookup limits by consolidating multiple SPF includes into a single dynamic record that OnDMARC manages. This simplifies SPF record management and prevents SPF validation failures due to exceeding the 10 DNS lookup limit.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
ondmarc_update_dynamic_dmarc
Section titled “ondmarc_update_dynamic_dmarc”Updates the Dynamic Services DMARC record settings for the specified domain. Only the DMARC tags provided in dmarc_settings are changed; others keep their original values. The domain must have Dynamic Services activated. Valid DMARC tags: rua (aggregate report address), ruf (forensic report address), p (policy: none/quarantine/reject), pct (percentage: 0-100), adkim (DKIM alignment: r/s), aspf (SPF alignment: r/s), fo (failure reporting options: 0/1/d/s), rf (report format: afrf), ri (report interval in seconds), sp (subdomain policy: none/quarantine/reject).
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
dmarc_settings | object | Yes | — |
ondmarc_tlsrpt_overview
Section titled “ondmarc_tlsrpt_overview”Retrieves the TLS-RPT (SMTP TLS Reporting) overview report for the specified domain covering the last 7 days. Returns successful and failed TLS connection counts broken down per receiving provider (e.g., Google, Microsoft, Yahoo) and per day, useful for monitoring inbound mail TLS health. Use optional start and end parameters (format: YYYY/MM/DD) to analyze a different time period.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
start | string | No | — |
end | string | No | — |
ondmarc_syntax_fix_dmarc
Section titled “ondmarc_syntax_fix_dmarc”Detects DMARC policy syntax errors for the given domain using the OnDMARC analyzer. Returns the raw record together with a list of human-readable issues. Use when a customer reports DMARC configuration problems.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
ondmarc_syntax_fix_spf
Section titled “ondmarc_syntax_fix_spf”Detects SPF policy syntax errors for the given domain using the OnDMARC analyzer. Returns the raw record together with a list of human-readable issues. Use when a customer reports SPF configuration problems.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
ondmarc_classify_sender_source
Section titled “ondmarc_classify_sender_source”Classifies a sending source (IP, domain, or known service identifier) into asset / threat / forwarder for the given OnDMARC-managed domain. Orchestrates compliance, subdomain, blocklist and reputation lookups; short-circuits when the source is already classified or has a recommendation. Returns rich signals plus a prompt scaffold for the agent.
| Parameter | Type | Required | Notes |
|---|---|---|---|
domain | string | Yes | — |
sourceId | string | Yes | — |
Pulse tools
Section titled “Pulse tools”pulse_get_enabled_services
Section titled “pulse_get_enabled_services”Retrieves comprehensive subscription settings and service configurations for the Pulse instance. Returns detailed information including Radar service features (main service, chat, and inbox enablement status), EventHub integrations availability, audit logs configuration, usage limits (maximum Radar users allowed), and subscription metadata (trial status, region, admin privileges). Use this to verify which Pulse services are enabled, check feature availability before performing operations, understand usage quotas, and troubleshoot service access issues.
Parameters: None required.
pulse_list_integrations
Section titled “pulse_list_integrations”Lists all EventHub integrations configured in the Pulse instance. Returns an array of integration objects, each containing the integration name, ID, type, services, and categories.
Parameters: None required.