ActiveProspect MCP

Load the full markdown of an ActiveProspect skill — a reference playbook for a specific workflow — by name. When a tool, instruction, or another skill says "see the X skill," load `X` before that work. When a loaded skill points at a reference file (a `references/…` path), call this tool again with that path as `file` to read it. The skills: - `interpreting-accounts` — How to read an account record: billing_type vs cpl_enabled (what kind of customer), products and feature_subscriptions (what they can use), state and roles. - `caps-and-limits` — Caps (accepted-lead limits) vs ping limits, reading the live usage counters, and why only active counters return. Use to answer "what is maxed out / near its cap", how much headroom remains, or when a cap resets. - `entities` — What entities are, source/recipient roles, standard vs account vs custom (and which are editable), the module_ids constraint, renaming hazards, and deprecate-do-not-delete. Read before create_entity/update_entity or when choosing a source/recipient role. - `event-metrics` — Aggregates over events — counts, unique values, medians, funnels, and time series — and how group_by, interval, and timezone combine. Use for "how many leads last week", failure rates, drop-off, or median cost; not for individual records (see leads). - `fields-and-variables` — The variable path model behind every group_by and filter lhv/property_name: prefixes (lead/source/flow/recipient/...), the vars.-prefixed event paths vs bare flow-rule paths, step-result variables (suppressionlist.*, trustedform.*), field types and sub-properties, lead vs appended data, and listing/creating fields. Read before writing any group_by, filter path, or flow rule field. - `flow-patterns` — The canonical LeadConduit flow shape (filter → verify → suppress → certify → deliver), the decision matrix for where a rule belongs (flow acceptance criteria vs source acceptance criteria vs filter step vs recipient when-rules), per-vendor treatment inside one flow, and test-traffic exemptions. Load whenever designing, reviewing, or explaining a flow's structure or step order — including "does this flow look right", "where should this rule go", or "add a filter/step to my flow" — before assembling a create_flow or update_flow body. **Required before assembling a create_flow or update_flow body.** - `flows-workflow` — How to build, update, test, and deploy a LeadConduit flow: the lifecycle, the lookup tools that resolve names to ids, the high-level create_flow input shape (sources, filters, recipients, mappings), safe-update rules, and reading test outcomes. For flow *design* decisions — step order, where rules belong, suppression/dedup mechanics — this skill routes to flow-patterns and suppression-and-dedupe. **Required before assembling a create_flow or update_flow body.** - `leadconduit-glossary` — Definitions of the core LeadConduit domain terms and the two filter shapes (ReportRule vs KeenFilter). Read when a term in a tool description is unfamiliar, or you are unsure which tool family a request belongs to. - `leads` — Finding and reading individual lead records (search_leads, get_lead_event, list_lead_events), the lead-vs-event distinction, and which identifiers external systems can actually join on. Use when the user wants a specific person/record — "show me Bob Smith's lead" — or is reconciling CRM/vendor data against LeadConduit; not for aggregate counts (see event-metrics). - `reports-workflow` — Creating, previewing, running, updating, sharing, and deleting saved reports — read vs write tools, the columns/grouping/rules shape, and translating business asks (vendor scorecards, net leads, cost per lead) into columns. Use for reusable, named, multi-column metric definitions, vs ad-hoc counts (see event-metrics). - `rules-and-operators` — The rule operator catalog shared by flow filters and report rules, field-type compatibility, the matches-pattern glob-vs-regex trap, how a step-result (appended-data) path derives from the step entity name, and where a rule should live (acceptance criteria vs filter vs recipient when-rules). **Required before writing any rules (flow rules, filter steps, or report rules).** - `suppression-and-dedupe` — The SuppressionList lookup→filter→add pattern for DNC lists, duplicate control, and geographic (ZIP allow-list) targeting inside a LeadConduit flow: the query_item/add_item integration modules, the found-is-true vs found-is-false polarity, add-item placement, dedup exemptions, list naming and lookback conventions. Load whenever a flow needs DNC, dedup/duplicate, suppression, blocklist, territory, service-area, or ZIP/postal-code logic — or when such a step misbehaves (blocking everything or nothing). - `vertical-vocabulary` — Translating industry business language into LeadConduit metrics — funnel stages (sets, issued appointments, demos, gross/net sales), dispositions, CRM stages, cost-per-X and ROI asks — and being explicit about what LeadConduit cannot compute because it happens after delivery. Load whenever a user asks about vendor performance, conversion, cost per sale/set/appointment, ROI, close rate, dispositions, or any funnel stage past lead delivery, even if they never name a LeadConduit metric. Read references/home-services.md for the home-services glossary and CRM landscape. - `account-binding` — How each MCP variant selects an account, and how to recover from no_account_selected. - `errors` — Common tool errors and how to recover from each. - `invitations` — Inviting a partner company to connect on the network: invite_partner's inputs (seller/buyer role, email vs directory company_id), how LeadConduit mirrors an invitation as a pending source entity usable in flows, duplicate checks, and resend rules. Read before invite_partner/resend_invitation, or when a LeadConduit flow needs a source or recipient for a partner that is not connected yet. **Required before sending or resending a partner invitation.**

