--- name: mixrank-cli description: Use the MixRank native CLI for API discovery, company and person data, bulk enrichment, email validation, exports, and troubleshooting. --- Use `mixrank --help` and `mixrank endpoints` to discover the installed version. If `mixrank` is not on PATH, use the plugin's `scripts/run-mixrank` launcher (or `scripts/run-mixrank.ps1` on Windows) with the same arguments. The launcher installs a checksum-verified, version-pinned binary if the bundle does not already contain one. Read [the generated operation reference](references/operations.md) for the relevant family. `mixrank endpoints OPERATION` shows its parameters, encoding, response fields, permissions and source. `mixrank api COMMAND --help` lists actual flags; command names replace operation underscores with hyphens. Read [recipes](references/recipes.md) for end-to-end examples. For lead generation or business follow-up, use `mixrank contacts --companies companies.json --output contacts.json` after discovery, or `mixrank contacts --domain example.com`. This shared workflow finds current relevant people and appends actual available B2B emails and direct dials. It accepts company arrays, a `companies` export, or raw company-search hits. Defaults: two contacts and ten candidates per company, at most 25 companies and 100 workflow API calls. Read `mixrank contacts --help` for role filters and bounds. MCP exposes the same operation as `mixrank_company_contacts`. Report company-level gaps and review flags; a company-only export does not fulfill a request for contacts. - Authentication: let the host prompt for a plugin secret when supported. For CLI/Codex use `mixrank auth login` (masked OS-vault entry) or explicit stdin. Never put a key in arguments, a repository, a skill, or a client configuration file. Runtime `MIXRANK_API_KEY` overrides the MixRank vault entry. `mixrank auth status` reveals availability only. - Pass JSON with `--body request.json` or `--body -`; query parameters with named flags or repeatable `--query key=value`. The SDK passes full Elasticsearch DSL unchanged and preserves integer precision. - Bulk input is UTF-8 newline-separated text via `--upload`. Preserve job IDs; inspect status and download the returned result URL. Do not resubmit after timeout merely because the outcome is unknown. - Use `--output filename` for binary/large responses; it refuses existing files. `--format jsonl` or `csv` exports object rows; CSV formulas are escaped. Offset pagination requires a finite `--max-pages`; it emits one JSONL envelope per page. Elasticsearch pagination stays explicit in DSL. - Prefer bulk email validation for lists. Single validation is serialized per credential across local toolkit processes. Separate hosts need coordination. Do not evade the rule with shell parallelism, raw calls, or another client. Only run authorized checks; `doctor --live` uses a single echo call. - LiveScan defaults to cached. A requested fetch/strict/besteffort strategy requires `--refresh`. Changing strategy is a user decision; no implicit fallback or retry. Posts also document refresh as of the catalog date. - Keep partial outputs and job identifiers on failure. 403 can mean missing license; 512 is a temporary LiveScan fetch failure and 513 permanent. Report provider errors and source dates without exposing credentials. Never treat an empty object as equivalent to absent/null data. Exit codes: 0 success; 2 local input/config error; 3 credentials or permission; 4 rate limit; 5 upstream failure; 6 uncertain side-effect outcome; 130 cancellation. A successful 202 means accepted, not completed. For asynchronous one-off validation, use `mixrank validation status` and acknowledge the matching signed callback with `validation ack --headers headers.json --body callback.json`; later one-offs remain blocked until then. Clear uncertain state only after independently confirming provider completion. Contacts use one array with `has_email`, `has_phone`, and `enrichment_status`. Use `--contact-filter all|any|email|phone|both|none|valid-email` to select rows. `--contactable-only` is the company-level email-or-phone mode and reports omitted businesses in `companies_filtered`. `all` includes discovered people not yet enriched; unknown is not unavailable. Lookups run with bounded parallelism (`--concurrency`, default 4, max 16). `--validate-emails` deduplicates addresses into one bulk job, waits up to `--validation-wait` (default 30s), and attaches provider validity and evidence. Preserve a pending report and its job ID, then use `contacts validate --input REPORT` or MCP `mixrank_validate_contacts` to resume without resubmission. Pending validation defers filters to preserve submitted emails. Never parallelize single-address validation. For businesses with no person-level channel, `--places-fallback` makes one explicit Google Places lookup. A matched listing is another row in `contacts` with `contact_type: business`, `business_phones`, `website_uri`, `place_id`, and `source: Google Places business listing`. It is a business phone, not a direct dial, and Places does not return individual emails. This option requires `mixrank auth google-places login` or a runtime `GOOGLE_PLACES_API_KEY`; it is billable, bounded by the shared request budget, and never retried automatically. Preserve `places_lookup` status and Google Maps attribution in user-facing output. Company-contact workflows automatically merge duplicate input rows by shared company IDs or normalized domains before requests. Supply raw rows directly; retain `company_merge` counts, `company_ids`, `name_aliases`, and `domain_aliases`. Names alone never merge companies. Shared-domain branches consolidate as one business account; use distinct IDs without the shared domain when location separation is required. Up to 250 input rows may resolve to at most 25 companies. Do not preprocess aliases in agent scripts.