less-annoying-crm

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

With only destructiveHint=true in annotations, the description adds the useful clarification that this creates a membership rather than altering the group itself. However, it omits whether the call is idempotent when the contact is already a member, what permissions are required, and why the operation is flagged destructive.

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 with the action and the key selection rule front-loaded; the trailing 'LACRM: CreateGroupMembership' tag is metadata that does not impede reading. Little waste overall.

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 3-parameter mutation with full schema coverage and no output schema, the description covers the essentials (action, effect, group identification). It is still thin on duplicate handling, permissions, and post-call state, which matters for a write operation with minimal annotations.

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 real value beyond the schema: the mutual-exclusion rule ('group_id ... or group_name — not both') and the explicit preference order for identifying the group, which the schema does not express.

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 ('Add a contact or company to a group') and clarifies the underlying effect ('creates a group membership'). This cleanly distinguishes it from siblings like lacrm_list_contacts_in_group and the various lacrm_create_* tools.

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 tells the agent how to identify the group (group_id preferred, or group_name, not both), which is useful routing guidance, but never states when to use this tool versus alternatives or any exclusions such as whether the contact must already exist.

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?

The destructiveHint=true annotation covers the write/irreversibility profile, and the description adds genuinely non-obvious behavior: company names must be unique, an omitted assigned_to triggers an extra GetUser call, and a missing company is created implicitly. The implicit company creation is a real side effect an agent needs to know. It does not describe failure behavior on duplicate company names.

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 tight sentences, front-loaded with the person/company distinction, then the behavioral caveats. The trailing 'LACRM: CreateContact.' is a redundant endpoint label that restates the name rather than earning its place, which keeps this from a 5.

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, but the description supplies the return shape ('Returns { ContactId }'), and all 12 parameters are documented in the schema including nested objects. Combined with the noted side effects, an agent has enough to call this correctly; only error/duplicate-handling is unaddressed.

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 meaning the schema does not: the person/company branch of company_name, its create-if-missing behavior, and the default-plus-hidden-cost of assigned_to. Those are real semantic additions, though most of the remaining 10 parameters are left 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?

States a specific verb and resource ('create a new contact (person) or company record') and immediately distinguishes the two record types, which is the key fork in this tool. An agent can tell it apart from lacrm_edit_contact or lacrm_search_contacts 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 explains the semantics of specific parameters (when company_name applies, what happens if assigned_to is omitted), which implies usage, but never says when to pick this tool over siblings like lacrm_edit_contact or lacrm_search_contacts, and gives no exclusions. Usage is inferable but not spelled out.

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?

The annotation destructiveHint=true is not contradicted by 'Create', and the description adds real behavioral context beyond annotations: 'The timezone of start_date becomes the event's timezone' and the return shape '{ EventId }'. It stops short of disclosing side effects such as attendee notifications or 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 a short return-value clause, with the core action and the most surprising behavior (timezone propagation) front-loaded. 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 an 8-parameter mutation tool with no output schema, the description covers the event type, attendee option, timezone semantics, and return value. It omits attendee-side effects and calendar selection detail, but the remaining gaps are modest given the schema fills much of the rest.

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 75%, so the schema already documents most parameters, but the description supplies a non-obvious semantic rule not in the schema: the timezone of start_date becomes the event's timezone. That genuinely adds meaning beyond the structured fields.

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 states a specific verb and resource ('Create a timed (or all-day) event on your calendar') and clarifies scope with the optional attendees nuance. An agent can immediately distinguish this from siblings like lacrm_list_events 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?

Usage is implied by the creation verb and the timed/all-day distinction, and attendees are noted as optional. However, no explicit when-to-use guidance, prerequisites, or named alternatives (e.g., lacrm_list_events for reading) are provided.

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?

The description discloses real behavior beyond the annotations: newlines are preserved and HTML/markdown is escaped, and it states the return shape { NoteId }. It does not explain the surprising destructiveHint: true, but nothing in the text contradicts it.

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 compact sentence plus a return-value note, front-loaded with the action and resource and containing 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, the description usefully supplies the return value { NoteId } and the content-escaping semantics. The one omission is any explanation of the destructiveHint flag, which is atypical for a note-creation 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 coverage is 100%, so the schema already documents all three parameters and this sets the baseline at 3. The description adds genuine meaning for the 'note' parameter by specifying escaping and newline handling, which the schema does not.

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 — attach a note to a contact or company's history — and even names the underlying API operation (CreateNote). It is unambiguous versus siblings like lacrm_list_notes, but it never explicitly differentiates itself from neighboring creation tools.

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 use this tool versus alternatives, and no prerequisites or exclusions. 'LACRM: CreateNote' is an API mapping, not usage context, so an agent gets no routing help.

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 destructiveHint=true, so the safety profile is partly covered. The description adds a genuinely useful behavioral detail absent from structured fields: the return value '{ PipelineItemId }', which matters since there is no output schema. It does not, however, explain side effects such as status automations beyond what the schema already states.

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, front-loaded with the core action, and every clause earns its place: the domain clarification, the input context, the optional note, and the return shape.

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 create tool with full schema coverage, destructiveHint annotation, and no output schema, the definition is nearly complete—it even supplies the return value. A brief note on the automation side effect or that pipeline IDs come from lacrm_list_pipelines would make it fully self-contained.

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 fully documented (including the string-encoded Uids and the run_status_automation default). The description only loosely maps concepts ('given pipeline and status, with an optional note'), which is the correct baseline 3 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?

States a specific verb+resource ('Create a pipeline item') plus the parent context ('on a contact in a given pipeline and status'), and clarifies the domain term with 'deal, lead...'. It clearly reads as the creation counterpart to lacrm_update_pipeline_item, though it never names that sibling 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?

The description implies the setup inputs (a contact, a given pipeline and status) but gives no explicit when-to-use/when-not or routing guidance against siblings like lacrm_update_pipeline_item or lacrm_get_contact_pipeline_items. Usage is only implied through the 'Create' verb.

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 annotations present the bar is lower, and the description adds useful context: the return shape ({ TaskId }), the optional contact attachment, and the date-only semantics. It does not contradict destructiveHint=true (a create that writes new data), though it doesn't explain that hint either.

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 tightly packed sentences, front-loaded with the core action and alternative, then return value and API mapping. Every clause earns its place with no redundancy.

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?

No output schema exists, but the description supplies the return value ({ TaskId }), and all six parameters are documented in the schema. Annotations cover the safety profile, leaving little an agent would need that isn't already present.

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 baseline is 3, but the description adds meaning beyond the schema by stressing 'date only, no time' for the due date and framing contact_id as an optional attachment. These are semantic constraints not fully captured by the property descriptions alone.

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 to-do on a user's task list') and explicitly distinguishes it from the sibling lacrm_create_event for timed items. An agent can tell what it creates and how it differs from the closest alternative 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?