Get the current user's membership on the current account: who they are, their roles, and the full account record. Use this for questions about the current user or about what kind of account this is (plan, products, state).

List memberships of the current account. Returns the users on this account and their roles, each embedding the full account record; does not include API keys.

List domains owned by the current account.

Get the current account's own network company profile, including role, verticals, lead criteria, payment details, and profile-completion status. For companies you are connected to, use `list_connected_companies`; to browse other sellers, use `list_directory_sellers`.

List the company profiles of every company connected to the current company. Returns each connected company's profile (name, role, verticals, connection status). For the connection relationship records themselves (relationship_type, permissions), use `list_connections`.

List the introductions sent and received by the current company. Returns two groups: `sent` (introductions this company made to directory sellers) and `received` (introductions other buyers sent to this company).

Send a network invitation asking a partner company to connect with this account. The network is the single system of record for invitations and connections; downstream products sync invitation state from it in the background. Invite by `email`, or by directory `company_id` (from list_directory_sellers) — exactly one of the two. Check list_connections and list_invitations first to avoid inviting an already-connected partner or duplicating a pending invite. Load the `invitations` skill with `load_skill` first.

Resend a pending network invitation email. Find the invitation with list_invitations — each carries `resend_allowed` and `resend_allowed_at`, and resending before `resend_allowed_at` is rejected. For a pending flow source entity, its `invitation_id` is the invitation to resend. Load the `invitations` skill with `load_skill` first.

List connection invitations sent by the current company. Pass `status` to filter — e.g. `["pending"]` for invites still awaiting a response. Omitting `status` returns invitations in every state.

List the current company's network connections. Each connection is the relationship record with another company — it carries the relationship_type (buyer/seller) and the permissions granted to you. For the connected companies' full profiles, use `list_connected_companies` instead.

Browse the seller directory to discover verified sellers. Returns a paginated page of seller company profiles. Requires the current account to have directory access (buyer role, contracted billing, and a product subscription); otherwise the call is rejected.

List all saved reports in the account — e.g. "show me my saved revenue-by-source report" or "what reports already exist before I create a new one."

Show the configuration of one saved report (its columns, filter rules, grouping, and share token). Accepts either a 24-char report ID or a share token.

Save a new report so it can be re-run later. A report defines which lead/event metrics to show (e.g. source-success, recipient-failure, cost, revenue), optionally grouped by source/recipient and filtered by rules. Load the `rules-and-operators` skill with `load_skill` first.

Change settings on an existing saved report (its name, columns, filters, or grouping). Only the fields you supply are changed, but each one replaces the existing value wholesale (columns/rules/group_by are not merged). Load the `rules-and-operators` skill with `load_skill` first.

Permanently delete a saved report. The report's share token (if any) stops working too.

Run a saved report over a time window and return the resulting metric rows — e.g. "show me last week's numbers for the Weekly Revenue by Source report." For an ad-hoc report you don't want to save first, use `preview_report` instead. Returns aggregate metrics only — for the actual lead records behind the numbers, use `list_lead_events`; to find a specific lead, use `search_leads`.

Run a one-off report for a time window without saving it. Use this for ad-hoc questions like "how many recipient errors did Acme Source have yesterday?" when you don't need to keep the report around. To run an already-saved report by ID or share token, use `run_report` instead. Returns aggregate metrics only — for the actual lead records, use `list_lead_events`; to find a specific lead, use `search_leads`. Load the `rules-and-operators` skill with `load_skill` first.

Generate a public share token for a saved report so the report can be viewed without an API key. Anyone with the token can run and read the report.

Revoke a saved report's share token. After this, the previous share link no longer works.

Show the column shape and grouping of a publicly shared report using only its share token (no API key needed). Use this when you have a report share link and want to know what metrics it exposes before running it.

Search LeadConduit flows in the account. Use this before creating a similarly named flow or before deploying an existing flow. Pass a query (a flow name fragment) to narrow accounts with many flows.

