Skip to main content
Glama
gray-wilbee

fub-mcp

by gray-wilbee

update_person

Update an existing person's details in Follow Up Boss CRM by ID, including tags, contact info, stage, and assigned agents, with support for custom fields.

Instructions

Update a person by id. (PUT /people/{id}) FUB's docs also list a wildcard "custom*" field here for reading/writing custom fields directly (e.g. a "Closing Date" field as custom.ClosingDate) — that's not a literal field name, so it's not in this tool's fixed schema. Pass custom. entries via extraBody instead. Call list_custom_fields first to get exact names. Tag removal has no dedicated endpoint: to remove a tag, first GET this person, filter the tag out of their current tags array yourself, then PUT the full filtered array back (with mergeTags left at its default of false so it replaces rather than merges). To add tags, just pass the new tags with mergeTags=true (this tool's default) so they're unioned with the person's existing tags. ⚠️ DATA LOSS RISK, confirmed against the live API: emails, phones, and addresses are REPLACED wholesale if you include them — there is no merge flag for these like there is for tags. Sending a single new phone number wipes out every other phone number the person had. To add one without losing the rest, GET the person first, append to their existing emails/phones/addresses array yourself, and PUT the complete merged array back. Never send a partial list unless the user explicitly wants everything else removed. collaborators is also settable here even though FUB's own docs don't list it on this endpoint (confirmed working in practice) — it has the same replace-not-merge behavior as tags/phones: omitting an existing collaborator's user id removes them, so GET the person first and merge if you only want to add one. Pass it via extraBody. Setting stage to "Trash" hides the person from default list views (FUB excludes trashed people from GET /people unless includeTrash is set) — it's reversible, but feels like the contact vanished to someone who isn't expecting it, so this requires confirm=true just like a delete, even though it isn't one.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
tagsNoA list of tags applied to the person. **This list will overwrite any existing tags for the person.** (To merge the tags passed with any existing tags,set the `mergeTags` query parameter in your request to true.)
priceNoThe price of the property of the person's first inquiry, or the estimated sell/buy price for this person.
stageNoThe stage the person is in. (e.g., "Lead" or "Trash". See [stage API endpoint](ref:stages-get) for more options.)Lead
emailsNoA list of email addresses associated with the person.
phonesNoA list of phone numbers associated with the person.
confirmNoOnly needed if `stage` is being set to "Trash" — must be true in that case, confirmed with the user first (it hides the contact from default views). Not needed for any other update.
lastNameNoThe last/family name of the person.
addressesNoA list of addresses associated with the person. (This is the address where this person can be contacted, it is not the address of a property this person may be interested in selling or buying).
contactedNoWhether the person has been contacted. (**Note**: Changing the `contacted` field to `true` will pause action plans.)
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.
firstNameNoThe first/given name of the person.
mergeTagsNoIf set to true, this will merge the tags sent in the `tags` argument with the current list of tags. By default, it overwrites the existing tags.
assignedToNoFull name of the agent assigned to this person.
backgroundNoBackground information on the person. (Can be a multi-line string.)
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.
timeframeIdNoID of the timeframe to move (Refer to the /timeframes endpoint for valid values of timeframeId.)
assignedPondIdNoID of the pond assigned to this person.
assignedUserIdNoID of the agent assigned to this person.
assignedLenderIdNoID of the lender assigned to this person.
assignedLenderNameNoFull name of the lender assigned to this person.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full burden, and it is unusually transparent: it warns about wholesale replacement of emails/phones/addresses, explains collaborator replace-not-merge behavior, and discloses that Trash hides the person from default list views. The main flaw is that mergeTags is described both as having a 'default of false' and as defaulting to true, which undermines the operational clarity.

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 description is long, but the tool has 21 parameters, nested objects, and severe data-loss risks, so most sentences earn their place. The warning-heavy structure and upfront 'Update a person by id' help orientation, though the repeated and contradictory mergeTags guidance could have been tightened.

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?

Given no annotations, a complex mutation endpoint, and high-stakes replace semantics, the description covers remarkably well: custom field handling, tag removal, partial-array danger, collaborator behavior, and Trash confirmation. The absence of an output schema is mitigated by the rich operational context; the internal mergeTags default discrepancy keeps it from being fully 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 95%, so the schema already handles most parameter documentation; the description adds genuinely useful beyond-schema meaning: custom.* fields belong in extraBody, collaborators are passed via extraBody, confirm is only needed for Trash, and emails/phones/addresses replace rather than merge. The value is reduced by the contradictory default statements about mergeTags, but it still meaningfully exceeds the baseline.

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 'Update a person by id' and names the endpoint PUT /people/{id}, giving a specific verb, resource, and identifier. This clearly distinguishes the tool from create_person, get_person, and list_people, and its scope is unambiguous.

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

Usage Guidelines4/5

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

The description provides concrete guidance: call list_custom_fields first, GET the person before tag removal or before merging emails/phones/addresses/collaborators, and require confirm=true when setting stage to Trash. It does not explicitly contrast with create/get tools, but it gives enough context that an agent can tell when update_person is the right call.

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