Skip to main content
Glama
gray-wilbee

fub-mcp

by gray-wilbee
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

list_people

Search Follow Up Boss CRM for people by name, email, phone, tags, stage, or custom fields. Retrieve paginated results with selective fields for efficient contact lookup.

Instructions

Search for people. (GET /people) Defaults to limit=100 (FUB's max per page) rather than its own default of 10 — bulk requests are the common case here. If the response's _metadata shows more results remain, keep paginating: use offset for offset-based endpoints, or the _metadata.next cursor value (as the next argument) for cursor-based endpoints like notes. Use fields to request only what you need instead of full records when scanning many people. For custom fields, call list_custom_fields first to discover the exact field names/labels rather than guessing. 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 extraQuery instead. Call list_custom_fields first to get exact names.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
idNoThe ID(s) of a person or people. (e.g., "123,456")
nameNoSearch for person with a name like what is given. (e.g., If you search for "drew", it might return a contact like "Andrew".)
sortNoThe sort order, can be one of the following: `id`, `created`, `updated`, `name`, `firstName`, `lastName`, `price`, `stage`, `lastActivity`, `lastCommunication`, `lastReceivedEmail`, `lastSentEmail`, `lastEmail`, `emailsReceived`, `emailsSent`, `lastIncomingCall`, `lastOutgoingCall`, `lastCall`, `firstCall`, `callsIncoming`, `callsOutgoing`, `callsDuration`, `lastReceivedText`, `lastSentText`, `lastText`, `lastLeadActivity`, `lastEmEventActivity`, `lastIdxVisit`, `textsReceived`, `textsSent`, `propertiesViewed`, `propertiesSaved`, `pagesViewed` or `nextTask`. <br /><br />Custom Fields (e.g. `customClosePrice`) can also be used in sorting.created
tagsNoSearch for people that match one or more tags. (e.g., "Foo,Bar" will match contacts with tags that include Foo OR Bar.)
emailNoSearch for a person by email address.
limitNoNumber of results to return. Max 100.
phoneNoSearch for a person by phone number.
stageNoSearch for person by stage name. (e.g., "Lead" or "Trash". See [stages API endpoint](ref:stages-get) for available stages.)
fieldsNoComma separated list of fields to return or use `allFields` to return all fields. (e.g., `firstName,lastName,timeframeId,timeframeUpdated,timeframeStatus,customFieldName`). Note: All custom fields should be prefixed with `custom` (i.e. customBirthday, customField). <br><br> Special values include `allCustom` (returns all custom fields) and `allFields` (returns all fields, including custom fields). <br><br> When using the `fields` parameter to filter the response, the `id` field will be included (even when not specified explicitly).
offsetNoSpecifies the number of rows to skip, before starting to return results.
sourceNoSearch for a person by lead source.
lastNameNoSearch for person with a last name like what is given. (e.g., If you search for "drew", it might return a contact like "Andrew".)
contactedNoSearch for people by whether or not they have been contacted.
firstNameNoSearch for person with a first name like what is given. (e.g., If you search for "drew", it might return a contact like "Andrew".)
assignedToNoSearch for a person by the user that is assigned to them. (e.g., Passing "William Riker" would return any person assigned to them.)
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.
priceAboveNoSearch for people who have specified a price above a given value.
priceBelowNoSearch for people who have specified a price below a given value.
smartListIdNoSearch for people that match a smart list with given ID.
includeTrashNoSet whether to include people in the "trash" stage. (By default responses from /people will not include any people with a "trash" stage.)
assignedPondIdNoSearch for a person by the assigned pond id.
assignedUserIdNoSearch for people by the assigned user ID.
assignedLenderIdNoSearch for people by the assigned lender user ID.
includeUnclaimedNoSet to include unclaimed leads offered to the current user.
lastActivityAfterNoSearch for last activity after a given time. (e.g., "2016-11-23 01:02:03")
assignedLenderNameNoSearch for people by the assigned lender name.
lastActivityBeforeNoSearch for last activity before a given time. (e.g., "2016-11-23 01:02:03")

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 provided, the description carries the full burden of behavioral disclosure. It reveals non-obvious behavior: the default limit is intentionally overridden to 100, pagination must follow `_metadata`, and custom fields require special handling via `extraQuery` rather than literal field names. It does not cover auth or rate limits, but for a read-only GET search, the key operational quirks are disclosed.

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 appropriately front-loaded with purpose and endpoint, and every sentence earns its place around defaults, pagination, and custom fields. It is dense at nearly 190 words and could be bulleted for readability, but there is no filler or tautology.

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 27 optional parameters, no annotations, and no output schema, the description supplies the essential operational context: default pagination behavior, result-count handling via `_metadata`, field minimization, and the custom-field discovery workflow. It does not describe the response shape beyond `_metadata`, but the most confusing aspects of this endpoint are covered.

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 description coverage is 100%, so the baseline is 3. The description adds real value beyond the schema by explaining the `limit` default override, advising on `fields` usage, and clarifying that custom fields must be passed through `extraQuery`. These insights meaningfully deepen parameter understanding without repeating schema text.

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 verb and resource — "Search for people. (GET /people)" — which unambiguously identifies the tool's purpose. The plural 'people' plus the search verb clearly distinguishes it from siblings like get_person or update_person, and the endpoint is stated explicitly.

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 strong context: it states that bulk requests are the common case, explains the default limit override, gives a concrete pagination procedure, and tells the agent to use `fields` to minimize payloads. It also explicitly points to list_custom_fields as a prerequisite for custom-field queries. However, it does not explicitly name alternatives like get_person for single-record lookups.

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