Get one LeadConduit flow by id, including sources, filters, recipient steps, fields, and deployment-relevant configuration. Each recipient step is annotated with appended_data_prefix and appended_data_paths — the exact variable paths a later filter rule may reference for that step's results (the namespace derives from the step's entity name; it cannot be guessed from the integration).

Search LeadConduit entities that can be used as flow sources or recipients. Use this to resolve a human-readable company name before calling create_flow. Pass a query (a company name fragment) to narrow large accounts instead of fetching every entity.

Get one LeadConduit entity by id, including its name, source/recipient roles, supported integration modules, and description. Resolve a name to an id with list_entities first.

Search LeadConduit integration modules that can be used by create_flow. Use inbound modules for sources and outbound modules for recipient delivery steps. Pass a query (e.g. "salesforce", "json") and/or direction to narrow the large catalog. The heavy request/response variable schemas are omitted unless include_variables is set.

List LeadConduit credentials used to authenticate integrations. Use this to resolve a credential name before referencing it from a source or recipient in create_flow. Secret values (token, password) are never returned. Credentials cannot be created through these tools — if the one a flow needs does not exist, the user must add it manually in the LeadConduit app first; never accept or pass a raw secret.

Search delivery destinations configured for the account in the LeadConduit app (Prismatic integration instances). These are pre-built outbound endpoints that follow a "configure once, reuse across flows" model and can each expose multiple actions (e.g. "Create Lead", "Update Contact"); add them to a flow as recipient steps. Destinations cannot be created or modified via the API — only listed and added to flows. Returns an empty list when none are configured. For the raw integration module catalog used to build a recipient from scratch, use list_integrations instead.

Create a source or recipient entity (a vendor, form, lead buyer, or CRM) in the account so it can be referenced by create_flow. create_flow only accepts entities that already exist, so call this first when the company the user named is not found by list_entities. Search list_entities first to avoid creating a duplicate — entity names must be unique within the account.

Update an existing CUSTOM LeadConduit entity. This is a merge-patch: it fetches the entity, applies only the fields you pass, and leaves everything else unchanged. Only custom (account-created) entities can be edited — standard and account entities are read-only and will fail. To retire an entity, set deprecated: true instead of deleting it (there is no delete tool). Resolve the entity id with list_entities first. To create a new entity use create_entity.

Create and save a new LeadConduit flow from high-level source, filter, and recipient intent. Sources and recipients are both optional: omitted sources default to the account's own entity with the standard inbound posting integration, and a flow saved without recipients accepts leads but delivers them nowhere until recipients are added. A source or recipient may also be named by a network connection id (from list_connections) or connected company name — it resolves to the partner's account entity, and saving the flow links that entity to the account with no UI step. This does not make the flow live; call deploy_flow with the returned id when the user wants the saved configuration deployed. Load the `flow-patterns`, `flows-workflow`, and `rules-and-operators` skills with `load_skill` first.

Update an existing LeadConduit flow by replacing its saved configuration with a full flow body. Required workflow: call get_flow first, transform the returned flow, then pass the full updated body here. A source/recipient entity id may be a network connection id (from list_connections) — it resolves to the partner's account entity automatically. Load the `flow-patterns`, `flows-workflow`, and `rules-and-operators` skills with `load_skill` first.

Remove exactly one step from an existing LeadConduit flow. Use for requests like "remove this recipient/filter step from my X flow."

Remove matching rule checks from one LeadConduit flow. Use for requests like "remove the state check from my X flow"; prefer remove_flow_step when the user wants an entire step removed. Load the `rules-and-operators` skill with `load_skill` first.

Deploy a saved LeadConduit flow so its latest configuration is live for lead handling. Use after create_flow when the user explicitly wants the saved flow to start processing leads.

Test one recipient step in a LeadConduit flow with supplied submission data. This runs LeadConduit step-test handling and can create test events.

Submit a test lead to a LeadConduit flow source and optionally verify the recorded events. This can exercise deployed recipient deliveries.

Verify a recently submitted LeadConduit test lead by querying recorded events. Use after submit_test_lead, or when the user gives a reference/email/phone for a test lead.

Search LeadConduit fields (standard and custom) that flows, rules, and mappings can reference. Use it to resolve a field id, name, or data type before referencing one in create_flow or a report rule. To add a custom field that does not exist yet, use create_field.

Create a CUSTOM LeadConduit field so flows, rules, and mappings can reference it. Prefer a standard field first: search list_fields and only create a custom field when nothing fits, since standard fields are normalized and map automatically across accounts while custom fields raise setup/maintenance cost. create_flow rejects a field id that does not exist, so call this once you have confirmed no standard field matches. Standard fields are built in and cannot be created. The field id is derived from the name plus the account field suffix, so it may differ from a bare slug of the name.

