MCP Tools

The OnFire MCP server publishes a tenant-scoped tool surface — every call is scoped to the tenant behind your OAuth session. These pages cover the 31 tools the published connector serves, in a handful of natural groups.

Query and schema

The core surface. One structured query engine, plus the three tools that tell an agent how to drive it.

• ask_onfire — the single structured-query surface over the data lake: people, companies, job posts, events, GitHub activity, headcount, and more.
• resolve_insights — look up the curated persona / technology vocabulary to use in ask_onfire insight filters. Optional.
• describe_onfire_schema — the queryable entities and their exact fields, filterability, and joins.
• load_onfire_guide — the long-form playbooks for each tool family.

Prospecting

• ai_prospecting — rank the likely buyers and champions at a target account.
• ai_prospecting_field_glossary — the self-describing contract for every field a run can return.

Identity resolution

• match_company — resolve a company to a verified LinkedIn URL plus firmographics.
• match_person — resolve a person to a verified LinkedIn profile plus current role.

Enrichment

Both are paid and enforce a two-phase consent flow above 10 records.

• contact_data_enrichment — append verified emails and phones to contact records.
• search_contact_by_email — identify the person and company behind an email address.

Account research

• account_research — the full account brief (config, 10-K, footprint, intent, scored prospects) in one call.
• query_company_filings — section-extract a company’s most recent 10-K.
• detect_warm_intros — alumni and shared-colleague paths into an account or a list of people.

Datasets

• list_datasets — the tenant’s active datasets.
• describe_dataset — schema, row count, and a head sample.
• query_datasets — read-only DuckDB SQL over one or more datasets.
• download_dataset — mint a clickable CSV download URL.

CRM and sales engagement

Live systems of record. The write tools are deny-by-default and must be granted to your tenant explicitly.

• crm_read — read from the connected CRM.
• crm_write — submit accounts or prospects to the async export pipeline.
• crm_write_status — poll an export job.
• crm_write_results — per-record outcomes as a dataset.
• sales_engagement_read — read from the connected sales engagement platform.
• sales_engagement_write — create and update SEP records.

Workflows

Design, save and run OnFire automations — a trigger, then steps that each take the rows the step before produced. These are the write side of the surface: building and live-running a workflow changes systems of record, so new workflows and live runs both gate on explicit user confirmation. Start every build at get_workflow_blocks and read load_onfire_guide("workflows").

• get_workflow_blocks — the blocks a workflow is built from, and their full detail.
• get_workflow_options — the valid values a block’s setting or input can take.
• build_workflow — assemble and validate the steps, with a dry-run preview. Nothing is saved.
• save_workflow — save the steps as a draft (or a new version). New workflows need the user’s yes.
• run_workflow — run a saved workflow (a dry run by default) and read what it did.
• manage_workflows — list, inspect, edit, pause or archive saved workflows.

Tenant and session

• get_tenant_settings — the tenant’s safe-to-share settings, including the CRM / SEP block.
• get_current_tenant — which tenant this session resolved to.

Cross-cutting conventions

Every tool inherits a few rules worth knowing once.

Tenant scoping. The tenant comes from your OAuth session. Super-tenant administrators can target another tenant via target_tenant_id on the tools that accept it; everyone else is blocked server-side.

Per-tenant tool allowlists. The tool list your client sees is the authoritative set for your tenant. The write paths (crm_write, sales_engagement_write) are deny-by-default and must be granted, so a tool named here may not be enabled for you. The server’s own instructions, tool descriptions and guides are filtered to your tenant, so what your agent reads never points at a tool it cannot call.

Datasets, not walls of rows. Tools that can return large results write the full result to a short-lived dataset (CSV in S3, 7-day TTL, up to 100,000 rows) and return a compact envelope with a handle plus preview_rows and facets. Slice it with the dataset tools.

Sizing before pulling. Result-volume tools count first and pull second. ask_onfire with no limit returns the match count for free; above 50 rows it needs confirmed=true (hard ceiling 1,000). detect_warm_intros returns needs_confirmation above 50 rows. query_datasets caps inline output at 500 rows, and SQL responses carry truncated plus total_count when a cap is hit.

Credits. Most data tools draw on your tenant’s credit balance — typically per row returned, and per call for the point lookups. Sizing a result (a count, a needs_confirmation response) is free, and a call that would exceed your balance fails closed rather than returning partial data. contact_data_enrichment and search_contact_by_email bill per enriched contact and per successful match respectively, and each enforces an explicit consent step before a large run. An address search_contact_by_email declines to look up — a personal mailbox — is not charged for.

Restricted and internal tools

The server also registers a small set of cross-tenant administrative integration proxies reserved for OnFire staff tenants. They are deny-by-default, never listed for customer tenants, and are not documented here. Customer tenants reach their own systems of record through crm_read, crm_write, sales_engagement_read, and sales_engagement_write.