Skip to main content
Glama
gray-wilbee

fub-mcp

by gray-wilbee

create_event

Register a new lead or record a lead event in Follow Up Boss to trigger lead routing, automations, and per-source workflows.

Instructions

Send in a lead or an event related to a lead. (POST /events) Use this — not create_person — when a NEW LEAD needs to be registered and should trigger FUB's lead routing, automations, and per-source workflows. create_person only inserts a bare contact record and triggers none of that; this is the actual lead-ingestion event. Set type to one of Registration, Inquiry, Seller Inquiry, Property Inquiry, General Inquiry, Viewed Property, Saved Property, Visited Website, Incoming Call, Unsubscribed, Property Search, Saved Property Search, Visited Open House, or Viewed PageRegistration for a genuinely new lead. Set source (and system if relevant) since lead routing rules commonly key off source. FUB auto-deduplicates the nested person object by phone/email — no separate deduplicate flag needed here, unlike create_person. ⚠️ If occurredAt is set to more than 1 day in the past, FUB treats the event as historical and will NOT trigger routing/automations at all — leave it unset (defaults to now) or within the last day if the point is to actually trigger workflows; only backdate it deliberately for importing historical data where you specifically don't want anything to fire.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
typeNoThe type of event. Currently one of `Registration`, `Inquiry`, `Seller Inquiry`, `Property Inquiry`, `General Inquiry`, `Viewed Property`, `Saved Property`, `Visited Website`, `Incoming Call`, `Unsubscribed`, `Property Search`, `Saved Property Search`, `Visited Open House` or `Viewed Page`.
personNoInformation about the lead who triggered this event. Follow Up Boss will automatically de-duplicate people based on their phone number or email address.
sourceNoThe name of the lead source.
systemNoThe name of the system used in providing leads.
messageNoA message from the user about this inquiry.
pageUrlNoThis field is to be used with the `Viewed Page` event type and indicates the url of the page viewed. (e.g., "http://www.samplerealestate.com/contact-us")
campaignNoThe name of the source where the lead originated. (e.g., If the lead came to your site through an organic search on `www.google.com` the source is "Google".)
propertyNoInformation about the property this event is related to.
extraBodyNoExtra raw JSON body fields not explicitly listed above — e.g. custom.* fields when creating/updating people or deals. Keys and values are sent as-is.
pageTitleNoThis field is to be used with the `Viewed Page` event type and indicates the title of the page viewed. (e.g., "Contact Us")
extraQueryNoExtra raw query parameters not explicitly listed above — e.g. FUB custom field filters like custom.ClosingDate on /people or /deals. Keys and values are sent as-is.
occurredAtNoThe date this event occurred. This is used to determine if the event is historical. Historical events will not trigger workflows upon creation. Any DateTime greater than 1 day will be considered historical.
descriptionNoAny additional information about this inquiry.
pageDurationNoThis field is to be used with the `Viewed Page` event type and indicates the duration of the visitor on the page viewed given in seconds.
pageReferrerNoThis field is to be used with the `Viewed Page` event type and indicates the referrer url where the visitor came from. (e.g., "https://www.google.com") (Note: If `pageReferrer` is sent in, `pageUrl` should be set as well.)
propertySearchNoIf this event was an inquiry you may have information about what the person was searching for, you can submit this information using this field.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full behavioral burden and does so well: it discloses that FUB auto-deduplicates the nested person object, that occurredAt older than 1 day is treated as historical and will NOT trigger routing/automations, and that leaving it unset defaults to now. This goes far beyond what any structured field would reveal.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The key distinction and usage rule are front-loaded, and the length is justified by the volume of critical behavior. It is somewhat long and includes repeated emphasis, so not a 5, but every major sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex 16-parameter tool with nested objects and no output schema or annotations, the description covers the main behavioral pitfalls (dedupe, routing, historical cutoff, source importance). It does not describe return values, but with no output schema expected and the call-side behavior well covered, it is nearly complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds meaningful selection guidance: type values with 'Registration for a genuinely new lead,' source/system being key for routing, and the critical occurredAt threshold. It doesn't walk through every parameter, but the most decision-critical ones get extra semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific action ('Send in a lead or an event related to a lead') and explicitly contrasts itself with create_person, stating this is the actual lead-ingestion event that triggers FUB's routing, automations, and per-source workflows. An agent can immediately distinguish it from create_person and the many create_* siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives an explicit when-to-use rule ('Use this — not create_person — when a NEW LEAD needs to be registered') and explains why create_person is insufficient. It also warns against backdating occurredAt unless deliberately importing historical data, giving clear do/don't scenarios.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools