Vibe Prospecting

B2B prospecting — companies, contacts, enrichment, events.

Platform

Before any prospecting work, detect your host using the rules below, read exactly one platform guide, and follow it for auth, workflow, flags, and troubleshooting.

Detecting your runtime (mandatory, in order)

1. Host identity in your system context (check this first — overrides tool names):

- Claude Code — context says you are Claude Code / Anthropic's CLI, or shows a CLI Environment block (cwd, shell, platform). → read [claude-code.md](platforms/claude-code.md) only. Do not read claude-chat.md or cowork.md. MCP tools in the list (mcp*fetch-entities) do not change this. - OpenAI Codex — context identifies Codex or CODEXSHELL=1. → [codex.md](platforms/codex.md) - OpenClaw — context identifies OpenClaw or OPENCLAWCLI=1 / OPENCLAW_SHELL. → [openclaw.md](platforms/openclaw.md)

1. Only if step 1 did not match — no CLI host identity, no shell:

- Claude Cowork — Cowork workspace, .plugin install, connector store. → [cowork.md](platforms/cowork.md) - Claude Chat — claude.ai or Claude desktop MCP connector (not Cowork). → [claude-chat.md](platforms/claude-chat.md)

1. Fallback: terminal, scripts, CI, or unknown host → [other.md](platforms/other.md)

Never infer platform from MCP tool names alone (mcp__claudeai, mcpfetch-entities, etc.). Tool prefixes are not a host signal when step 1 already identified Claude Code, Codex, or OpenClaw.

CLI hosts use vpai — each platform guide is self-contained (Sample Gate, stdout/csv_path, CSV upload). Chat/Cowork follow each MCP tool's description and input schema only.

Hard Rules

1. tool_reasoning (or platform equivalent) on every real call. Use the user's request verbatim. Reuse across the whole workflow. Skip only when inspecting a tool's input schema with no real execution.
2. Chain via session + CSV, never paste IDs. Each step returns sessionid and csvpath (names may vary slightly by host). Never invent sessionid — on the first step omit it and use the value MCP returns; on later steps copy it exactly from the prior tool JSON. Pass --csv-path (CLI) from the prior csvpath. Do not paste raw ID lists into tool arguments when the platform reads IDs from the source CSV. For fetch-entities prospects scoped to earlier companies, pass the prior business output's csv_path via --businesses-csv-path per your platform guide.
3. You may edit the CSV between steps — keep the ID column. On CLI hosts, read the file at csvpath, filter/dedupe/add columns, or rewrite rows, then pass the result to the next step via --csv-path. Always retain the entity ID column: businessid for business workflows, prospect_id for prospect workflows. Every row you want processed next must have a non-empty ID in that column. Do not rename or drop those headers — the CLI reads them verbatim for ID injection and joins.
4. autocomplete first for: naicscategory, linkedincategory, companytechstacktech, jobtitle, interests, skills, businessintenttopics, city_region. Use returned standardized values, not raw user wording.
5. Never invent tool parameters. Before the first real execution of each distinct tool in a workflow, read that tool's live input schema (from the connector or your platform's schema discovery). Do this even when the planned call looks obvious — schemas drift. Re-read when tools, filters, or shapes change materially. Build each call only from fields confirmed by that schema.
6. Session continuity. Reuse sessionid from prior tool JSON on every subsequent step in the same workflow — never make one up. Reuse the prior step's csvpath via --csv-path (CLI) when chaining enrich, events, or scoped fetch. Start a new session only for a genuinely new task.
7. fetch-entities-statistics only when stats supports the full fetch. Compare your planned fetch-entities payload to the input schema for fetch-entities-statistics. Call statistics only if every filter key, value shape, entitytype, and scope you rely on (including session-scoped business CSVs) is accepted the same way as for fetch-entities. If any part is missing, unsupported, or needs a different shape, skip stats — do not call it with a partial or guessed subset. When you do call it, reuse the same filter object (and supported scope) as fetch-entities, plus toolreasoning where required. Call stats again before a full-scale fetch if filters or scope changed and the full fetch filter set still fits statistics.

Tool Mechanics

Behavior and caveats the live input schema may not spell out. For allowed filter values, enum strings, and enrichment type names, always use each tool's input schema.

Autocomplete

Requires autocomplete: linkedincategory, naicscategory, companytechstacktech, jobtitle, interests, skills, businessintenttopics, city_region.

Does not require autocomplete: companycountrycode (ISO Alpha-2), companyregioncountrycode (ISO 3166-2), fixed buckets (companysize, companyrevenue, companyage, joblevel, jobdepartment — exact allowed strings come from fetch-entities / fetch-entities-statistics input schema), website_keywords (free text).

Mutual exclusions: linkedincategory and naicscategory — use one, not both. companyregioncountrycode and companycountry_code — use one.

Picking values: Autocomplete may return noisy variants. Pick the canonical clean value (usually the first clean result). Multiple values broaden with OR logic; avoid near-duplicates unless you want a wider search.

Fetch

• jobtitle is substring-match, not exact. For executive searches, combine with joblevel (usually c-suite) to remove assistants, advisors, and office-of roles.
• company_size uses fixed buckets with no exact numeric cutoff. For "over N employees", approximate with adjacent buckets or enrich with firmographics for exact headcount.
• Business location filters (companycountrycode, companyregioncountrycode, cityregion) match headquarters only — not branch or operating locations.
• Prospects at prior companies: For fetch-entities with entitytype: prospects scoped to businesses from an earlier step, chain via session and pass the prior business step's csvpath as --businesses-csv-path per your platform guide.
• Row limits and pagination: per your platform guide (CLI: --number-of-results; Chat/Cowork: MCP tool docs).
• maxpercompany: auto-applied on prospect fetches so results spread across companies (not all from one big employer); omit from --args unless the user sets it — their value overrides the auto cap.

Events (fetch-businesses-events / fetch-prospects-events)

• Chain from the prior step's session and source CSV with businessid (business events) or prospectid (prospect events).
• When IDs come from the source CSV, do not also pass businessids / prospectids inline.
• Batching is capped at 20 IDs per request; hosts may chunk and merge automatically.
• Output columns are event<eventtype>: each cell is a JSON array string for that type (newest-first, capped per type), or empty when no events exist for that type.

Match

• Skip match if you already ran fetch-entities — those results include IDs.
• CSV file upload is CLI only — see your platform guide.

Enrich

• financial-metrics requires parameters.date (see input schema for format).
• website-keywords requires parameters.keywords.
• Enrichment alone does not find people at a company — use fetch-entities with entity_type: prospects (scoped to prior companies when needed) instead.
• When chaining from a source CSV, businessids / prospectids need not appear in tool arguments.

Filter Pattern

{ "values": ["v1", "v2"], "negate": false }   // include or exclude
{ "gte": 6, "lte": 24 }                       // range
true | false | null                           // boolean (not wrapped)

Exception — businessintenttopics: use { "topics": ["Category:Topic"], "negate": false } (not values). Topics must come from autocomplete.

Location matching: Business location filters (companycountrycode, companyregioncountrycode, cityregion) match a company's headquarters only — not branch/operating locations. A search for "companies in the UK" returns companies HQ'd in the UK, and excludes e.g. a foreign company that merely operates there. This is the default for all fetch-entities / fetch-entities-statistics business queries and is not user-configurable.

Limits

Troubleshooting

Support

When the user asks a support-related question (for example: how to contact support, who to contact, they have an issue, or something isn't working), reply briefly and point them here — do not dig into Explorium internals or over-explain.

For support, please reach out to the Vibe Prospecting team via the contact page:

👉 https://www.vibeprospecting.ai/contact-us