> ## Documentation Index
> Fetch the complete documentation index at: https://heybtw.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# The heyBTW MCP rules

> Ten rules every heyBTW tool follows and every agent using heyBTW should follow too.

These rules hold on every tool, prompt and guide. They are what makes heyBTW's answers safe to act on. Agents: follow them as written. People: this is what you can expect Claude to say, and why.

## 1. Registered and attended are separate

Approved, pending and going are **registered**. Only a check-in (`CHECKED_IN`) is **attended**. Never mark a whole guest list attended, never report sign-ups as attendance, and never thank someone for attending on an RSVP alone.

## 2. Null is unknown, never zero

A missing value is `null` with a named gap. Report it as unknown. A fact with no source is a gap, not a zero, an empty list or a guess.

## 3. Facts, not scores

heyBTW serves facts with a basis. It returns no score, tier, rank, weight or priority. Where rows have an order, the response names the rule (`metadata.ordering`), and position means that rule and nothing more. The user and the workflow decide what matters.

## 4. CRM data stays in the CRM

heyBTW stores references and join keys, never deal stage, owner or amount copied from the user's own connector. There are two routes to a CRM:

1. **The user's own CRM connector in their client.** It answers owner, deal and activity questions, joined to heyBTW on `email` and `company_domain`. It needs no setup in heyBTW.
2. **A CRM connected inside heyBTW.** It lets heyBTW compute pipeline attribution and follow-up status itself.

`crm_context` on every CRM-dependent response says which route applies. If heyBTW returns a gap because no CRM is connected inside it, say so. Never substitute a number of your own under heyBTW's name.

## 5. heyBTW never sends, with two named exceptions

Through MCP, heyBTW never sends a message and never writes to a customer system. It sends only two things, each described by its tool and confirmed by the user first: a **Luma invite send** ([`activate_list`](https://heybtw.com/docs/tools/activate-list)) and a **collab co-host invitation email** ([`manage_collab_partners`](https://heybtw.com/docs/tools/manage-collab-partners)). heyBTW never adds guests to an event platform's guest list. Every other send goes through the user's own mail, Slack or CRM connector.

## 6. The event-history ladder

An event's history reaches heyBTW one of three ways, best first:

| Rung | Route | Brings |
| - | - | - |
| 1 | API sync (Luma, Splash, Zuddl, connected in the dashboard) | Events, guest lists, check-ins and registration answers, kept current |
| 2 | Event page link ([`create_collab`](https://heybtw.com/docs/tools/create-collab)) | The event only |
| 3 | Guest export ([`record_signups`](https://heybtw.com/docs/tools/record-signups), [`create_import_link`](https://heybtw.com/docs/tools/create-import-link)) | A snapshot of the list at that moment |

Every import names what it did not bring in `import_gaps` (partners, attendance, registration answers), each with the tool that fills it.

## 7. Nothing is attributed before the event day

An event that has not happened has no attributed pipeline. The open pipeline of the accounts registered for it is served under its own name, `registered_account_pipeline`, and is never reported as sourced, influenced or won.

## 8. A person's location never comes from their company

Location is the person's own city, with its source (`imported_declared`, registration, enrichment, event-derived). A company headquarters is never a person's location, and an event city is where someone attended, not where they live. Distance is a band, never miles.

## 9. Per-person invite records only for targeted sends

A targeted invite is recorded per person, so heyBTW can say who was invited and what came of it. A mass send is recorded as a count. [`activate_list`](https://heybtw.com/docs/tools/activate-list) defaults to per-person records up to 2,500 recipients and a count above that (`invite_log`).

## 10. Relay what heyBTW says as written

When a coverage note says "tell the user ... as written", relay that sentence word for word. Read clock values (`event_tense`, `days_until`, `event_window`, pace) as served; never compute them yourself. End a workflow with the counts, then what could not be carried: unmatched people, refused tools, declined asks.

## Connector routing in one line

heyBTW holds the record (who registered and attended, who brought them, partner overlap, Lists, observations, tasks). The user's own connectors act (CRM lookups and writes, mail and Slack sends, calendar holds). A tool whose next step lives outside heyBTW says so in a `carry` block or a "Carry to:" line, naming the destination and the join key.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.