Skip to main content
Glama
gray-wilbee

fub-mcp

by gray-wilbee
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

list_events

Search and retrieve all Follow Up Boss events matching filters like type, person, or property, with automatic pagination to fetch every result.

Instructions

Search for events. (GET /events) 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.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nextNoTo get the next page of results, set this to the value returned in _metadata.next, or use the URL from _metadata.nextLink directly.
typeNoComma separated list of one or more of the following: "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".
limitNoNumber of results to return. (Max 100.)
offsetNoSpecifies the number of rows to skip, before starting to return results. (For more efficient paging, please use the "next" parameter instead.)
personIdNoFind all events related to a person.
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.
hasPropertyNoFilters based on whether a property is associated with an event or not.
propertyAddressNoSearches property addresses for a given value, including partial matches.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the burden of behavior disclosure, and it does well by explaining the limit default deviation, max page size, and how to continue pagination via _metadata, offset, or next. It does not cover auth, rate limits, or response shape, but for a read-only GET tool the most important behavioral traits 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.

Conciseness5/5

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

Three focused sentences with no filler: the purpose is front-loaded, followed by the most operationally important detail (default limit) and pagination instructions. Every sentence earns its place.

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

Completeness3/5

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

The description covers the key operational concern—paginating through large result sets—and the schema fully documents parameters. However, there is no output schema and no description of the event object itself, ordering, or response format, which leaves a meaningful gap for an agent consuming the results.

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

Parameters3/5

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

Schema description coverage is 100%, so the parameters are already well documented. The description adds some value by explaining how next and offset relate to pagination, but it does not meaningfully expand on the schema's parameter-level semantics.

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

Purpose4/5

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

The description clearly states the resource ('events') and the operation ('Search'), reinforced by the explicit 'GET /events' endpoint. It does not explicitly differentiate from siblings like get_event or list_em_events, so it misses the top score.

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

Usage Guidelines3/5

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

The note that 'bulk requests are the common case here' implies this tool is best for bulk event retrieval, but it does not explicitly state when to choose it over get_event or other list tools. Pagination guidance is provided, but no exclusions or alternative-selection rules are given.

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