Names the alternative explicitly ('use lacrm_create_event for timed things') and clarifies the date-only nature, which drives the choice. It stops short of covering when to prefer lacrm_edit_task or other task siblings, so it's clear context without full exclusion coverage.

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 give destructiveHint=true; the description goes further by disclosing that the update is partial ('only fields you pass change') and that multi-value fields (email, phone, address, website) are REPLACED wholesale — the single most important data-loss behavior for an agent to know. It omits auth/permission requirements and any rate or idempotency notes.

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 compact sentences, front-loaded with the destructive replace warning, and every clause carries non-obvious information. 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 13-parameter mutation with no output schema, the description covers the highest-risk unknowns (partial update, replacement semantics, is_company coupling). What remains unstated — permission requirements and what the response returns on success — is minor but not trivial for an edit operation.

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 real meaning the schema does not: the partial-update rule, the replace-not-merge rule for multi-value lists, and the specific instruction to set is_company=true when renaming a company (which reframes the schema's terse 'set true if this record is a company' text).

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 fields on an existing contact or company'), and 'existing' implicitly distinguishes it from the sibling lacrm_create_contact. It never names get_contact or create_contact explicitly, so it stops 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?

Usage is implied by the semantics — agents can infer this is the tool for modifying an existing record vs. lacrm_create_contact — but no sentence states when to use it, when to prefer lacrm_search_contacts to find the id first, or when to fall back to field-specific tools. Adequate but guidance is 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?

The annotations only supply destructiveHint=true and a title, so the description adds real value with PATCH semantics ('Only passed fields change') and the is_complete=true/false effect, which is not derivable from the hint alone. However, it omits permissions/auth needs, what happens to fields left unset versus cleared, and any reversibility note 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 tight sentences with the core operation front-loaded, no padding. The trailing 'LACRM: EditTask.' is an internal API mapping that contributes little for an agent, a minor wasted clause.

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 single-required-parameter patch tool with no output schema, the description covers what changes (only passed fields) and the completion toggle, which is the operationally critical information. It is slightly thin on failure modes and return shape, but those are minor given the schema coverage.

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?

With 8 parameters and 75% schema description coverage, the schema already documents most parameters (task_id, contact_id, calendar_id, assigned_to, due_date, is_complete). The description restates the is_complete boolean meaning and the partial-update rule but adds no format, validation, or inter-parameter 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?

States a specific verb and resource ('Update a task') and goes further by naming the completion/re-opening payload semantics, which is more than a tautology. It is implicitly distinguishable from lacrm_create_task and lacrm_list_tasks by the edit verb, but it never explicitly contrasts itself with those 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?

Usage is only implied: the agent infers this is the tool for changing an existing task and for toggling completion. No alternative is named (e.g., find a task_id via lacrm_list_tasks, or use lacrm_create_task for new tasks), and there are no preconditions or exclusions 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 already declare readOnlyHint=true, so the safety profile is covered. The description adds meaningful value by disclosing the returned field groups (emails, phones, addresses, custom fields, owner), which is important since there is no output schema.

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?

The core sentence is front-loaded and efficient. The trailing 'LACRM: GetContact.' is redundant with the tool name/title and is the only wasted content.

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 single-parameter read tool with annotations covering safety and no output schema, the description covers both the operation and the returned field scope. Minor gap: no mention of what happens if the id is invalid or not found.

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 the single contact_id parameter is fully documented there, including the string-Uid warning. The description adds no parameter detail beyond the schema, 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 (Fetch) and resource (one contact or company record) and enumerates the field groups returned. The word 'one' implicitly separates it from the list/search siblings, though no sibling is named 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: fetch a single record by id. There is no explicit statement of when to use this versus lacrm_search_contacts or lacrm_list_contacts_in_group, nor any note that an id must first be obtained from a search.

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 no behavioral context beyond that — no pagination behavior, no default page size note, no auth requirements — which is acceptable given the annotation but leaves nothing extra.

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 trailing 'LACRM: GetGroupsAttachedToContact' is internal API mapping that adds little for an agent, but it is brief and not disruptive.

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 paginated read tool with fully documented parameters and readOnlyHint, the definition covers enough to invoke it correctly. With no output schema present there is a minor gap around the shape of the returned group list, but the tool is low-risk and self-evident.

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 page, contact_id, and max_results are already documented in the schema, including the 'contact or company id ... always pass as string' caveat. The description repeats that a contact or company is the subject but adds no syntax or format detail. 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 (List) and resource (groups) bound to a single contact or company, which distinguishes it from the sibling lacrm_list_groups (all groups) and lacrm_list_contacts_in_group (the inverse direction). An agent can pick it apart from siblings 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?

The scope phrase 'one contact or company' implies when to reach for it, but the description never states a when-to-use condition or names an alternative such as lacrm_list_groups or lacrm_add_contact_to_group. Usage is inferable from the name, not spelled out.

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?

The readOnlyHint annotation already establishes this as a safe read, lowering the burden on the description. The description adds a genuinely useful behavioral detail — results are grouped by pipeline — but says nothing about pagination, ordering, result volume, or empty cases. With annotations covering safety, this is a modest value-add.

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, front-loaded sentences that get to the point immediately. The trailing 'LACRM: GetPipelineItemsAttachedToContact' largely restates the tool name, which is mild redundancy, but overall it is tight and well-structured.

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 single-parameter read tool with safety covered by annotations, the description is close to sufficient, and 'grouped by pipeline' gives a hint about the return shape. However, with no output schema, it could have described the returned item structure more concretely. Adequate but with a clear gap.

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%; the contact_id parameter is fully documented in the schema, including the string-format nuance ('always pass it as a string'). The description only echoes 'one contact or company' without adding syntax or format detail. Baseline 3 applies 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 specific resource (pipeline items) and pins its scope to 'one contact or company,' which implicitly separates it from the sibling lacrm_list_pipeline_items. It adds the useful output-shape detail 'grouped by pipeline.' It stops short of naming the sibling or explicitly contrasting the two, so it is clear but not fully differentiated.

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/when-not guidance and no mention of the obvious alternative lacrm_list_pipeline_items or lacrm_list_pipelines. An agent must infer from scope alone that this is the contact-scoped variant. 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 declare readOnlyHint=true, so the safety profile is already covered. The description adds value beyond that by framing the call as 'cheap' (implying a lightweight, low-cost read) and by tying the returned UserId to downstream use in AssignedTo. No auth prerequisites or rate limits are mentioned, but little else is needed for a zero-argument read.

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 sentences, both front-loaded with the return shape first and the motivation second. The trailing 'LACRM: GetUser.' is a minor label but no sentence is wasted.

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 the return value and does so precisely (UserId, name, email, timezone). For a zero-param read tool with annotation-covered safety, nothing an agent needs to call it correctly is missing.

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 for the schema to describe and no gap for the description to fill. Baseline 4 for a no-parameter tool.

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 ('Return the user who owns this API key') and enumerates exactly which fields come back (UserId, name, email, timezone). The scope qualifier ('who owns this API key') cleanly separates it from the sibling lacrm_list_users, so an agent can choose without inspecting 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?

Gives two concrete use cases: a cheap key-validation check, and obtaining the UserId needed for AssignedTo. It doesn't explicitly name lacrm_list_users as the alternative when a full roster is needed, so it stops short of full when/when-not routing.

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 establish readOnlyHint=true, so the safety profile is covered. The description adds the mutual-exclusivity constraint and the preference ordering of the two identifiers, which is useful. It does not disclose pagination behavior or the shape of the returned contact list, but with annotations carrying safety that gap is minor.

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 sentences, front-loaded with the action and scope, followed by the identifier rule. No filler, and the trailing 'LACRM: GetContactsInGroup' is a compact upstream-method anchor.

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, fully schema-documented list tool with no output schema, the description covers selection and identifier semantics adequately. It could still note that results are paged (relevant given the page/max_results params) and roughly what a result row looks like, which is the only real gap.

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 genuine value the schema does not: that group_id and group_name are mutually exclusive and that group_id is preferred. The schema alone only hints at preference via 'if you do not have its id' and never states the exclusivity rule.

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 precise verb and resource with scope: 'List the contacts that are members of one group.' This is meaningfully narrower than lacrm_search_contacts or lacrm_get_contact_groups, so an agent can place it correctly. It stops short of a 5 because it never names the sibling it is not (e.g., search_contacts), leaving the differentiation to inference.

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 context is implied by the scope ('members of one group') but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g., use search_contacts for cross-group queries). The 'group_id (preferred) or group_name — not both' note is really parameter guidance rather than tool-selection 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's job is to add context beyond that, which it does by explaining what the returned definitions contain and how they feed into other calls. It omits any note on pagination behavior or that archived fields are excluded by default, leaving minor gaps.

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 with the core purpose front-loaded and no filler. The trailing 'LACRM: GetCustomFields.' mapping is a minor appendage rather than a structural flaw, but it slightly clutters an otherwise tight description.

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, the description adequately conveys what comes back (name, type, options) and the entity scope. It doesn't mention result limits or that pipeline_id narrows results, though the schema already covers those 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 page, max_results, pipeline_id, record_type, and include_archived are already fully documented. The description's phrasing 'for contacts, companies or pipelines' loosely echoes record_type but adds no syntax or format detail, 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 field definitions') and even enumerates the returned shape (name, type, options). The scope 'for contacts, companies or pipelines' cleanly distinguishes it from sibling tools like lacrm_get_contact or lacrm_list_pipelines.

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 downstream use case: 'use the Name values as keys in custom_fields when creating/editing contacts', which tells the agent why and when to call it before lacrm_create_contact/lacrm_edit_contact. It stops short of naming alternatives or explicit when-not-to-use conditions.

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 adds a non-obvious behavioral trait not present in the schema: contact_id short-circuits and overrides all other filters. It does not mention pagination behavior, but the page/max_results defaults are already documented in the schema.

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, zero filler, with the core scope stated first and the exception rule immediately after. The API endpoint hint ('LACRM: GetEvents') is a compact, useful trace to the underlying operation.

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 eight-parameter, zero-required read-only list tool with a fully documented schema, the description covers scope, filters, and the one surprising precedence rule. With no output schema, it could say a little more about the shape of returned events, but nothing critical to correct invocation is missing.

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 eight parameters are documented in the schema itself (including defaults and enum for sort_direction). The description only adds the cross-parameter override semantics for contact_id; it gives no additional format or syntax detail. Baseline 3 is appropriate.

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 calendar events') with the scope qualifier 'in a date range', and names the two filter axes (user, calendar). It is clearly distinguishable from lacrm_create_event, though it does not explicitly route against any ambiguous sibling.

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 usage condition: when contact_id is supplied, all events attached to that contact are returned and other filters are ignored. This is real when-to-use guidance, but no alternative tool is named for cases where the agent wants filtered-by-user results spanning contacts.

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 establish readOnlyHint=true, so safety is covered. The description adds genuine context beyond that: results are limited to groups the caller 'can see' (visibility/permission scoping) and member counts are flagged as slower, a performance caveat. It doesn't cover pagination behavior, so not a 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 compact sentences, zero filler, with the resource and returned fields front-loaded and the optional behavior trailing. 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 usefully names the returned fields, and annotations plus a fully documented schema cover safety and parameters. It is nearly complete for a simple read-only list tool, though it says nothing about ordering or total-count/pagination behavior.

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 the schema already documents page, max_results, and include_contact_counts (including the 'slower' note). The description's 'optionally with member counts' merely restates the boolean without adding syntax or default details, 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+resource ('List the contact groups') and even enumerates the returned fields (GroupId, Name, Sharing, Color), so the agent knows exactly what comes back. It doesn't explicitly distinguish itself from siblings like lacrm_list_contacts_in_group or lacrm_get_contact_groups, which would have pushed it to a 5.

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 phrase 'optionally with member counts' implies when to enable that flag, and 'you can see' hints at a permission scope, but there is no explicit when-to-use/when-not guidance and no sibling is named as an alternative. Usage 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 tells the agent this is a safe read, so the bar is lower. The description adds a genuinely useful behavioral default ('newest first by default'), but says nothing about pagination limits, default page size, or result shape.

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?