List active LeadConduit cap counters with their current usage. A cap limits how many successful leads a flow accepts over a time window. Only caps that received lead traffic in the current interval are returned. Use it to answer "which caps are maxed out or close to their limit?". For ping (pre-bid) limits use list_ping_limits.

List active LeadConduit ping-limit counters with their current usage. A ping limit caps how many pings (pre-bid requests) a flow or source accepts over a time window. Only ping limits that received ping traffic in the current interval are returned. For accepted-lead caps use list_caps.

List LeadConduit changelogs — the audit trail of create/update/delete changes made to flows, entities, fields, and reports. Each entry summarizes who changed what and when. Pass resource_type and resource_id together to scope to one flow, entity, or field; omit both for the account-wide trail. For the full change detail and revision delta of one entry, use get_changelog.

Get one LeadConduit changelog by ID, including its full normalized change list and the raw delta from the previous revision. Use it to answer "what exactly changed and who did it?" after finding the entry with list_changelogs.

Count how many lead events happened in a time window — e.g. "how many leads were submitted last week," "how many recipient calls failed yesterday." Optionally bucket by day/hour and break down by source, recipient, outcome, or any other lead field. Pick this over `get_lead_stats` for time-series ("show me daily counts") or arbitrary Keen-style filters. Returns counts only — for the actual lead records use `list_lead_events`; to find a specific lead by name/email/phone use `search_leads`.

Count how many distinct values appeared for a lead/event field — e.g. "how many unique sources sent us leads," "how many unique phone numbers we received this month," "how many distinct buyers we delivered to." Returns a number, not the values themselves — use `list_unique_lead_values` to see the actual values, or `list_lead_events` for the underlying lead records.

List the actual distinct values that appeared for a lead/event field over a time window — e.g. "which sources sent leads last week," "which buyer destinations got calls today," "every unique zip code we received this month." This is also the DISCOVERY tool: when you need to filter by a specific source.id / recipient.id / state / etc. but don't yet know what values exist, call this with the field as `target_property` to enumerate them, then plug a value into `list_lead_events.rules` or another tool.

