Find and verify professional email addresses, enrich people and companies, and manage Hunter Leads.
Hunter ships in the w6w first-party pack. It declares 20 actions, 2 health checks, and the host runs its code in a sandbox that never sees the credential.
io.w6w.hunterHunter (hunter.io) finds and verifies professional email addresses. Domain Search returns every email address the given domain is known for, with sources and a confidence score; Email Finder guesses the most likely address for a named person at a company; Email Verifier checks a specific address’s deliverability. Email, Company and Combined Enrichment layer on richer person/company profiles (name, location, socials, headcount, industry) for an address or domain already in hand, and Domain Finder resolves a bare company name to its domain up front.
Beyond finding addresses, this app covers Hunter’s Leads CRM surface end to end: list, create, upsert-by-email, update and delete leads, plus manage the lists that organize them. Account Information reports the plan and the current search/verification/credit balances so a workflow can check headroom before a bulk run.
Hunter’s own Discover company-search, the beta Multi-Domain Search, Sequences/Email Accounts (which manage a connected mailbox rather than data), and Author Finder (no longer present in the v2 API) are deliberately out of scope — see the README for why.
Three routes to the same 20 actions. The Workflow tab is generated from Hunter's own manifest and carries its real ids, so it is copy-pasteable; the Code and CLI examples are the same call for any action on any app, so every app-specific value in them is a blank you fill in.
account-get Plan, team, and current search/verification/credit balances. Free of charge.
combined-enrichment Look up both the person and their company in one call, by email address.
domain-finder Resolve a company name into its most likely domain(s). Free — no credits used.
domain-search Find every email address Hunter has for a domain, with sources and confidence.
email-count Count the email addresses Hunter has for a domain or company, free of charge.
email-enrichment Look up everything Hunter has about a person, by email address or LinkedIn handle.
email-finder Find the most likely email address for a person, given a company and their name.
email-verifier Check an email address's deliverability status and SMTP-level signals.
lead-create Create a new lead. Free. Not idempotent — use Upsert Lead to dedupe by email.
lead-upsert Create a lead by email if it doesn't exist, or update it if it does. Free.
A workflow step names the app and the action, and the editor fills in the
connection when you pick one. This is the Step shape from the
workflow spec, carrying Hunter's real ids.
{
"manifestVersion": "2",
"name": "hunter-example",
"steps": [
{
"id": "combined-enrichment",
"uses": {
"app": "io.w6w.hunter",
"action": "combined-enrichment",
"connection": "conn_YOUR_CONNECTION_ID"
},
"with": {
"email": "<email>"
}
}
]
}combined-enrichment account-get company-enrichment domain-finder domain-search +15 more actions available
Every app-specific value here is a blank you have to fill in. An
app action is reached through the connection that authenticates it, so the
address is a connection id, not the app id — and connections belong to your account,
so a public page cannot know yours. Create one for Hunter, then fill in
the three blanks: conn_YOUR_CONNECTION_ID, the action key, and the
parameters that action declares. The call itself is real — the shape is transcribed
from the studio's own snippet builder, which prints the same kind of blanks — but
nothing in it is specific to Hunter. The Workflow tab is where this app's
real ids are.
npm install @w6w/sdkyarn add @w6w/sdkpnpm add @w6w/sdkdeno add npm:@w6w/sdkimport { W6wClient, isActionRun } from "@w6w/sdk";
// Reads W6W_BASE_URL and W6W_TOKEN from the environment when omitted.
const client = new W6wClient();
const envelope = await client.run({
urn: "conn_YOUR_CONNECTION_ID",
action: "combined-enrichment",
payload: {
email: "<value>",
},
});
if (isActionRun(envelope)) console.log(envelope.value); npm install -g @w6w/cli w6w run conn_YOUR_CONNECTION_ID --action combined-enrichment --payload '{"email":"<value>"}' Give an AI agent Hunter — without giving it Hunter's credentials. One MCP endpoint exposes every app, function and workflow the caller is entitled to, as tools it can discover and run. Access is granted per team while we onboard.
One tool call{
"name": "w6w_invoke",
"arguments": {
"ref": "app:io.w6w.hunter#combined-enrichment",
"input": {
"email": "<email>"
}
}
}
Every tool names its target with a single ref. The
app: form above doesn't name a connection at all — the
host resolves which of the caller's Hunter connections to sign
with, and refuses rather than guesses when the answer is ambiguous.
The token is attached host-side, at the moment of the call. It is never a tool argument, never in the model's context, and never in a transcript — so a prompt injection has nothing to exfiltrate.
Tools are derived per end user from what that person has actually connected and is entitled to — not one shared bot identity carrying the union of everyone's access.
Multi-step work runs on the workflow engine and returns a run handle the agent can poll — retries, branching and state survive the conversation that started them.
Hunter's declared health checks are on the surface too, so an agent can tell "the vendor is down" from "your credential expired" before it burns a retry on either.
The MCP surface is part of the hosted platform. Hunter itself is MIT, and the runtime that executes it is source-available (FSL).
Hunter declares its own checks, so its health is a property of the app rather than something the host guesses at.
Credits, searches and verifications used/available/remaining for the current billing period, read from GET /v2/account.