One sentence plus an API tag; scope and default ordering are front-loaded and nothing is redundant.

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 seven-parameter read-only list tool with no output schema, the description covers scope, filtering, and default ordering adequately. It could go slightly further on pagination behavior and what a returned note contains.

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 the schema already documents all seven parameters including defaults and formats. The description only echoes the date-range and author filters already present in the schema, adding no syntax or edge-case detail.

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 notes') plus its scope ('across the whole CRM, or for one contact'), which cleanly separates it from the sibling write tool lacrm_create_note. The trailing 'LACRM: GetNotes' maps it to the underlying API operation.

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 clear selection context: use it globally or narrow to a single contact, and filter by date range and author. It names no explicit alternative or exclusion (e.g., when to prefer create_note vs. this), 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 already declare readOnlyHint=true, so the safety profile is covered. The description adds a genuinely useful, non-obvious behavioral rule: an empty status filter returns items in all ACTIVE statuses (not all statuses). It stops short of describing pagination or result shape, keeping it below a 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 tightly packed sentences with the core operation front-loaded and no filler. The trailing 'LACRM: GetPipelineItems' marker is low-cost but slightly extraneous phrasing in an otherwise efficient definition.

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 8-parameter list tool with no output schema and only a readOnlyHint annotation, the description is barely adequate. It covers the status-filter edge case but is silent on pagination behavior, default sort, and how advanced_filters compose, even though the schema carries the parameter-level detail.

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 one of the 8 parameters is already documented in the schema and the baseline is 3. The description adds only the semantic that an empty status_ids filter means 'all active statuses'; it adds nothing for page, sort_by, sort_direction, max_results, or advanced_filters.

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 items in one pipeline') and clarifies the domain with examples (deals, leads...). It does not explicitly distinguish itself from the nearby siblings lacrm_get_contact_pipeline_items or lacrm_list_pipelines, which would have pushed it to a 5.

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 optional narrowing dimensions (statuses, users) and the empty-filter behavior, so usage is implied. However, it never says when to prefer this over the contact-scoped or pipeline-list siblings, and offers no stated prerequisites beyond the schema's reference to lacrm_list_pipelines.

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 adds real value beyond that by disclosing return content (statuses with StatusId/Name/IsActive) and warning that custom fields are verbose — explaining why the flag defaults to false. Pagination/auth behavior remains unstated, keeping it short of a 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?