Measure drop-off through a multi-step lead pipeline: of the leads that hit step 1, how many made it to step 2, then step 3, etc. Use this for funnel analysis like "submitted → accepted by source → delivered to buyer → converted." Returns funnel counts only — for the actual lead records that progressed (or didn't) use `list_lead_events` with appropriate rules.

Get the median (typical) value of a numeric lead/event property over a time window — e.g. median cost per lead, median revenue per lead, median processing latency — optionally broken down by source, recipient, or module. Returns one median per group, not lead records — for individual leads use `list_lead_events`.

Get tabular lead and event counts grouped by source, recipient, outcome, or any lead field, with optional time bucketing and computed metrics like cost, revenue, profit, and success rates. This is the data that powers saved reports — pick this over `count_lead_events` when you want a spreadsheet-shaped result with the same metric columns reports use. Returns aggregate counts/rates only, not lead records — for the actual leads in the window use `list_lead_events`; to find a specific lead use `search_leads`.

List lead events (one event per flow step, with the lead snapshot embedded). This is the standard "show me the leads" call — returns the actual lead records (collected fields, appended data, outcomes) for the time window. With the default type=["source"] you get ONE event per lead — the canonical post-processing snapshot — i.e. the natural "list me leads in this window" call. Drop or change type to drill into per-step events ("recipient" for delivery events, "filter" for filter steps, etc.). Pagination is cursor-based via after_id / before_id; do not use page numbers. Each event can be large (full lead + appended data), so prefer small limits or use include/exclude to trim fields.

Fetch a single lead event by its 24-char hex ID. Returns the full event including the lead snapshot — every field collected at submission plus everything appended by prior flow steps. Use this when `list_lead_events` or `search_leads` gives you an event ID and you want the full record. Note: a single event can be large; prefer it for one-record drill-ins, not bulk fetching.

Full-text search across leads. Indexed fields: first_name, last_name, email, phone_1, phone_2, address_1, city, state, postal_code, reference. Returns { hits, total } where each hit has a lead_id, a latest_event_id you can pass to get_lead_event for the full record, and highlighted matched terms. Use this when the user asks something like "find the lead from Bob Smith" or "what was that lead with email foo@bar.com" — i.e. you have a person/identifier but no ID. Search semantics: - Case-insensitive prefix match: "sam" matches "sam" and "samantha". - Multiple words = AND: "fred tx" matches leads with both terms. - Use double quotes for an exact phrase: "\"fred smith\"".

Load the full markdown of an ActiveProspect skill — a reference playbook for a specific workflow — by name. When a tool, instruction, or another skill says "see the X skill," load `X` before that work. When a loaded skill points at a reference file (a `references/…` path), call this tool again with that path as `file` to read it. The skills: - `interpreting-accounts` — How to read an account record: billing_type vs cpl_enabled (what kind of customer), products and feature_subscriptions (what they can use), state and roles. - `caps-and-limits` — Caps (accepted-lead limits) vs ping limits, reading the live usage counters, and why only active counters return. Use to answer "what is maxed out / near its cap", how much headroom remains, or when a cap resets. - `entities` — What entities are, source/recipient roles, standard vs account vs custom (and which are editable), the module_ids constraint, renaming hazards, and deprecate-do-not-delete. Read before create_entity/update_entity or when choosing a source/recipient role. - `event-metrics` — Aggregates over events — counts, unique values, medians, funnels, and time series — and how group_by, interval, and timezone combine. Use for "how many leads last week", failure rates, drop-off, or median cost; not for individual records (see leads). - `fields-and-variables` — The variable path model behind every group_by and filter lhv/property_name: prefixes (lead/source/flow/recipient/...), the vars.-prefixed event paths vs bare flow-rule paths, step-result variables (suppressionlist.*, trustedform.*), field types and sub-properties, lead vs appended data, and listing/creating fields. Read before writing any group_by, filter path, or flow rule field. - `flow-patterns` — The canonical LeadConduit flow shape (filter → verify → suppress → certify → deliver), the decision matrix for where a rule belongs (flow acceptance criteria vs source acceptance criteria vs filter step vs recipient when-rules), per-vendor treatment inside one flow, and test-traffic exemptions. Load whenever designing, reviewing, or explaining a flow's structure or step order — including "does this flow look right", "where should this rule go", or "add a filter/step to my flow" — before assembling a create_flow or update_flow body. **Required before assembling a create_flow or update_flow body.** - `flows-workflow` — How to build, update, test, and deploy a LeadConduit flow: the lifecycle, the lookup tools that resolve names to ids, the high-level create_flow input shape (sources, filters, recipients, mappings), safe-update rules, and reading test outcomes. For flow *design* decisions — step order, where rules belong, suppression/dedup mechanics — this skill routes to flow-patterns and suppression-and-dedupe. **Required before assembling a create_flow or update_flow body.** - `leadconduit-glossary` — Definitions of the core LeadConduit domain terms and the two filter shapes (ReportRule vs KeenFilter). Read when a term in a tool description is unfamiliar, or you are unsure which tool family a request belongs to. - `leads` — Finding and reading individual lead records (search_leads, get_lead_event, list_lead_events), the lead-vs-event distinction, and which identifiers external systems can actually join on. Use when the user wants a specific person/record — "show me Bob Smith's lead" — or is reconciling CRM/vendor data against LeadConduit; not for aggregate counts (see event-metrics). - `reports-workflow` — Creating, previewing, running, updating, sharing, and deleting saved reports — read vs write tools, the columns/grouping/rules shape, and translating business asks (vendor scorecards, net leads, cost per lead) into columns. Use for reusable, named, multi-column metric definitions, vs ad-hoc counts (see event-metrics). - `rules-and-operators` — The rule operator catalog shared by flow filters and report rules, field-type compatibility, the matches-pattern glob-vs-regex trap, how a step-result (appended-data) path derives from the step entity name, and where a rule should live (acceptance criteria vs filter vs recipient when-rules). **Required before writing any rules (flow rules, filter steps, or report rules).** - `suppression-and-dedupe` — The SuppressionList lookup→filter→add pattern for DNC lists, duplicate control, and geographic (ZIP allow-list) targeting inside a LeadConduit flow: the query_item/add_item integration modules, the found-is-true vs found-is-false polarity, add-item placement, dedup exemptions, list naming and lookback conventions. Load whenever a flow needs DNC, dedup/duplicate, suppression, blocklist, territory, service-area, or ZIP/postal-code logic — or when such a step misbehaves (blocking everything or nothing). - `vertical-vocabulary` — Translating industry business language into LeadConduit metrics — funnel stages (sets, issued appointments, demos, gross/net sales), dispositions, CRM stages, cost-per-X and ROI asks — and being explicit about what LeadConduit cannot compute because it happens after delivery. Load whenever a user asks about vendor performance, conversion, cost per sale/set/appointment, ROI, close rate, dispositions, or any funnel stage past lead delivery, even if they never name a LeadConduit metric. Read references/home-services.md for the home-services glossary and CRM landscape. - `account-binding` — How each MCP variant selects an account, and how to recover from no_account_selected. - `errors` — Common tool errors and how to recover from each. - `invitations` — Inviting a partner company to connect on the network: invite_partner's inputs (seller/buyer role, email vs directory company_id), how LeadConduit mirrors an invitation as a pending source entity usable in flows, duplicate checks, and resend rules. Read before invite_partner/resend_invitation, or when a LeadConduit flow needs a source or recipient for a partner that is not connected yet. **Required before sending or resending a partner invitation.**

Get the current user's membership on the current account: who they are, their roles, and the full account record. Use this for questions about the current user or about what kind of account this is (plan, products, state).

List memberships of the current account. Returns the users on this account and their roles, each embedding the full account record; does not include API keys.

List domains owned by the current account.

List every ActiveProspect account the current user has access to, with the currently selected account flagged. Call this before `switch_account` to discover valid account ids.

Switch the current ActiveProspect account for this MCP session. Subsequent tool calls operate on the new account.

Get the current account's own network company profile, including role, verticals, lead criteria, payment details, and profile-completion status. For companies you are connected to, use `list_connected_companies`; to browse other sellers, use `list_directory_sellers`.

List the company profiles of every company connected to the current company. Returns each connected company's profile (name, role, verticals, connection status). For the connection relationship records themselves (relationship_type, permissions), use `list_connections`.

List the introductions sent and received by the current company. Returns two groups: `sent` (introductions this company made to directory sellers) and `received` (introductions other buyers sent to this company).

Send a network invitation asking a partner company to connect with this account. The network is the single system of record for invitations and connections; downstream products sync invitation state from it in the background. Invite by `email`, or by directory `company_id` (from list_directory_sellers) — exactly one of the two. Check list_connections and list_invitations first to avoid inviting an already-connected partner or duplicating a pending invite. Load the `invitations` skill with `load_skill` first.

Resend a pending network invitation email. Find the invitation with list_invitations — each carries `resend_allowed` and `resend_allowed_at`, and resending before `resend_allowed_at` is rejected. For a pending flow source entity, its `invitation_id` is the invitation to resend. Load the `invitations` skill with `load_skill` first.

List connection invitations sent by the current company. Pass `status` to filter — e.g. `["pending"]` for invites still awaiting a response. Omitting `status` returns invitations in every state.

List the current company's network connections. Each connection is the relationship record with another company — it carries the relationship_type (buyer/seller) and the permissions granted to you. For the connected companies' full profiles, use `list_connected_companies` instead.

Browse the seller directory to discover verified sellers. Returns a paginated page of seller company profiles. Requires the current account to have directory access (buyer role, contracted billing, and a product subscription); otherwise the call is rejected.

List all saved reports in the account — e.g. "show me my saved revenue-by-source report" or "what reports already exist before I create a new one."

Show the configuration of one saved report (its columns, filter rules, grouping, and share token). Accepts either a 24-char report ID or a share token.

Save a new report so it can be re-run later. A report defines which lead/event metrics to show (e.g. source-success, recipient-failure, cost, revenue), optionally grouped by source/recipient and filtered by rules. Load the `rules-and-operators` skill with `load_skill` first.

Change settings on an existing saved report (its name, columns, filters, or grouping). Only the fields you supply are changed, but each one replaces the existing value wholesale (columns/rules/group_by are not merged). Load the `rules-and-operators` skill with `load_skill` first.

Permanently delete a saved report. The report's share token (if any) stops working too.

Run a saved report over a time window and return the resulting metric rows — e.g. "show me last week's numbers for the Weekly Revenue by Source report." For an ad-hoc report you don't want to save first, use `preview_report` instead. Returns aggregate metrics only — for the actual lead records behind the numbers, use `list_lead_events`; to find a specific lead, use `search_leads`.

Run a one-off report for a time window without saving it. Use this for ad-hoc questions like "how many recipient errors did Acme Source have yesterday?" when you don't need to keep the report around. To run an already-saved report by ID or share token, use `run_report` instead. Returns aggregate metrics only — for the actual lead records, use `list_lead_events`; to find a specific lead, use `search_leads`. Load the `rules-and-operators` skill with `load_skill` first.

Generate a public share token for a saved report so the report can be viewed without an API key. Anyone with the token can run and read the report.

Revoke a saved report's share token. After this, the previous share link no longer works.

Show the column shape and grouping of a publicly shared report using only its share token (no API key needed). Use this when you have a report share link and want to know what metrics it exposes before running it.

Search LeadConduit flows in the account. Use this before creating a similarly named flow or before deploying an existing flow. Pass a query (a flow name fragment) to narrow accounts with many flows.

Get one LeadConduit flow by id, including sources, filters, recipient steps, fields, and deployment-relevant configuration. Each recipient step is annotated with appended_data_prefix and appended_data_paths — the exact variable paths a later filter rule may reference for that step's results (the namespace derives from the step's entity name; it cannot be guessed from the integration).

