Read and write Less Annoying CRM contacts, notes, tasks, events, pipelines and groups.
Scored across 23 tools
Every tool targets a distinct resource and action, with descriptions explicitly clarifying boundaries (e.g., list_pipelines is setup, list_pipeline_items is data; events vs tasks are time-based vs date-based). The related group tools—get_contact_groups, list_groups, and list_contacts_in_group—are clearly differentiated. No two tools appear to do the same thing.
All names use a consistent lacrm_ prefix and snake_case verb_noun pattern, which makes the set predictable. There are minor inconsistencies in verb choice: add vs create (add_contact_to_group vs create_contact) and edit vs update (edit_contact/edit_task vs update_pipeline_item), but these do not seriously hinder recognition.
At 23 tools, the server sits in the heavy range (16–25) for a single CRM integration. While each tool is plausibly useful, several read-only list/get tools could be consolidated or made optional, making the surface feel slightly bloated for the domain.
The tool set covers creation, editing, and reading for contacts, tasks, and pipeline items, plus supplementary reads for events, notes, groups, users, and custom fields. However, there are no delete or remove operations anywhere (contacts, notes, events, tasks, group memberships, pipeline items), and notes/events lack update/edit tools, leaving notable lifecycle gaps.
Add a contact or company to a group (creates a group membership). Identify the group by group_id (preferred) or group_name — not both. LACRM: CreateGroupMembership.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | No | The group id (a long numeric Uid — always pass it as a string). | |
| contact_id | Yes | The contact or company id (a long numeric Uid — always pass it as a string). | |
| group_name | No | The group name, if you do not have its id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the safety posture is partly covered, and the description adds that the call creates a membership. It does not disclose idempotency (what happens if the contact is already in the group), required permissions, or whether the change is reversible — meaningful gaps for a state-mutating 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 tight clauses with zero waste; the core action is front-loaded, followed by the identification rule, then the internal API mapping. Every element 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?
For a simple three-parameter tool with full schema coverage and no output schema, the description plus annotations give the agent enough to invoke it correctly. The remaining gap is post-call behavior on duplicate membership and error conditions, which is not addressed anywhere.
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 baseline is 3, and the description adds real value beyond the schema by establishing a preference order between group_id and group_name and forbidding their joint use. It also clarifies that contact_id covers either a contact or a company, matching and reinforcing the schema rather than merely repeating it.
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 contact or company to a group") and parenthetically defines the underlying operation as creating a group membership, which disambiguates it from siblings like lacrm_get_contact_groups and lacrm_list_contacts_in_group. It does not, however, explicitly name a sibling or contrast itself with one, so sibling differentiation is inferred rather than stated.
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 clear invocation rule: identify the group by group_id (preferred) or group_name, and explicitly excludes passing both. This is genuine when/how guidance, but it is scoped to group identification and says nothing about when this tool is the right choice versus listing or removing memberships.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new contact (person) or company record. For a person, company_name links them to that company (creating it if needed). Company names must be unique. If assigned_to is omitted, the record is assigned to the API key's own user (one extra GetUser call). Returns { ContactId }. LACRM: CreateContact.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Full name of the person, or the company's name. | |
| No | Email address(es). | ||
| phone | No | Phone number(s). | |
| address | No | Address(es). | |
| website | No | Website URL(s). | |
| birthday | No | Birthday, yyyy-mm-dd (or 0000-M-D for no year). | |
| job_title | No | Job title (people only). | |
| is_company | No | true to create a COMPANY record. Default false (a person). | |
| assigned_to | No | UserId to assign the record to. Default: the API key's user. | |
| company_name | No | For a PERSON: the company they work at (created if it does not exist). Not used for company records. | |
| custom_fields | No | Extra fields keyed by the account's field names exactly as LACRM shows them (e.g. {"Lead Source": "Referral"}). Use lacrm_list_custom_fields to find them. Merged verbatim into Parameters. | |
| background_info | No | The Background Info text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply destructiveHint and a title, so the description carries real weight here and delivers: company-name uniqueness constraint, implicit company creation, the extra GetUser call as a side-effect/cost of omitting assigned_to, and the return shape { ContactId } with no output schema present. It does not discuss permissions or duplicate-name failure behavior.
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, front-loaded with purpose and scope, each carrying operational information. The trailing 'LACRM: CreateContact.' API tag is marginal filler, but everything else 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?
For a 12-parameter creation tool with nested objects and no output schema, the description covers the return value, the person/company fork, the uniqueness rule, and the default assignment. It leaves out what happens on a duplicate-company-name collision and doesn't flag the required 'name' field, both of which would complete the picture.
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 meaning beyond the schema: company_name's create-if-missing side effect and the extra API call cost of omitting assigned_to are not stated in the schema. custom_fields guidance is largely duplicated from 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?
Opens with a specific verb and resource ('Create a new contact (person) or company record') and explicitly covers the two modes the tool supports. An agent can immediately distinguish this from siblings like lacrm_edit_contact, lacrm_get_contact, and lacrm_search_contacts.
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 conditional guidance: company_name applies only when creating a person, is_company switches record type, and omitting assigned_to triggers the API-key user default. It never names an alternative (e.g. lacrm_edit_contact for existing records), so no explicit when-not guidance, but the context is clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a timed (or all-day) event on your calendar, optionally with contacts/users as attendees. The timezone of start_date becomes the event's timezone. Returns { EventId }. LACRM: CreateEvent.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Event name shown on the calendar. | |
| end_date | Yes | End, ISO 8601 date-time. | |
| location | No | ||
| attendees | No | Attendees: contacts and/or users. | |
| is_all_day | No | All-day event (times ignored). Default false. | |
| start_date | Yes | Start, ISO 8601 date-time, e.g. 2026-10-06T14:00:00-05:00. | |
| calendar_id | No | Calendar to put it on. Default: your primary (a long numeric Uid — always pass it as a string). | |
| description | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Description adds real value: the timezone-of-start_date rule, all-day option, and return shape ({ EventId }). But annotations declare destructiveHint=true — plausible for calendar mutation since it can add attendees/notify — yet the description never discloses any destructive/notification/permission behavior. That gap holds it to 3; there's no contradiction, just silence on the annotated risk.
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, all load-bearing: capability, timezone behavior, return value, plus alias. Front-loaded and 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?
For an 8-parameter mutation tool with no output schema, the description covers the essentials an agent needs (trigger, timezone rule, return). It leaves attendees/calendar_id defaults and destructive side-effects to the schema and annotations, which is acceptable given 75% 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?
Schema coverage is 75%, so most parameters are self-documenting. The description echoes 'attendees' and 'all-day' implicitly but adds no syntax or constraint detail beyond the schema (e.g. no required-field reminder, no calendar_id default emphasis) to compensate for the 25% gap.
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 timed (or all-day) event on your calendar') with scope qualifiers (attendees optional). Distinguishes cleanly from sibling lacrm_list_events, which is the read counterpart.
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?
Implicitly the tool for scheduling new events, but no explicit when-to-use guidance or routing vs alternatives (e.g. lacrm_list_events to check availability). Timezone behavior is mentioned but not framed as a usage decision.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Attach a plain-text note to a contact or company's history (newlines kept, HTML/markdown escaped). Returns { NoteId }. LACRM: CreateNote.
| Name | Required | Description | Default |
|---|---|---|---|
| note | Yes | The note text. | |
| contact_id | Yes | The contact or company id (a long numeric Uid — always pass it as a string). | |
| date_displayed | No | When the note should appear in history, ISO 8601 date-time. Default: now. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply destructiveHint=true, which is counterintuitive for an append operation, and the description usefully clarifies that content is appended to history with newlines preserved and HTML/markdown escaped. It also names the return value ({ NoteId }), adding meaningful behavior beyond the single annotation. It stops short of explaining why the mutation is marked destructive or 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?
Three compact sentences with no filler, and the behavioral essentials (plain-text handling, return shape) are front-loaded immediately after the core purpose.
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?
Params are fully covered by the schema, and the description compensates for the missing output schema by naming the return value. For a small 3-param tool this is nearly complete, though it could say more about the destructive annotation.
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 three parameters are already documented. The description confirms the tool targets a contact or company id, mildly reinforcing the schema, but adds no syntax or format details beyond what the schema provides. 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 (attach) and resource (plain-text note) plus scope (a contact or company's history). The 'plain-text, newlines kept, HTML/markdown escaped' detail makes the behavior concrete and distinguishable from sibling list_notes, which is a different 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?
No guidance on when to use this vs lacrm_list_notes, lacrm_create_task, or other create_* siblings, and no prerequisites or exclusions are given. Usage is only implied by the verb 'attach'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a pipeline item (deal, lead...) on a contact in a given pipeline and status, with an optional note. Returns { PipelineItemId }. LACRM: CreatePipelineItem.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Optional note shown in the item's history. | |
| status_id | Yes | The starting status id (from the pipeline's Statuses) (a long numeric Uid — always pass it as a string). | |
| contact_id | Yes | The contact or company id (a long numeric Uid — always pass it as a string). | |
| pipeline_id | Yes | The pipeline id (from lacrm_list_pipelines) (a long numeric Uid — always pass it as a string). | |
| run_status_automation | No | Run the status's automation. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The destructiveHint annotation already flags this as a write, and the description adds the return shape ({ PipelineItemId }) plus the fact that item types include deals/leads and that the note appears in history. It does not disclose permission requirements, whether duplicate items are allowed, or that run_status_automation can fire automations, so it adds moderate value but not rich behavioral context.
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?
Front-loaded core action followed by the return value in two compact sentences with no filler. The trailing 'LACRM: CreatePipelineItem.' merely echoes the tool name and could be dropped.
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 states the return value, and the schema fully carries parameter semantics. What is missing is behavioral framing for a mutating tool with only a destructiveHint annotation - no mention of automation side effects beyond the schema's run_status_automation flag, permissions, or duplicate handling.
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 parameter is well documented in the schema itself (including the lacrm_list_pipelines provenance for pipeline_id and the string-Uid convention). The description only restates that the note is optional, adding nothing the schema lacks, 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 ('Create a pipeline item... on a contact in a given pipeline and status') and enumerates the entity types (deal, lead), so the agent knows exactly what is produced. It does not explicitly contrast with the close sibling lacrm_update_pipeline_item, so it falls 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?
The description implies usage (attach a pipeline item to a contact) but never states when to prefer this over lacrm_update_pipeline_item or lacrm_add_contact_to_group, nor any prerequisites such as needing valid pipeline_id/status_id from lacrm_list_pipelines. No exclusions or alternatives are named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a to-do on a user's task list (date only, no time — use lacrm_create_event for timed things). Optionally attach it to a contact. Returns { TaskId }. LACRM: CreateTask.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Task name shown on the task list. | |
| due_date | No | Due date, yyyy-mm-dd. | |
| contact_id | No | Attach the task to this contact or company (a long numeric Uid — always pass it as a string). | |
| assigned_to | No | UserId to assign to. Default: you. | |
| calendar_id | No | Calendar to file it under. Default: your primary (a long numeric Uid — always pass it as a string). | |
| description | No | Longer details. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds behavior beyond the annotations: the date-only (no time) constraint, the optional contact linkage, the return shape { TaskId } (valuable since there is no output schema), and the underlying API mapping. It omits permission/authorization notes and what happens on invalid dates, but the destructiveHint annotation plus the stated writes cover the core profile.
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 zero filler; the core purpose and the sibling exclusion are front-loaded, and the return-shape note trails 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?
Six parameters, 100% schema coverage, and no output schema — so the description usefully compensates with the { TaskId } return note and the date-only rule. It stops short of mentioning required vs optional fields or failure behavior, but nothing critical for a correct call 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 every parameter is already documented with format hints (yyyy-mm-dd, string-only Uids, defaults). The description only reinforces the date-only semantics, which the schema itself already implies. 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 ('Create a to-do on a user's task list') and immediately distinguishes itself from the closest sibling, lacrm_create_event, by scoping to date-only items. An agent can separate it from lacrm_edit_task and lacrm_list_tasks 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?
Gives an explicit routing rule — use lacrm_create_event for timed things — and clarifies the optional contact attachment. It does not address when to prefer a note (lacrm_create_note) or pipeline item instead, but the primary disambiguation is present and clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update fields on an existing contact or company. Only the fields you pass change; omitted fields are left alone. Multi-value fields (email, phone, address, website) are REPLACED by the list you pass. Set is_company=true when renaming a company. LACRM: EditContact.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | New full name (person) or company name. | |
| No | Email address(es). | ||
| phone | No | Phone number(s). | |
| address | No | Address(es). | |
| website | No | Website URL(s). | |
| birthday | No | Birthday, yyyy-mm-dd (or 0000-M-D for no year). | |
| job_title | No | Job title (people only). | |
| contact_id | Yes | The contact or company id (a long numeric Uid — always pass it as a string). | |
| is_company | No | Set true if this record is a company, so `name` maps to its Company Name field. | |
| assigned_to | No | Reassign to this UserId. | |
| company_name | No | For a PERSON: the company they work at (created if it does not exist). Not used for company records. | |
| custom_fields | No | Extra fields keyed by the account's field names exactly as LACRM shows them (e.g. {"Lead Source": "Referral"}). Use lacrm_list_custom_fields to find them. Merged verbatim into Parameters. | |
| background_info | No | The Background Info text. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Goes well beyond the destructiveHint=true annotation by explaining the actual mutation model: omitted fields are left alone (safe partial update) while multi-value fields (email, phone, address, website) are fully REPLACED by the list passed. That replacement warning is critical data-loss context the annotation cannot express.
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, front-loaded with the core update semantics and the highest-risk behavior (REPLACED) before the incidental is_company note. 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 tool with no output schema and only a destructiveHint annotation, the description supplies exactly the missing behavioral risk (partial vs replacement fields) and cross-references the helper tool for custom field discovery. Nothing essential to correct invocation is absent.
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 genuinely new meaning: the pass-through vs replace distinction across parameters and the is_company=true rename rule. It also points to lacrm_list_custom_fields for custom_fields keys.
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 ('Update fields on an existing contact or company') and the scope word 'existing' cleanly separates it from the sibling create_contact. An agent can distinguish the read/update path from creation 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?
Clear context: this is for pre-existing records, and the field-level update semantics tell the agent exactly how to call it. It does not name an explicit alternative (e.g. create_contact for new records, lacrm_get_contact for reads), so it lacks the when-not routing of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a task — including marking it complete (is_complete=true) or re-opening it (false). Only passed fields change. LACRM: EditTask.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | ||
| task_id | Yes | The task id (a long numeric Uid — always pass it as a string). | |
| due_date | No | New due date, yyyy-mm-dd. | |
| contact_id | No | Attach to this contact instead (a long numeric Uid — always pass it as a string). | |
| assigned_to | No | Reassign to this UserId. | |
| calendar_id | No | Move to this calendar (a long numeric Uid — always pass it as a string). | |
| description | No | ||
| is_complete | No | true = mark complete, false = mark incomplete. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true and the title. The description adds genuinely useful behavior — that unspecified fields are left untouched (partial-update semantics) — which softens the destructive implication of overwriting data. It does not cover permissions, whether the update is reversible, 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, front-loaded with the core action, then the non-obvious complete/re-open flag and the partial-update rule. No filler, and the LACRM: EditTask reference is compact.
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 75% schema coverage and no output schema, the description is adequate but thin: it does not clarify that only task_id is required, nor what the result of a successful edit looks like operationally. The core call path is covered, the edges are not.
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 task_id, due_date, contact_id, assigned_to, calendar_id, and is_complete. The description restates the is_complete boolean semantics that the schema already provides, adding no new syntax or format detail beyond it. 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 gives a specific verb+resource ("Update a task") and clarifies a non-obvious sub-purpose — completing or re-opening via is_complete. That distinguishes it from lacrm_create_task and lacrm_list_tasks, 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?
"Only passed fields change" implies partial-update usage and the complete/re-open duality is spelled out, but there is no explicit when-to-use vs when-to-prefer-lacrm_create_task guidance or prerequisite statements. Usage context is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one contact or company record with all its fields (emails, phones, addresses, custom fields, owner). LACRM: GetContact.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_id | Yes | The contact or company id (a long numeric Uid — always pass it as a string). |
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 goes beyond that by disclosing what the record contains (emails, phones, addresses, custom fields, owner), which materially helps the agent decide whether this single call suffices instead of chaining other tools.
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 first sentence is front-loaded and efficient. The trailing 'LACRM: GetContact' merely restates the title and is redundant rather than harmful, costing it a perfect score.
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 does the minimum needed by summarizing the returned fields, and the tool is a simple one-parameter read. Minor gaps remain — no error behavior for an unknown id, no pagination or size caveats — but nothing critical for correct invocation.
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 parameter is fully documented there (including the string-Uid nuance), so the description adds no parameter-level meaning. Baseline 3 applies when the schema carries the load.
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) with an explicit scope of 'one', which implicitly separates it from the list/search siblings. The enumeration of returned field groups makes the action concrete rather than tautological.
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 singular 'one record' suggests this is for retrieving a known contact_id, but no alternative (e.g. lacrm_search_contacts, lacrm_list_contacts_in_group) or precondition is named. An agent must infer when this beats the search/list siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the groups one contact or company belongs to. LACRM: GetGroupsAttachedToContact.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1-based. Default 1. | |
| contact_id | Yes | The contact or company id (a long numeric Uid — always pass it as a string). | |
| max_results | No | Results per page (MaxNumberOfResults), 1-10000. Default here: 50. |
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 adds nothing beyond that: no note on pagination behavior across pages, no mention of what happens for a non-existent or company-type id, no result-shape hints. With annotations carrying the safety profile, this leaves the description with essentially zero added behavioral value.
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 tight, front-loaded sentence with the tool's purpose first. The trailing 'LACRM: GetGroupsAttachedToContact.' is redundant internal naming and slightly dilutes the otherwise efficient structure.
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 fully documented params and annotations, the essentials are covered. However, with no output schema, the description never says what a result looks like (group ids, names) or how pagination terminates, which an agent needs to consume the response.
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% – page, contact_id (long numeric Uid passed as string) and max_results (1-10000, default 50) are all documented in the schema. The description adds no parameter meaning beyond that, 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 clear verb+resource with scope ('the groups one contact or company belongs to'), which distinguishes it implicitly from lacrm_list_groups (all groups) and lacrm_list_contacts_in_group (the inverse direction). It does not explicitly name those siblings, and the trailing 'LACRM: GetGroupsAttachedToContact.' is internal plumbing that adds no meaning.
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 guidance, no prerequisites, and no comparison to the closely related lacrm_list_groups / lacrm_add_contact_to_group / lacrm_list_contacts_in_group tools. The agent must infer the use case from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
All pipeline items attached to one contact or company, grouped by pipeline. LACRM: GetPipelineItemsAttachedToContact.
| Name | Required | Description | Default |
|---|---|---|---|
| contact_id | Yes | The contact or company id (a long numeric Uid — always pass it as a string). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already establishes this is a safe read. The description adds one useful behavioral detail beyond the annotations — that results are 'grouped by pipeline' — but says nothing about pagination, ordering, or return 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?
The core sentence is front-loaded and waste-free. The trailing 'LACRM: GetPipelineItemsAttachedToContact.' is an internal API name that adds little for an agent, a minor blemish.
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 tool with one fully documented parameter, the description covers what it does and how results are grouped, which compensates for the absent output schema. Nothing critical for a correct call 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 the single contact_id parameter (including the 'always pass it as a string' hint and its contact-or-company scope) is fully documented in the schema. The description's 'one contact or company' restates what the schema already says, adding no new meaning.
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 (get pipeline items attached to a contact/company) and the scope ('one contact or company'), so the agent can distinguish it from the broader lacrm_list_pipeline_items. It does not name that sibling explicitly, so differentiation relies on the reader inferring it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'attached to one contact or company' implies the use case (fetch a single entity's items) versus a global list, but there is no explicit when/when-not guidance and no reference to lacrm_list_pipeline_items as the alternative. 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.
Return the user who owns this API key — UserId, name, email and timezone. A cheap way to confirm the key works, and the UserId to use for AssignedTo. LACRM: GetUser.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 real value on top: it is side-effect-free in the sense of being 'cheap', it lists the exact fields returned, and it flags the practical purpose of verifying key validity.
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 that front-load the purpose and the returned payload before the usage hint. No filler beyond the trailing 'LACRM: GetUser' provenance marker.
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 no parameters, the description carries the burden and does name the return fields, which is exactly what an agent needs. It omits error behavior on an invalid key, a minor gap for a zero-param diagnostic 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?
The tool takes zero parameters, so the baseline of 4 applies. The description correctly implies no input is needed by framing the call as key-scoped.
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 the returned fields (UserId, name, email, timezone). It implicitly contrasts with lacrm_list_users by scoping to the key owner, but never names the sibling, so differentiation is inferred 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?
Gives two concrete uses: cheaply confirming the API key works, and sourcing the UserId for AssignedTo. That is clear when-to-use guidance, though it names no exclusions or alternative tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the contacts that are members of one group. Identify the group by group_id (preferred) or group_name — not both. LACRM: GetContactsInGroup.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1-based. Default 1. | |
| group_id | No | The group id (a long numeric Uid — always pass it as a string). | |
| group_name | No | The group name, if you do not have its id. | |
| max_results | No | Results per page (MaxNumberOfResults), 1-10000. Default here: 50. |
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 identifier exclusivity rule and the upstream API name (GetContactsInGroup), but says nothing about pagination behavior, result totals, or what happens when neither identifier is supplied.
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 that front-load the action, followed by the API mapping. Little waste, though the trailing 'LACRM: GetContactsInGroup' is metadata rather than instruction.
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, so the description carries the burden of describing returns, yet it never says what a result contains, how pagination/total counts work, or the behavior when no identifier matches. Adequate for calling the tool correctly, but incomplete for anticipating the response.
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. The description earns an extra point by supplying a constraint the schema does not encode: group_id and group_name are mutually exclusive and id is preferred. It does not, however, explain the interaction of page and max_results beyond what the schema 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 contacts that are members of one group), which is unambiguous. It does not explicitly differentiate from the closest siblings, e.g. lacrm_get_contact_groups (the reverse direction) or lacrm_add_contact_to_group, but the operation itself is 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?
Gives real selection guidance for the identifier parameter: prefer group_id, fall back to group_name, and never pass both. However, it offers no when-to-use guidance relative to sibling tools such as lacrm_get_contact_groups or lacrm_search_contacts, so usage is only partially covered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's field definitions (name, type, options) for contacts, companies or pipelines — use the Name values as keys in custom_fields when creating/editing contacts. LACRM: GetCustomFields.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1-based. Default 1. | |
| max_results | No | Results per page (MaxNumberOfResults), 1-10000. Default here: 50. | |
| pipeline_id | No | For pipeline fields, only this pipeline's (a long numeric Uid — always pass it as a string). | |
| record_type | No | Only fields for this record type. | |
| include_archived | No | Include deleted fields. Default false. |
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 real behavioral value by disclosing the cross-tool contract (returned Name values are the keys accepted in custom_fields), which no annotation or schema conveys.
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 dense sentence that front-loads the action and purpose, then the practical usage note, followed by a compact API-name tag. 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?
With no output schema, the description steps in by naming the returned attributes (name, type, options) and the three record types. It is callable as-is; only pagination/return-envelope behavior is left implicit, which is minor for a read-only metadata listing.
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, pipeline_id, record_type, and include_archived. The description adds only the 'name, type, options' output hint and the record_type enumeration in prose, so it neither compensates nor detracts — 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 enumerates what is returned (name, type, options) plus the record-type scope. This clearly distinguishes it from sibling list tools that return records (contacts, pipelines, tasks) rather than field metadata.
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 when-to-use: 'use the Name values as keys in custom_fields when creating/editing contacts,' tying it to lacrm_create_contact/lacrm_edit_contact. No explicit when-not or alternative tool is named, but the context is unambiguous for a metadata-lookup tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List calendar events in a date range, filterable by user or calendar. If contact_id is given, all events attached to that contact are returned and other filters are ignored. LACRM: GetEvents.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1-based. Default 1. | |
| end_date | No | End of the range (inclusive), ISO 8601 date or date-time. | |
| user_ids | No | Only events for these UserIds. | |
| contact_id | No | Only events attached to this contact (a long numeric Uid — always pass it as a string). | |
| start_date | No | Start of the range (inclusive), ISO 8601 date or date-time. | |
| max_results | No | Results per page (MaxNumberOfResults), 1-10000. Default here: 50. | |
| calendar_ids | No | Only events on these CalendarIds (your own calendars only). | |
| sort_direction | No | Sort direction. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile. The description adds the important behavioral detail that contact_id overrides other filters, which goes beyond annotations. But it doesn't disclose pagination behavior or return format.
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 terse sentences that front-load the core purpose, then the filter behavior, then the API reference. 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?
Adequate for a read-only list tool with full schema coverage and annotations covering safety. It lacks return format/pagination detail, but for a read-only listing tool this is a minor 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 schema documents all 8 parameters thoroughly. The description adds the contact_id precedence rule, which is meaningful, but beyond that the schema does the heavy lifting. 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+resource (list calendar events) with scope (date range) and filter dimensions (user or calendar). It's clear, though it doesn't differentiate from the create_event sibling which is a different operation anyway, so a 4 is warranted.
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?
Provides a clear conditional rule: if contact_id is given, all events attached to that contact are returned and other filters are ignored. This is important guidance about precedence. However, no explicit when-to-use-this-vs-alternatives guidance relative to siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the contact groups you can see (GroupId, Name, Sharing, Color), optionally with member counts. LACRM: GetGroups.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1-based. Default 1. | |
| max_results | No | Results per page (MaxNumberOfResults), 1-10000. Default here: 50. | |
| include_contact_counts | No | Also return the number of contacts in each group (slower). |
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 adds that member counts are optional and permission-scoped results ('you can see'), but says nothing about pagination behaviour, default ordering, or size limits, which are relevant for a paged list endpoint.
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, zero filler, with the core action and return shape front-loaded before the optional modifier. The trailing 'LACRM: GetGroups' alias is terse and useful for mapping to the upstream API.
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 compensates by naming the returned fields and the optional count. Pagination semantics rely on the schema, which is acceptable, but a brief note on ordering or result scope would make it fully self-sufficient.
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 and include_contact_counts are already fully documented in the schema. The description only echoes the optional member-count behaviour, adding no new syntax or default information. 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 the contact groups') and even enumerates the returned fields (GroupId, Name, Sharing, Color), which lets an agent predict the payload. It does not explicitly contrast with near-name siblings like lacrm_get_contact_groups or lacrm_list_contacts_in_group, so it falls short of 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?
No guidance on when to use this versus the many sibling list/get tools, nor on prerequisites. The only implicit usage signal is the scope phrase 'you can see', which hints at permission-filtered results but is never explained.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List notes, newest first by default — across the whole CRM, or for one contact. Filter by date range and author. LACRM: GetNotes.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1-based. Default 1. | |
| date_end | No | Only notes on/before this date-time (ISO 8601). | |
| user_ids | No | Only notes entered by these UserIds. | |
| contact_id | No | Only notes attached to this contact (a long numeric Uid — always pass it as a string). | |
| date_start | No | Only notes on/after this date-time (ISO 8601). | |
| max_results | No | Results per page (MaxNumberOfResults), 1-10000. Default here: 50. | |
| sort_direction | No | Sort direction. |
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 the default ordering (newest first), but says nothing about pagination behavior, page size limits, or result volume — the sort_direction param can override the stated default, which is left implicit.
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, front-loaded with the scope before the filters, and the API operation name (GetNotes) appended as a compact identifier. No wasted words.
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?
All seven parameters are optional, safety is covered by annotations, and the description covers scope, default ordering, and filter dimensions. With no output schema, pagination and response shape remain unstated, which is a minor gap for a list tool rather than a blocking one.
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 (including the author/user_ids mapping and the contact_id string-uid caveat) is already documented in the schema. The description restates the date-range and author filters without adding format or edge-case detail, 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 verb and resource (list notes) plus its two scopes — whole CRM or a single contact — and the default sort order. An agent can distinguish this from lacrm_create_note (opposite operation) and from contact-scoped getters 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?
Gives clear context for selection: use it globally, or pass a contact to narrow to one contact's notes, and filter by date range and author. It stops short of naming alternatives or exclusions (e.g., whether lacrm_get_contact already returns notes), so it is context without routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the items in one pipeline (deals, leads...), optionally only in given statuses or for given users. An empty status filter returns items in all ACTIVE statuses. LACRM: GetPipelineItems.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1-based. Default 1. | |
| sort_by | No | Default Status. | |
| user_ids | No | Only items whose contact is assigned to these UserIds. | |
| status_ids | No | Only items in these StatusIds. | |
| max_results | No | Results per page (MaxNumberOfResults), 1-10000. Default here: 50. | |
| pipeline_id | Yes | The pipeline id (from lacrm_list_pipelines) (a long numeric Uid — always pass it as a string). | |
| sort_direction | No | Sort direction. | |
| advanced_filters | No | AdvancedFilters, ANDed together. See https://account.lessannoyingcrm.com/api_docs/v2/Advanced/Filter_Contacts for the names/operations your account supports. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already covers the safety profile, and the description adds genuinely non-obvious behavioral context: an empty status filter returns items in all ACTIVE statuses, plus the underlying LACRM endpoint name (GetPipelineItems). It does not cover pagination behavior, but the annotations carry the important safety signal.
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, no filler, with the scope statement front-loaded and the non-obvious empty-filter rule immediately following. 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?
For a read-only list tool with a fully documented 8-parameter schema and no output schema, the description covers scope and a key filter subtlety. It leaves pagination and result-shape expectations to the schema, which is reasonable given the parameter descriptions handle those.
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 eight parameters including page, sort, filters, and pipeline_id. The description's only added semantic is the empty-status-filters behavior, which is useful but marginal against a fully documented 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 (List) and resource (items in one pipeline) and clarifies the item types with examples (deals, leads...). It reads clearly against lacrm_list_pipelines, though it doesn't explicitly name sibling list tools like lacrm_get_contact_pipeline_items as 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?
Gives the useful filter conditions ('optionally only in given statuses or for given users') and the empty-status semantics, but offers no explicit when-to-use vs when-not guidance relative to the sibling tools that also return pipeline items (lacrm_list_pipelines, lacrm_get_contact_pipeline_items).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the account's pipelines (e.g. Sales Leads) with their statuses (StatusId, Name, IsActive) and optionally their custom fields. This is the setup, not the items — use lacrm_list_pipeline_items for those. LACRM: GetPipelines.
| Name | Required | Description | Default |
|---|---|---|---|
| include_archived | No | Include deleted pipelines. Default false. | |
| include_custom_fields | No | Include each pipeline's custom field definitions. Default here: false (they are verbose). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already declares the safety profile, but the description adds value beyond it: it discloses the returned entity shape (StatusId, Name, IsActive) and the tradeoff that custom fields are verbose and off by default. It does not discuss pagination or ordering, so it stops 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 sentences, front-loaded with the core purpose and the sibling exclusion immediately after. The trailing 'LACRM: GetPipelines.' is a minor API-mapping annotation rather than description content, slight overhead but not harmful.
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, so the description carries the return-value burden and does so by naming the status fields and the optional custom-field payload. Combined with the 100% schema coverage and readOnly annotation, nothing an agent needs to call this 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?
Schema coverage is 100% and both parameters are already documented in the schema with their defaults, so the description only marginally reinforces them ('optionally their custom fields'). 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?
Specific verb+resource ('List the account's pipelines') with concrete example ('Sales Leads') and an explicit statement of what is returned (statuses with StatusId, Name, IsActive). It directly names and rules out the sibling lacrm_list_pipeline_items, so an agent can disambiguate 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 states 'This is the setup, not the items — use lacrm_list_pipeline_items for those,' which gives both the boundary and the named alternative. The inclusion of the 'LACRM: GetPipelines' API mapping further anchors when this tool applies.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List tasks due in a date range, optionally only incomplete/complete, for given users. If contact_id is given, ALL of that contact's tasks are returned regardless of dates or status. LACRM: GetTasks.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1-based. Default 1. | |
| end_date | Yes | Upper bound of due dates, yyyy-mm-dd. | |
| user_ids | No | Only tasks assigned to these UserIds. | |
| contact_id | No | Only tasks attached to this contact (a long numeric Uid — always pass it as a string). | |
| start_date | Yes | Lower bound of due dates, yyyy-mm-dd. | |
| max_results | No | Results per page (MaxNumberOfResults), 1-10000. Default here: 50. | |
| sort_direction | No | Sort direction. | |
| completion_status | No | Default Both. |
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 genuinely non-obvious behavior: contact_id silently overrides the date range and status filter. It stops short of disclosing pagination/result-cap behavior, which is left entirely to 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 tight sentences, front-loading the default scope and then the exception, with no redundancy. The trailing 'LACRM: GetTasks.' API mapping is minor filler 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 an 8-parameter read tool with no output schema, the description covers the parameters whose interaction is subtle (contact_id vs. dates/status) while the schema handles pagination, sorting, and result caps verbatim. Return shape is unspecified, but that is a minor gap for a 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 coverage is 100%, so the baseline is 3, but the description adds real semantics beyond the schema wording by clarifying that contact_id bypasses start_date/end_date/completion_status — something the schema's 'Only tasks attached to this contact' does not convey.
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 tasks) plus the scoping axes (due date range, completion status, assigned users). It is clearly distinguishable from the create/edit task siblings 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?
Gives a clear conditional rule for the contact_id override ('ALL of that contact's tasks are returned regardless of dates or status'), which is exactly the kind of usage guidance an agent needs. It does not, however, name an alternative sibling or say when to prefer a different listing tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the users on the account that you can see (admins see all), with their UserIds — needed to assign contacts, tasks or filter by owner. LACRM: GetUsers.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 real value beyond that by disclosing the permission-scoped visibility rule ('you can see, admins see all') and that UserIds are returned. No pagination or ordering behavior is mentioned, but for a small account-level list that 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?
A single sentence that front-loads the verb and resource, then appends the practical use case. The trailing 'LACRM: GetUsers' API mapping is minor redundancy but useful for traceability, so it does not hurt much.
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 input parameters and no output schema, the description carries the burden of saying what comes back, and it does ('with their UserIds'). Combined with the visibility rule, an agent has enough to call it and use the result correctly; only ordering/pagination details are absent.
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 and there is nothing for the description to disambiguate. It correctly notes that no filtering input is accepted.
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 ('users on the account') and clarifies scope ('that you can see, admins see all'). It also implicitly distinguishes itself from the sibling lacrm_get_user by covering the whole account rather than one user.
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 purposes ('needed to assign contacts, tasks or filter by owner'), which tells the agent when this tool is the right precursor step. It stops short of naming the single-user sibling lacrm_get_user as the alternative when one UserId is already known.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search (or list) contacts and companies. With no search_terms, returns everything visible, paged. Returns { HasMoreResults, Results }. LACRM: GetContacts.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1-based. Default 1. | |
| sort_by | No | Sort field. Default Relevance. | |
| max_results | No | Results per page (MaxNumberOfResults), 1-10000. Default here: 50. | |
| record_type | No | Limit to people (Contacts) or Companies. | |
| search_terms | No | Text to search for across record fields (name, email, phone, company...). | |
| owner_user_ids | No | Only records assigned to these UserIds. | |
| sort_direction | No | Sort direction. | |
| advanced_filters | No | AdvancedFilters, ANDed together. See https://account.lessannoyingcrm.com/api_docs/v2/Advanced/Filter_Contacts for the names/operations your account supports. | |
| requires_write_access | No | Only records you can edit. |
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-structural context: the fallback listing behavior when search_terms is omitted and the returned shape { HasMoreResults, Results }, which tells the agent how pagination terminates.
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: purpose first, then the no-filter behavior, then the return shape and API mapping. No filler; the API-operation tag is compact and potentially useful for doc cross-referencing.
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 nine fully documented parameters and no output schema, the description supply side is adequate: it names the return envelope and pagination semantics. It is slightly thin on how results interact with the many filter parameters (owner_user_ids, requires_write_access, advanced_filters), but nothing essential is missing for a correct call.
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, making 3 the baseline. The description adds only marginal meaning (search_terms is optional and its absence triggers a full listing); it does not clarify sort, filters, or the advanced_filters structure 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 (search/list) and resource (contacts and companies), plus the API operation mapping (LACRM: GetContacts). However, it never explicitly distinguishes itself from close siblings such as lacrm_get_contact or lacrm_list_contacts_in_group, so the agent must infer the boundary.
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 does convey an important usage rule: with no search_terms it returns everything visible, paged, making the tool act as a lister. But it offers no when-to-use guidance against alternatives (e.g. get_contact for a single record, list_contacts_in_group for group-scoped listing), leaving selection to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Move a pipeline item to another status (e.g. Prospect → Won) and/or add a note to its history. LACRM: EditPipelineItem.
| Name | Required | Description | Default |
|---|---|---|---|
| note | No | Note to add to the item's history. | |
| status_id | No | The new status id (a long numeric Uid — always pass it as a string). | |
| pipeline_item_id | Yes | The pipeline item id (a long numeric Uid — always pass it as a string). | |
| run_status_automation | No | If the status changes, run its automation. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, so the write/mutating nature is covered. The description adds the meaningful detail that status movement and note-appending can be combined or done independently, plus the API operation name (EditPipelineItem). It does not disclose whether changes are reversible, permissions required, or that a status change may trigger automation unless the schema param is 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 short sentences, front-loaded with the action and effect, with a minimal example. The trailing 'LACRM: EditPipelineItem.' is arguably redundant scaffolding but is compact and could aid API mapping. 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 4-param mutation tool with a fully documented schema and a destructiveHint annotation, the description covers the two core operations adequately. The absence of an output schema is acceptable since no return value is promised. Minor gap: no statement about what happens to the item or side effects of status changes.
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 baseline is 3 and the schema already documents all four parameters thoroughly (including the string-typed Uid hints and run_status_automation default). The description only re-surfaces 'status' and 'note' without adding 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?
States a specific verb+resource pair ('move a pipeline item to another status', 'add a note to its history'), so an agent immediately knows this mutates pipeline state. It also gives a concrete example (Prospect → Won). It does not name a sibling to differentiate from lacrm_create_pipeline_item or lacrm_get_contact_pipeline_items, however the verb 'update/move' versus 'create/get' is inherently distinct.
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 'and/or' phrasing implies this is the tool for both status changes and note additions, which is useful context. But there is no explicit when-to-use vs. when-not guidance, no prerequisites, and no mention of the sibling lacrm_create_note for note-only workflows. 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.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
lacrm_add_contact_to_group1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_create_contact1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_create_event1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_create_note1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_create_pipeline_item1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_create_task1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_edit_contact1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_edit_task1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_get_contact1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_get_contact_groups1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_get_contact_pipeline_items1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_get_user1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_list_contacts_in_group1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_list_custom_fields1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_list_events1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_list_groups1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_list_notes1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_list_pipeline_items1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_list_pipelines1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_list_tasks1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_list_users1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_search_contacts1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_update_pipeline_item1 field changedInput schema / $schemaPrevious value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"lacrm_add_contact_to_grouplacrm_create_contactlacrm_create_eventlacrm_create_notelacrm_create_pipeline_itemlacrm_create_tasklacrm_edit_contactlacrm_edit_tasklacrm_get_contactlacrm_get_contact_groupslacrm_get_contact_pipeline_itemslacrm_get_userlacrm_list_contacts_in_grouplacrm_list_custom_fieldslacrm_list_eventslacrm_list_groupslacrm_list_noteslacrm_list_pipeline_itemslacrm_list_pipelineslacrm_list_taskslacrm_list_userslacrm_search_contactslacrm_update_pipeline_itemRead deals, persons, organizations, activities and pipelines; create and update CRM records.
Read and write Copper CRM people, companies, opportunities and activities.
List and create Keap contacts, companies, tasks, opportunities, orders, tags and campaigns.
Read and write Folk CRM people, companies, groups and notes.
Add one secure layer between your agents and this server.