follow-up-boss

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

Annotations provide only destructiveHint=true and a title, so the description carries most of the burden. It hints that the note becomes visible on the contact's timeline and cites the raw endpoint 'POST /v1/notes', but says nothing about permissions, whether the note is editable/deletable, rate limits, or what the response looks like for a mutation tool.

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 short sentences with the purpose front-loaded; the API endpoint reference is developer-facing filler but costs little space. Nothing is buried or padded.

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?

For a simple 4-parameter append tool with no output schema, the description covers the core action adequately. However, with annotations limited to destructiveHint, it leaves unanswered how the note interacts with the contact record and when to choose this over sibling timeline tools.

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% (body, isHtml, subject, personId all documented), so the baseline is 3. The description adds no format, length, or HTML-escaping guidance beyond what the schema already states.

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 ('Add a note to a contact's timeline'), which is distinct from the many creation/list siblings like fub_create_task and fub_log_call. It does not explicitly name an alternative, but the resource is unambiguous enough that an agent can tell what it does without opening the schema.

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?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as fub_log_call or fub_send_lead_event for other timeline entries. Usage is only implied by the tool name and the word 'timeline'.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds genuinely non-obvious behavior: the search spans the whole account including records this user cannot see, and the response includes assignment. It doesn't state what happens when nothing matches, a minor gap.

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?

Three tight sentences, front-loaded with the core behavior, then the usage cue, then the API reference. 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?

There is no output schema, and the description compensates by stating the result includes assignment and covers invisibly-scoped records. It leaves the no-match case and whether email/phone can be combined unstated, which is a small but real gap for a duplicate-check tool.

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% and both params are optional with clear descriptions, so the schema does the heavy lifting (baseline 3). The description confirms email/phone are the lookup keys but adds no format, matching, or combination semantics beyond that.

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?

Specific verb (check duplicate) plus resource (person/contact) and the exact lookup keys (email or phone). The scope note 'anywhere in the account (even ones this user cannot see)' distinguishes it from fub_get_person and fub_search_people without the agent needing to open either schema.

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?

Explicit trigger: 'Use before adding a lead.' That gives a clear when-to-use condition. It does not name search_people/get_person as the alternatives for non-duplicate-check lookups, so it stops short of full routing guidance.

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

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

With only destructiveHint=true in annotations, the description carries real burden, and it discloses a non-obvious behavioral gotcha (a deal with no users is invisible to agents) plus the dependency on fub_list_pipelines. It says nothing about auth requirements, error modes, or what the response contains, so it is good but not complete.

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?

Three short sentences, each carrying distinct information: what it does, the dependent lookup, and the critical userIds constraint, with the API endpoint tacked on compactly. Zero 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?

For a 15-parameter mutation with no output schema and partial schema coverage, the description omits return-value information (e.g. the new deal id, which an agent would need for follow-up calls) and gives no guidance on the many optional date/commission fields. It covers the essential create path but leaves meaningful gaps.

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 47%, below the threshold where the schema can carry parameter meaning alone, so the description must compensate. It adds semantics for only two of fifteen parameters (stageId's source and userIds' practical requirement), leaving price, description, and the six date fields undocumented in both places.

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 ('Create a deal in a pipeline stage') and points at fub_list_pipelines as the source for stage ids, which orients the agent within the sibling set. It does not explicitly contrast with fub_update_deal, so it falls just short of full sibling differentiation.

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 a concrete calling rule rather than just a purpose: stage ids must come from fub_list_pipelines, and userIds should be included or the deal is 'invisible to agents.' It stops short of stating when to prefer this over fub_update_deal or when not to create.

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

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

Annotations provide only destructiveHint=true and a title. The description adds a genuinely useful behavioral constraint not in the schema: that assignedUserId or assignedTo is required despite the schema listing only personId as required. However, it says nothing about side effects, permissions, or what the call returns, leaving the destructive hint unexplained.

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 compact sentences, front-loaded with the core action and the key constraint. The 'FUB: POST /v1/tasks' endpoint reference is minor but non-redundant. No wasted prose.

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?

For a 9-parameter creation tool with no output schema, the description is thin: it omits defaults, side effects, and the meaning of the destructive annotation. The schema and the added assignment rule cover enough to invoke it, but behavioral completeness is only adequate.

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 78% (high), so the schema already documents most parameters. The description adds the either/or assignment semantics for assignedUserId/assignedTo, which is real value beyond the schema, but nothing else about the remaining params.

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+resource ('Create a task on a contact') and clarifies the assignment requirement. Distinguishable from siblings like fub_update_task and fub_list_tasks, though it doesn't explicitly name them.

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 when-to-use vs alternatives guidance; it doesn't say when to prefer this over fub_update_task or how it relates to notes/events. The only context is the assignment requirement, which is a constraint rather than usage guidance.

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

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

readOnlyHint=true already covers the safety profile, so the description is free to add value, which it does: it flags the operation as cheap and unpacks the return payload (account + authenticated user). It stops short of detailing the user object's fields, but this is solid supplemental context beyond the annotation.

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 tight sentences plus the API route, with the subject (who the credential belongs to) front-loaded and no filler. Every clause earns its place.

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, the description carries the burden of describing returns and does so at a high level (id, domain, owner, user). It omits finer detail on the authenticated-user object, but for a simple read-only probe this is nearly complete.

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?

The tool takes zero parameters, so there is nothing to disambiguate and the schema is trivially complete. Baseline of 4 applies per the rubric for parameterless tools.

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?

Names a specific verb and resource - retrieving the identity tied to the credential - and enumerates what that identity contains (account id, domain, owner, authenticated user). This is inherently distinct from sibling data-access tools like fub_get_person or fub_list_users, so an agent can tell it apart without opening any schema.

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?

"A cheap way to confirm the API key works" gives a concrete when-to-use scenario (credential validation). It doesn't state explicit exclusions or name alternatives, but for a zero-param identity probe there is little ambiguity to resolve.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the endpoint path and the behavior of a specific parameter value, but says nothing about error handling for missing ids, return shape, or rate limits.

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 tight sentences with the primary action front-loaded, followed by the parameter tip and endpoint reference. Nothing is wasted or buried.

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?

For a simple read tool with full schema coverage and a readOnly annotation, the description covers what an agent needs to invoke it. Only the absence of any error or fallback context 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.

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 documented. The note that allFields pulls in custom fields and 'everything else' adds minor meaning beyond the schema's terse 'allFields / allCustom' wording, which lands at baseline.

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 (Fetch) and resource (one contact by id), and includes the underlying endpoint GET /v1/people/{id}. The singleton-by-id framing implicitly distinguishes it from the list-oriented siblings, though it never names an alternative explicitly.

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?

Usage is implied by 'by id', but there is no when-to-use guidance and no comparison to alternatives such as fub_search_people (for finding a person) or fub_get_identity. The agent must infer the fetch-vs-search boundary itself.

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

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

readOnlyHint=true already tells the agent this is a safe read. The description's main addition is the start/end coupling constraint and the mention of returned fields, but the coupling rule is already restated in the schema, and there is no pagination, rate-limit, or result-shape context beyond a bare field list.

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 compact sentences plus an endpoint reference, with the returned-shape and filtering constraints front-loaded and no filler. The 'FUB: GET /v1/appointments' trailer is marginal value but not padding.

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?

For a simple read-only list tool with full schema coverage and no output schema, the description covers return fields and filter combinations adequately. It leaves gaps on pagination behavior and on how this list differs from fub_list_events, both of which an agent working across sibling tools would benefit from.

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 all six parameters are already documented with their constraints (limit range, offset deep-paging hint, ISO-8601 formats). The description only restates the filtering semantics at a high level, adding nothing beyond the schema, so 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?

The description names the resource (calendar appointments) and the fields it returns (invitees, type, outcome), which is more specific than the bare title 'List appointments'. It does not, however, distinguish itself from the sibling fub_list_events, which an agent could plausibly confuse with calendar appointments.

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?

It states the three supported filter modes (person, user, start+end window) and the coupling rule that start and end must be used together. That implies usage but gives no explicit when-to-use or when-not-to-use guidance, and names no alternative tool for related queries.

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

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

readOnlyHint already declares this a safe read, so the description doesn't need to restate safety. It adds the useful detail that records carry outcome/direction/duration and cites the backing endpoint, but says nothing about pagination behavior or result volume, which matters for a list endpoint with limit/offset.

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 short sentences, resource-first, with no filler. The endpoint reference is compact and useful; nothing is wasted, though the sentence fragment style is minimal.

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?

For a read-only, six-parameter, no-required list endpoint with full schema documentation and no output schema, the description covers what the tool returns and how to filter. Only pagination behavior is left implicit, which the schema's limit/offset partially handle.

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 every parameter is already documented and the baseline is 3. The description's 'filter by person or number' loosely maps to phone/personId/toNumber/fromNumber but adds no syntax or format detail beyond the schema.

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?

Names the resource precisely ('Logged phone calls') and the fields returned (outcome, direction, duration), plus binder of the endpoint. Distinguishes itself from the write sibling fub_log_call, though it never names an alternative explicitly.

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?

'Filter by person or number' implies how to narrow results but gives no when-to-use guidance versus siblings like fub_list_text_messages, fub_list_events, or fub_log_call. Usage is inferable but not stated.

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

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

readOnlyHint=true already declares the safe-read profile, so the bar is lower, yet the description still adds genuine context: the operation is account-scoped, it enumerates the returned attributes, and it explains the practical consequence of the API name (usable as a key in customFields). The raw endpoint (GET /v1/customFields) is also disclosed. It stops short of pagination or default-count behavior, but adds real value beyond the annotation.

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?

Very short and front-loaded: the resource and returned attributes come first, the usage hint follows. Every sentence earns a place, though the trailing endpoint string is arguably redundant with the GET semantics and slightly interrupts the flow.

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, the description compensates well by describing the shape of returned field records (label, API name, type, dropdown choices) and their intended use. The main omissions are pagination behavior and default page size, which matter for a list endpoint with limit/offset parameters.

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 label, limit and offset are already fully documented in the schema, and the description adds nothing about their semantics or interplay. Baseline 3 is appropriate when the schema does the heavy lifting.

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?

The description names the resource precisely ('the account's contact custom fields') and enumerates what each field record contains (label, API name, type, dropdown choices), which distinguishes it from siblings like fub_list_deals or fub_list_pipelines. It never states the verb but the name 'list' plus the GET endpoint carries that. Clear, though sibling differentiation is implicit rather than explicit.

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?

There is no guidance on when to call this versus alternatives, nor any prerequisite or exclusion. 'Use the name as a key in customFields' is a downstream hint about interpreting results, not a selection guideline for the agent. No when-to-use framing at all.

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

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

Annotations already declare readOnlyHint=true, so safety is covered. The description usefully adds that response metadata includes totalByStageId and names the underlying endpoint (GET /v1/deals), but says nothing about pagination behavior or rate limits, even though the schema hints at a `next` cursor.

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?

Three short sentences, front-loaded with the resource and fields, then filters, then response/endpoint detail. Nothing is redundant or padded.

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, the description partially compensates by naming the carried fields and the totalByStageId metadata, and it covers the filter dimensions. It is nearly complete for a list tool, missing only explicit return-shape or pagination guidance.

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% with all 8 parameters documented, so the baseline is 3. The description's filter list (pipeline, user, person, status) maps to existing parameters but adds no syntax, format, or behavioral nuance beyond the schema.

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?

The description identifies the resource (deals/transactions) and enumerates the fields it carries, so an agent can tell it is the deal-listing tool distinct from fub_create_deal, fub_update_deal and the person/pipeline listers. However, it never uses a listing verb itself, relying on the name and title to signal the action, and it does not explicitly contrast itself with siblings.

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?

It states the filtering axes ('filter by pipeline, user, person or status'), which implies usage context, but offers no when-to-use versus alternatives (e.g., fub_list_pipelines to resolve IDs) and no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds a genuinely useful caveat that some events are only visible in the FUB app (a data-completeness limitation), but it says nothing about pagination constraints or how the result is scoped beyond that note.

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 short sentences plus an endpoint reference, with the core resource defined up front and no filler. Efficient and front-loaded, though the endpoint reference is redundant rather than additive.

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?

For a read-only list tool with full schema coverage, no required params, and no output schema, the description conveys what is returned and how to filter it. The app-visibility caveat closes the main completeness gap; missing return-shape detail is acceptable since no output schema exists and results are self-describing.

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% and each of the 7 parameters is well documented in the schema (including the full event-type enum and cursor guidance). The description's "filter by person or type" only gestures at personId/type, adding no syntax or meaning beyond the schema, so 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 resource (lead events / lead activity) with concrete examples of event types, and the endpoint reference (GET /v1/events) confirms the read-list semantics. It is clearly distinguishable from siblings like fub_list_calls and fub_list_tasks, though it never names those alternatives.

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?

"Filter by person or type" implies a usage pattern but gives no explicit when-to-use/when-not guidance or routing to siblings (e.g. fub_search_people or fub_list_calls). Usage context is present but left to inference.

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

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

readOnlyHint=true already declares this as a safe read. The description adds that the response includes pipelines together with their stages, which is genuinely useful content beyond the annotation, but it says nothing about pagination or the return shape beyond that single hint.

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 terse, front-loaded fragments with no filler; the resource comes first and the endpoint reference trails. It borders on overly sparse but every clause carries information.

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 and only a readOnly annotation, the description carries more of the burden. It covers the key payload fact (pipelines include stages) but omits return format and pagination behavior, leaving it barely adequate for a list tool.

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?

There is one optional parameter (name) with 100% schema coverage, and the schema already documents it as an exact pipeline name. The description adds no filtering syntax or behavior beyond the schema, so the baseline of 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 resource (deal pipelines) and scope (with their stages), and ties the output to the stage ids used by fub_create_deal / fub_update_deal, so the agent knows what it gets. It does not explicitly distinguish itself from the sibling fub_list_stages, leaving some ambiguity about which list tool returns what.

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?

The parenthetical implies why you would call it (to obtain stage ids for create/update deal), which is a useful usage cue. However, it never states when to prefer this over fub_list_stages or other list tools, nor any prerequisites, so the guidance is only implied.

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

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

readOnlyHint=true already declares the safe-read profile, so the description only needs to add context. It contributes the return shape (stages plus people counts) and the underlying endpoint (GET /v1/stages), but says nothing about pagination behavior or how the count is derived, which the offset/`next` schema hint only partially covers.

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 compact clauses, front-loaded with what the tool returns and immediately followed by its role relative to siblings. No filler, no repetition of the title.

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, the description usefully discloses that the response carries stage names and people counts, which is the key thing an agent needs. Deep-paging guidance lives in the schema's `offset` description rather than here, leaving a minor gap for a simple list endpoint.

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% and each of sort/limit/offset is documented in the schema itself, so the baseline of 3 applies. The description adds no parameter-level detail beyond what the schema already provides.

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 resource (contact lifecycle stages), enumerates representative values, and notes it returns people counts. It explicitly names the siblings (fub_search_people, fub_update_person) that consume these names, so an agent can place it precisely without opening a schema.

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?

The description makes the use case clear: this is the vocabulary lookup for the "stage" values that search/update tools take, which implies you call it before filtering or mutating by stage. It stops short of explicit when-not-to-use guidance or naming list-based alternatives, so it is strong context but not fully prescriptive.

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

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

Annotations declare readOnlyHint=true and the description's 'GET /v1/tasks' is consistent with that safe-read profile, so no contradiction. However, it adds no behavioral context beyond the endpoint, e.g. pagination behavior, default page size, or result ordering.

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?

Three short, front-loaded fragments with no filler; the resource and filters come first. The telegraphic style ('FUB: GET /v1/tasks') is efficient but borders on terse.

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?

For an 11-parameter list tool with no output schema, the description covers the main filter categories but omits paging semantics (limit/offset/next, FUB default 10) and return shape. With no output schema and no annotation detail, this leaves gaps an agent must resolve from the schema alone.

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 every parameter is already documented in the schema, making 3 the correct baseline. The description restates the 'due' enum and filter categories but adds no format or syntax detail beyond what the schema provides.

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 clear verb+resource ('Tasks') and enumerates the filterable dimensions, so an agent knows this lists task records. It does not distinguish itself from close siblings such as fub_list_calls, fub_list_appointments, or fub_list_events, which an agent could easily confuse with this tool.

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?

The filter list ('by person, assignee, type, completion, or due window') implies when the tool is useful, but there is no explicit when-to-use vs. when-not guidance and no routing to alternatives like fub_list_appointments for scheduled events. Usage must be inferred.

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

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

readOnlyHint=true already establishes the safe-read profile, so the bar is lower. The description adds real behavioral value beyond annotations by warning that message bodies may be redacted by FUB for privacy, which directly affects how an agent should interpret results.

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 short sentences with no filler, and the resource plus filter scope is front-loaded before the endpoint reference. Size is well matched to a simple list tool.

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?

For a read-only list tool with no output schema, annotations that cover safety, and fully documented params, the description supplies the one thing structured fields cannot: the privacy redaction caveat. Only the paging behavior is left implicit, and the schema's 'prefer next' note partially covers that.

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 all five parameters (limit, offset, personId, toNumber, fromNumber) are already documented in the schema. The description only restates the two filter axes at a high level, adding no syntax, default, or paging guidance beyond the schema.

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 the resource (text messages) and the two scoping keys (person or phone number), and names the underlying endpoint. It is clearly distinguishable from sibling read tools like fub_list_calls, though the 'list' verb itself is only carried by the name rather than the description.

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?

The description says what can be filtered but never states when to reach for this tool versus alternatives (e.g., fub_list_calls for call history, or a search tool). No prerequisites, no note about combining or omitting filters to browse all messages.

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

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

readOnlyHint=true already establishes this is a safe read. The description reinforces this with the underlying endpoint (GET /v1/users) but adds no behavioral detail beyond that — no pagination behavior, no result-size guidance, no note on what happens with the optional filters. With annotations carrying the safety profile, this is adequate but thin.

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?

A single front-loaded sentence stating the resource and its purpose, plus the endpoint reference. No filler, no restatement of the title or name.

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?

For a six-parameter, no-output-schema list tool, the description omits return shape and paging behavior (e.g., that results are id-bearing user records and that `next` is preferred for deep paging, which lives only in a parameter description). It is sufficient to call the tool, but not complete about the interaction.

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%, with each of the six parameters individually documented, so the schema does the heavy lifting. The description only tangentially enriches the role parameter by naming sample role values, which the schema already does as well. 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?

The description names the resource (users in the account) and disambiguates the term by listing the concrete roles it covers (agents, brokers, lenders), then states what the returned ids are for. No sibling tool lists users, so there is nothing to differentiate against, but the purpose is immediately clear.

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?

It gives a clear situational trigger: use this to get the ids you need when assigning people, tasks and deals. It stops short of naming alternatives or exclusions (e.g., how to look up a single known user), so it is context-rich but not a full when/when-not rule.

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

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

Annotations supply only destructiveHint=true and a title, so the description carries most of the burden. It usefully discloses that no outbound call is dialed and gives the backing endpoint (POST /v1/calls), but it does not explain the write semantics, permission requirements (the schema notes userId is admin-only), or what is created/returned. Adequate but thin for a mutation tool.

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?

Three short sentences, front-loaded with the core action, then the scope exclusion, then the API mapping. No filler and nothing buried.

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?

For a 10-parameter mutation tool with no output schema and minimal annotations, the description covers the what and the not-what but omits return behavior, permission constraints, and any guidance on the optional fields (recordingUrl, fromNumber/toNumber, duration). It is sufficient to start but not to call confidently.

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?

Ten parameters at 60% schema description coverage, and the description adds essentially nothing about them beyond 'with its outcome,' which merely gestures at the outcome field already enumerated in the schema. Required fields (personId, phone, isIncoming) and the admin-only userId restriction are left entirely to the schema.

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?

The description gives a specific verb and resource ('Record a phone call ... with its outcome') and adds a scope qualifier ('made or received outside FUB') plus the negative constraint 'Does not place a call.' It clarifies the operation well, though it never names the sibling it is meant to be distinguished from (e.g. fub_add_note or fub_list_calls).

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?

'Record a phone call made or received outside FUB' states when to use it, and 'Does not place a call' rules out a plausible but wrong interpretation. However, no alternative tool is named for the case where the call is placed by the system or when the user wants to attach a note instead.

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

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

With readOnlyHint=true already covering the safety profile, the description still adds real behavioral context: Trash-stage people are excluded unless includeTrash is true, and the default projection omits fields unless `fields` is passed. It adds moderate value beyond annotations.

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?

Five short sentences, each carrying a distinct behavioral fact (AND logic, partial matching, default sort, trash exclusion, projection) with no repetition of the schema. Front-loaded and waste-free.

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?

For a 25-parameter, zero-required search tool with no output schema and only a readOnly annotation, the description covers the non-obvious behavior (trash exclusion, default projection, sort default) well. It could say slightly more about paging (e.g. that `next` is preferred over `offset`), but the schema already carries that.

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% so the baseline is 3, but the description adds cross-parameter rules the schema cannot express: AND-combination of criteria, partial-match behavior for name filters, and how to widen the returned field set via `fields` / 'allFields'. That is genuine added meaning over the per-field descriptions.

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?

Opens with a specific verb+resource ('Search contacts and leads'), which cleanly separates it from single-record siblings like fub_get_person and fub_check_duplicate_person. The trailing 'FUB: GET /v1/people' anchors it to a concrete endpoint.

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 operative search semantics (criteria combine with AND, name filters are partial, newest-first default) and points to fub_list_stages for valid stage names. It never states the exclusion condition against alternatives, e.g. 'use fub_get_person when you already have an id', so it stops short of a 5.

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

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

Annotations only declare destructiveHint=true, so the description carries the real burden and delivers: de-duplication by email/phone, Lead Flow routing, agent notification, action plans for Registration/Inquiry, and the meaning of a 204 response (archived source, event ignored). This is uncommon depth beyond structured fields.

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?

Four sentences, zero filler, front-loaded with the create-vs-activity distinction and the response-code caveat last where it belongs.

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?

For a 10-param nested write tool with no output schema, the description covers the create/activity duality, de-dup behavior, side effects, and the key response outcome (204), leaving only auth/rate-limit details unstated.

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%, so the baseline is 3, but the description adds non-obvious semantics: de-dup keyed on email/phone, person.id targeting an existing contact, and the type-driven side effects (Registration/Inquiry). It clarifies the two required params beyond their field-level descriptions.

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+resource pair ('Add a new lead or record activity on an existing one') and frames it as FUB's documented lead-creation path, mapping to POST /v1/events. An agent can distinguish it from fub_update_person or fub_add_note without opening the schema.

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?

It gives conditional guidance inline ('use person.id to target a contact', de-dup by email/phone) but never states when to choose this over fub_update_person for modifying a contact, nor any exclusions. Usage is implied rather than stated.

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

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

Annotations supply only destructiveHint=true, so the description carries most of the disclosure burden and it does add one genuinely non-obvious, high-value fact: peopleIds/userIds replace the full list rather than append. It does not resolve the larger question for a destructive 14-parameter update — whether omitted fields (name, price, dates, description) are left untouched or cleared, nor any permission requirements.

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 tight sentences plus an API mapping note, with the core capability and the destructive list-replacement warning front-loaded. No filler sentences and nothing repeated from the title.

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?

For a 14-parameter destructive mutation with 21% schema coverage and no output schema, the description gives the essential scope and one critical caveat but leaves the partial-vs-full update semantics and date string formats unaddressed. It is usable but incomplete for an agent to call with confidence.

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 only 21%, so the description must compensate; it partially does by grouping the parameters into categories (stage, price, dates, people, agents) and by explaining the replacement behavior of the two array parameters. However, the seven-plus date and value fields (commissionValue, possessionDate, dueDiligenceDate, projectedCloseDate, earnestMoneyDueDate, finalWalkThroughDate, mutualAcceptanceDate) get no format or meaning added anywhere.

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 ('Update a deal') and enumerates the mutable dimensions — stage, price, dates, people, agents — so an agent knows exactly what the call can change. It does not explicitly contrast itself with fub_create_deal or fub_update_person, so sibling differentiation is left implicit.

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?

There is no when-to-use guidance, no mention of when not to use it, and no pointer to alternatives such as fub_create_deal for new deals or fub_update_person for contact changes. The only usage-adjacent statement is the replace-list semantics for peopleIds/userIds, which is behavioral rather than routing guidance.

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

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

Annotations only declare destructiveHint=true; the description goes well beyond that by disclosing that tags/phones/emails REPLACE existing lists, that contacted=true pauses action plans, and that source/sourceUrl are immutable post-creation. These are exactly the destructive side effects an agent must know before invoking, and they are consistent with the destructiveHint annotation.

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?

Dense and front-loaded: the cautions about replacement and immutability come before the API endpoint reference. Every clause carries actionable signal 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?

For a 19-parameter mutation tool with no output schema, the description covers the highest-risk behaviors (list replacement, action-plan pausing, immutable fields) that an agent most needs. It falls short only in not touching the remaining assignable/price/address parameters, which is a minor gap given the destructive semantics are covered.

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 low (32%), so the description must compensate. It does add crucial semantics for tags, mergeTags, phones, emails, and contacted, but leaves other significant parameters (price, stage, addresses, customFields, assigned* fields) unexplained beyond the schema, so the gap is only partially closed.

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 ("Update a contact's fields") that is easily distinguished from read siblings like fub_get_person or fub_search_people. It does not explicitly name alternatives or contrast scope with fub_update_deal/fub_update_task, but the purpose is unambiguous.

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?

The description explains behavior (what gets replaced, what is immutable) but never states when to use this tool versus alternatives such as fub_search_people to locate a record first, or fub_update_deal for related data. No prerequisites or exclusions are given.

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

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

Annotations provide only destructiveHint=true, so the description carries most of the burden. It does not disclose whether this is a full replacement (PUT semantics) that blanks omitted fields, whether partial updates are safe, permission requirements, or any return shape. The one useful clue, the PUT verb, is left unexplained.

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 short sentences with the action list front-loaded and the API mapping tacked on. No filler, no repetition of the title.

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?

For a 7-parameter mutation tool with 29% schema coverage and no output schema, the description covers the headline use cases but omits the id requirement, the role of personId, and the PUT replacement semantics. Adequate but clearly short of what this tool needs.

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 only 29%, so the description must compensate, and it does partially: 'mark it complete' maps to isCompleted, 'rename' to name, 'retype' to type, and 'reassign' to assignedTo/assignedUserId. It says nothing about the required id or what personId does, so the undocumented half of the parameters remains opaque.

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 (update) plus resource (task) and enumerates the concrete mutations available: complete, rename, retype, reassign. The 'FUB: PUT /v1/tasks/{id}' line pins the exact endpoint. It does not explicitly name sibling tools like fub_create_task or fub_list_tasks, but the verb alone separates it cleanly.

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 statement of when to use this versus fub_create_task (new task) or fub_update_deal, and no prerequisites such as needing an existing task id or what happens if the id is unknown. Usage is only inferable from the verb.

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