Search LeadConduit entities that can be used as flow sources or recipients. Use this to resolve a human-readable company name before calling create_flow. Pass a query (a company name fragment) to narrow large accounts instead of fetching every entity.

Get one LeadConduit entity by id, including its name, source/recipient roles, supported integration modules, and description. Resolve a name to an id with list_entities first.

Search LeadConduit integration modules that can be used by create_flow. Use inbound modules for sources and outbound modules for recipient delivery steps. Pass a query (e.g. "salesforce", "json") and/or direction to narrow the large catalog. The heavy request/response variable schemas are omitted unless include_variables is set.

List LeadConduit credentials used to authenticate integrations. Use this to resolve a credential name before referencing it from a source or recipient in create_flow. Secret values (token, password) are never returned. Credentials cannot be created through these tools — if the one a flow needs does not exist, the user must add it manually in the LeadConduit app first; never accept or pass a raw secret.

Search delivery destinations configured for the account in the LeadConduit app (Prismatic integration instances). These are pre-built outbound endpoints that follow a "configure once, reuse across flows" model and can each expose multiple actions (e.g. "Create Lead", "Update Contact"); add them to a flow as recipient steps. Destinations cannot be created or modified via the API — only listed and added to flows. Returns an empty list when none are configured. For the raw integration module catalog used to build a recipient from scratch, use list_integrations instead.

