List all team inboxes from Follow Up Boss to view and manage shared email accounts.
Get a list of Team Inboxes (GET /teamInboxes)
| Name | Required | Description | Default |
|---|---|---|---|
| extraQuery | No | Extra 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. |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It doesn't mention whether this is a read-only operation (it says GET, but that's not enough), whether it requires authentication, what fields are returned, or if there are any side effects. The description is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Single sentence, no fluff. But it could be improved by front-loading the purpose more clearly and adding a note about the optional parameter. It's concise but under-specified.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has only one optional parameter and no output schema, the description is too thin. It doesn't explain what data the response contains, any filtering options besides extraQuery, or typical usage scenarios. Incomplete for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one optional parameter described clearly. The description doesn't add much beyond the schema, but since the schema is complete, baseline 3 is appropriate. It doesn't give examples of valid extraQuery values.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States it gets a list of Team Inboxes, but 'Team Inboxes' is a vague resource name. It doesn't define what a Team Inbox is or what data it returns. Could be confused with similar list tools like list_groups or list_teams, but the resource name is specific enough.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance on when to use this tool versus siblings like list_groups or list_teams. It just says 'Get a list of Team Inboxes', with no context on typical use cases or criteria for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.