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

With readOnlyHint already declaring the safe-read profile, the description adds real value: it discloses that include_importable triggers an outbound call to Follow Up Boss, and that the returned settings/field mapping/routing/CRM user shapes mirror what update_integration accepts. It does not cover pagination or list-size limits, so it falls short of a full 5.

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?

Two dense sentences, front-loaded with the list/read duality before the optional importable mode and the sibling routing. Every clause carries distinct information with no filler.

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?

With no output schema present, the description compensates by naming the list fields and pointing at update_integration as the shape contract for single-integration reads. It also covers the enum parameter's purpose, so an agent has everything needed to call it correctly.

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 description coverage is 100%, so both parameters are already fully documented in structured form; the description largely restates the omit-vs-supply behavior of integration_id. Its only marginal addition for include_importable is the Follow Up Boss backend call, which is more behavioral than semantic, so the baseline 3 applies.

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 a specific verb and resource ('List the account's connected integrations') and enumerates the returned fields (platform, name, status, primary CRM), then clarifies the alternate read mode when integration_id is supplied. It explicitly distinguishes itself from the sibling get_crm_options by naming it and the condition that selects it.

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?

Gives explicit branching instructions: omit integration_id to list all, pass it to read one integration's configuration, use include_importable for Follow Up Boss users/groups. It also names the alternative tool (get_crm_options) and the condition under which that one is correct, leaving nothing to inference.

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