Create a source or recipient entity (a vendor, form, lead buyer, or CRM) in the account so it can be referenced by create_flow. create_flow only accepts entities that already exist, so call this first when the company the user named is not found by list_entities. Search list_entities first to avoid creating a duplicate — entity names must be unique within the account.

Update an existing CUSTOM LeadConduit entity. This is a merge-patch: it fetches the entity, applies only the fields you pass, and leaves everything else unchanged. Only custom (account-created) entities can be edited — standard and account entities are read-only and will fail. To retire an entity, set deprecated: true instead of deleting it (there is no delete tool). Resolve the entity id with list_entities first. To create a new entity use create_entity.

Create and save a new LeadConduit flow from high-level source, filter, and recipient intent. Sources and recipients are both optional: omitted sources default to the account's own entity with the standard inbound posting integration, and a flow saved without recipients accepts leads but delivers them nowhere until recipients are added. A source or recipient may also be named by a network connection id (from list_connections) or connected company name — it resolves to the partner's account entity, and saving the flow links that entity to the account with no UI step. This does not make the flow live; call deploy_flow with the returned id when the user wants the saved configuration deployed. Load the `flow-patterns`, `flows-workflow`, and `rules-and-operators` skills with `load_skill` first.

Update an existing LeadConduit flow by replacing its saved configuration with a full flow body. Required workflow: call get_flow first, transform the returned flow, then pass the full updated body here. A source/recipient entity id may be a network connection id (from list_connections) — it resolves to the partner's account entity automatically. Load the `flow-patterns`, `flows-workflow`, and `rules-and-operators` skills with `load_skill` first.

Remove exactly one step from an existing LeadConduit flow. Use for requests like "remove this recipient/filter step from my X flow."

Remove matching rule checks from one LeadConduit flow. Use for requests like "remove the state check from my X flow"; prefer remove_flow_step when the user wants an entire step removed. Load the `rules-and-operators` skill with `load_skill` first.

Deploy a saved LeadConduit flow so its latest configuration is live for lead handling. Use after create_flow when the user explicitly wants the saved flow to start processing leads.

Test one recipient step in a LeadConduit flow with supplied submission data. This runs LeadConduit step-test handling and can create test events.

Submit a test lead to a LeadConduit flow source and optionally verify the recorded events. This can exercise deployed recipient deliveries.

Verify a recently submitted LeadConduit test lead by querying recorded events. Use after submit_test_lead, or when the user gives a reference/email/phone for a test lead.

Search LeadConduit fields (standard and custom) that flows, rules, and mappings can reference. Use it to resolve a field id, name, or data type before referencing one in create_flow or a report rule. To add a custom field that does not exist yet, use create_field.

Create a CUSTOM LeadConduit field so flows, rules, and mappings can reference it. Prefer a standard field first: search list_fields and only create a custom field when nothing fits, since standard fields are normalized and map automatically across accounts while custom fields raise setup/maintenance cost. create_flow rejects a field id that does not exist, so call this once you have confirmed no standard field matches. Standard fields are built in and cannot be created. The field id is derived from the name plus the account field suffix, so it may differ from a bare slug of the name.