Three tight clauses with zero filler; the core purpose is front-loaded before the sibling routing hint and API mapping. Every sentence 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 compensates by sketching the returned fields and the status shape, which is adequate for a simple read-only list tool. Minor gaps (no mention of ordering, pagination, or how archived/custom-field flags interact) keep it from a 5.

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% and both parameters document their defaults, so the schema does the heavy lifting. The description only obliquely references the custom-fields option ('optionally their custom fields'), adding little 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 ('List the account's pipelines') plus the returned structure (StatusId, Name, IsActive) and explicitly contrasts with lacrm_list_pipeline_items. An agent can distinguish it from the similarly named sibling without opening 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?

Explicitly frames the tool's role ('This is the setup, not the items') and names the alternative (lacrm_list_pipeline_items) for the item-listing case. When-to-use is unambiguous.

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 readOnlyHint=true, so the description carries the behavioral burden and does well by disclosing the non-obvious override: supplying contact_id returns ALL of that contact's tasks regardless of dates or status. That is exactly the kind of surprise an agent needs. It omits pagination/result-count behavior, keeping it from a 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 tight sentences with the main scope first and the important exception second; the trailing 'LACRM: GetTasks.' is a minor origin tag rather than padding. No redundant restatement 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 should say more about what a result set looks like and how paging works (page and max_results, default 50), since an 8-parameter list tool will often return more than one page. Safety is covered by readOnlyHint and filtering semantics are covered, but the return/pagination story is left entirely to the schema.

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 genuine semantics beyond the schema: the interaction between contact_id and start_date/end_date/completion_status (the date and status filters are ignored). That precondition is not expressible in the schema and materially affects how the parameters are combined.

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 ('List tasks') plus the scope axes that matter: date range, completion status, and user assignment. It is trivially distinguishable from the write-oriented siblings lacrm_create_task and lacrm_edit_task.

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 implies when the tool is appropriate (fetching tasks in a window) and hints at a special mode via contact_id, but never states when to prefer this over, say, sorting/filtering client-side or when the date-range mode is inappropriate. Usage is inferable rather than declared.

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, but the description adds a genuine behavioral trait: results are permission-scoped ("that you can see (admins see all)"). That visibility caveat is not derivable from the annotations or the empty schema and materially affects interpretation of the result set.

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 that carries the action, the permission scope, the returned identifier and the use case, ending with the API mapping ("LACRM: GetUsers."). No filler or redundancy.

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 zero-parameter read tool with no output schema, the description covers what it does, who sees what, and what it returns at the identifier level. It could go slightly further on the shape of the returned user records, but nothing required to invoke it correctly is missing.

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 the baseline is 4; there is no parameter syntax the description needs to compensate for. The mention of UserIds describes output content rather than an input, so no additional credit 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 users on the account") plus a scope qualifier ("that you can see (admins see all)") and names the returned identifier (UserIds). It is clearly distinguishable in substance from the single-record sibling lacrm_get_user, though it never names that sibling 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?

Gives concrete downstream context for calling it — "needed to assign contacts, tasks or filter by owner" — which tells the agent the scenario in which the UserIds are required. It stops short of stating exclusions or naming the alternative (lacrm_get_user) for single-user lookups.

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, and the description adds the no-search_terms fallback behavior and pagination, plus the return shape { HasMoreResults, Results }. Since there is no output schema, disclosing the return envelope is genuinely useful context beyond the 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?

Three short, front-loaded sentences with no filler; the primary behavior precedes the return-shape detail. The trailing 'LACRM: GetContacts.' mapping is minor but harmless.

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 search tool with a fully documented schema but no output schema, the description covers the important gaps: dual search/list mode, pagination, and return envelope. It is close to complete, lacking only alternative-routing 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%, so all nine parameters are already documented in the schema. The description only references search_terms implicitly and adds no syntax or format detail beyond what the schema provides; 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 pair (search/list) and resource (contacts and companies), so an agent immediately knows the operation. It does not explicitly differentiate itself from siblings like lacrm_list_contacts_in_group or lacrm_get_contact, which prevents a 5.

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 clarifies the dual mode ('with no search_terms, returns everything visible, paged'), which implicitly tells the agent it can be used as a listing tool. However, it never states when to prefer it over the sibling get/list tools or any exclusions.

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 destructiveHint=true, and the description adds only that a note lands in the item's history. It does not say what a status move destroys or overwrites (prior status, history entries), nor mention side effects like automation beyond what the schema's run_status_automation already documents.

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, front-loaded sentences with the core action first. The trailing 'LACRM: EditPipelineItem.' is a backend-method tag that adds little for an agent, a minor bit of waste.

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 4-param mutation tool with no output schema, the description covers the action but omits return behavior (does it echo the updated item?) and any permission prerequisites. Schema covers inputs, so the gap is mostly around outcomes.

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 four parameters are already documented, including the string-Uid guidance and the automation default. The description's only addition is the 'Prospect → Won' illustration of status_id, which is marginal.

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 (move) plus resource (pipeline item) and a secondary effect (annotate history), with a concrete status-transition example. It is distinguishable from lacrm_create_pipeline_item and lacrm_get_contact_pipeline_items, though it never names alternatives 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?

No when-to-use or when-not-to-use guidance. The 'and/or' phrasing hints the tool does two things, but nothing tells the agent when to prefer this over lacrm_create_note for logging history or lacrm_create_pipeline_item for a new item.

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