List active LeadConduit cap counters with their current usage. A cap limits how many successful leads a flow accepts over a time window. Only caps that received lead traffic in the current interval are returned. Use it to answer "which caps are maxed out or close to their limit?". For ping (pre-bid) limits use list_ping_limits.

List active LeadConduit ping-limit counters with their current usage. A ping limit caps how many pings (pre-bid requests) a flow or source accepts over a time window. Only ping limits that received ping traffic in the current interval are returned. For accepted-lead caps use list_caps.

List LeadConduit changelogs — the audit trail of create/update/delete changes made to flows, entities, fields, and reports. Each entry summarizes who changed what and when. Pass resource_type and resource_id together to scope to one flow, entity, or field; omit both for the account-wide trail. For the full change detail and revision delta of one entry, use get_changelog.

Get one LeadConduit changelog by ID, including its full normalized change list and the raw delta from the previous revision. Use it to answer "what exactly changed and who did it?" after finding the entry with list_changelogs.

Count how many lead events happened in a time window — e.g. "how many leads were submitted last week," "how many recipient calls failed yesterday." Optionally bucket by day/hour and break down by source, recipient, outcome, or any other lead field. Pick this over `get_lead_stats` for time-series ("show me daily counts") or arbitrary Keen-style filters. Returns counts only — for the actual lead records use `list_lead_events`; to find a specific lead by name/email/phone use `search_leads`.

Count how many distinct values appeared for a lead/event field — e.g. "how many unique sources sent us leads," "how many unique phone numbers we received this month," "how many distinct buyers we delivered to." Returns a number, not the values themselves — use `list_unique_lead_values` to see the actual values, or `list_lead_events` for the underlying lead records.

List the actual distinct values that appeared for a lead/event field over a time window — e.g. "which sources sent leads last week," "which buyer destinations got calls today," "every unique zip code we received this month." This is also the DISCOVERY tool: when you need to filter by a specific source.id / recipient.id / state / etc. but don't yet know what values exist, call this with the field as `target_property` to enumerate them, then plug a value into `list_lead_events.rules` or another tool.

Measure drop-off through a multi-step lead pipeline: of the leads that hit step 1, how many made it to step 2, then step 3, etc. Use this for funnel analysis like "submitted → accepted by source → delivered to buyer → converted." Returns funnel counts only — for the actual lead records that progressed (or didn't) use `list_lead_events` with appropriate rules.

Get the median (typical) value of a numeric lead/event property over a time window — e.g. median cost per lead, median revenue per lead, median processing latency — optionally broken down by source, recipient, or module. Returns one median per group, not lead records — for individual leads use `list_lead_events`.

Get tabular lead and event counts grouped by source, recipient, outcome, or any lead field, with optional time bucketing and computed metrics like cost, revenue, profit, and success rates. This is the data that powers saved reports — pick this over `count_lead_events` when you want a spreadsheet-shaped result with the same metric columns reports use. Returns aggregate counts/rates only, not lead records — for the actual leads in the window use `list_lead_events`; to find a specific lead use `search_leads`.

List lead events (one event per flow step, with the lead snapshot embedded). This is the standard "show me the leads" call — returns the actual lead records (collected fields, appended data, outcomes) for the time window. With the default type=["source"] you get ONE event per lead — the canonical post-processing snapshot — i.e. the natural "list me leads in this window" call. Drop or change type to drill into per-step events ("recipient" for delivery events, "filter" for filter steps, etc.). Pagination is cursor-based via after_id / before_id; do not use page numbers. Each event can be large (full lead + appended data), so prefer small limits or use include/exclude to trim fields.

Fetch a single lead event by its 24-char hex ID. Returns the full event including the lead snapshot — every field collected at submission plus everything appended by prior flow steps. Use this when `list_lead_events` or `search_leads` gives you an event ID and you want the full record. Note: a single event can be large; prefer it for one-record drill-ins, not bulk fetching.

Full-text search across leads. Indexed fields: first_name, last_name, email, phone_1, phone_2, address_1, city, state, postal_code, reference. Returns { hits, total } where each hit has a lead_id, a latest_event_id you can pass to get_lead_event for the full record, and highlighted matched terms. Use this when the user asks something like "find the lead from Bob Smith" or "what was that lead with email foo@bar.com" — i.e. you have a person/identifier but no ID. Search semantics: - Case-insensitive prefix match: "sam" matches "sam" and "samantha". - Multiple words = AND: "fred tx" matches leads with both terms. - Use double quotes for an exact phrase: "\"fred smith\"".