keap

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

The annotations declare destructiveHint=true, and the description reinforces this with a mutating verb. It also adds meaningful behavior Beyond annotations by noting that applying a tag segments contacts and can trigger automation. This gives the agent useful side-effect awareness without contradiction.

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 description is one focused sentence followed by a concrete endpoint reference. It is front-loaded with the primary action and includes only the most relevant side-effect context, with 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?

The operation is simple, both parameters are required and fully schema-documented, and the description covers the action, effect, and endpoint. With no output schema, a bit more detail about expected response or failure modes could help, but for a 2-param mutation the definition is largely complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% as both tag_id and contact_ids are documented in the schema. The description does not add much parameter-level detail beyond restating that a tag is applied to contacts, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: APPLY" is a clear action, 'a tag to one or more contacts' is the resource and scope. It also adds distinguishing context (segments them / can trigger automation) that sets it apart from sibling list/get/create tools, and the endpoint reference further clarifies the 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?

The description implies a use case: applying a tag to contacts, especially when segmentation or automation triggering is intended. However, it does not explicitly mention when not to use this tool or point to an alternative, so usage guidance is present but largely implicit.

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 says the tool CREATES a new contact, but the annotations set destructiveHint=true. Creating a record is not destructive, so the description directly contradicts the annotation and leaves the agent uncertain whether this call can destroy data.

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 focused sentences. The action and resource are front-loaded, the optional field guidance follows, and the endpoint reference supplies useful context without padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Nested objects and all parameters are documented in the schema, and the endpoint is given, but there is no output schema and return behavior is not described. More importantly, the contradictory destructiveHint leaves the operational impact unclear, so the description is not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description lists the same field names and merely adds 'any of' and 'optional extra,' which mostly recapitulates the schema rather than providing deeper semantics.

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?

Starts with 'CREATE a new contact in the Keap CRM' and ends with the endpoint 'POST /contacts'. This names the verb, resource, and system, and clearly differentiates from siblings like keap_update_contact and keap_get_contact.

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 'CREATE a new contact' and 'Provide any of ...' give clear context that the tool is for creating contacts and that no full set of fields is required. It does not explicitly exclude update/create alternatives, 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 declare destructiveHint=true, while the description says 'CREATE a task' and references POST /tasks. Creating a task is not destructive, so the description contradicts the annotation. No additional behavioral context such as side effects or required permissions is provided.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with no filler; the core action and endpoint are front-loaded and every sentence adds value.

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, the tool has 5 parameters, and the annotations conflict with the described behavior. The description does not clarify what the response will contain or reconcile the destructiveHint inconsistency, leaving an agent without enough context to fully understand the operation's effects.

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 fully documents title, due_date, contact_id, description, and extra. The description only adds that the task may be linked to a contact, which duplicates contact_id's schema description, and does not provide meaningful new parameter semantics.

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 (CREATE), resource (task), and domain (follow-up / to-do), plus the exact endpoint. This distinguishes it from sibling tools like keap_create_contact or keap_get_task without requiring 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?

The description implies use when a new task should be created, and optionally linked to a contact, but it does not explicitly state when not to use it or mention alternatives like keap_get_task, keap_list_tasks, or keap_update_contact. Usage guidance is only implicit.

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 declares this is a safe read operation, and the description is consistent with that. The description adds no behavioral detail beyond the endpoint pattern; it does not mention not-found behavior, field-selection effects, or response shape. With annotations present, this is adequate but not rich.

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 description is one concise sentence that immediately states the action and resource, then adds the endpoint as supporting context. Every word earns its place and there is no fluff.

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 single-company GET with only one required parameter, the description plus schema is sufficient for an agent to call it correctly. There is no output schema, so a note about the return shape would have been a minor bonus, but it is not essential for 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?

The input schema already describes both company_id and fields with 100% coverage, so the description does not need to restate them. The description adds no additional parameter nuance beyond confirming the lookup is by id.

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 action ('Get a single company by id') on a clear resource, distinguishing it from list-style sibling tools like keap_list_companies. Including the HTTP endpoint reinforces the operation without ambiguity.

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 'by id' clearly implies this tool should be used when a specific company_id is known and a single company is needed, versus listing companies. It does not explicitly name alternatives or exclusions, but the intended context is unambiguous from the description.

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 readOnlyHint=true already establishes the read-only nature, and the description's 'GET /contacts/{contact_id}' reinforces this without contradicting it. The description adds the concrete API endpoint but does not disclose potential error behavior, response format, or field-selection implications beyond what annotations and schema already imply.

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 description is two short sentences with no filler. The core purpose is front-loaded, and the API endpoint is provided as concise supporting context.

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 single-resource GET with two parameters and no output schema, the description is largely adequate. It could be more complete by indicating the default return behavior or what happens when fields is omitted, but the simplicity of the operation and annotation coverage make this 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 description coverage is 100%, so the schema already documents both contact_id and fields. The description only restates that lookup is by id and does not add meaningful parameter-level detail beyond what the input schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource: 'Get a single contact by id', which clearly identifies both the action and the target. This differentiates it from sibling tools like keap_list_contacts (list vs. single) and keap_get_company (contact vs. company).

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 when to use the tool: when you have a specific contact_id and want one contact. However, it does not explicitly mention alternatives such as keap_list_contacts for retrieving multiple contacts or keap_update_contact for modifying a contact, leaving usage differentiation mostly 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 readOnlyHint annotation already covers the safety profile, so the description does not need to restate it. It adds the GET endpoint and confirms single-record retrieval, but it does not mention error behavior, authentication, or response shape. This is acceptable given the annotation coverage.

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 description is two short sentences with no filler. It front-loads the core action and includes a useful endpoint reference, making every word valuable.

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 getter with one required parameter, full schema coverage, and a readOnlyHint annotation, the description is sufficiently complete. The endpoint, resource, and parameter are all covered; no output schema exists, but the operation is self-explanatory.

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 opportunity_id as 'The opportunity id.' The description adds little beyond the schema, merely repeating that retrieval is by id. Baseline 3 is appropriate because the schema carries the parameter documentation burden.

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: 'Get a single opportunity by id.' It also includes the exact REST endpoint, making the operation unambiguous. It is clearly differentiated from sibling list tools like keap_list_opportunities and other get_* 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?

The description clearly implies the use case: call this tool when you already have an opportunity_id and need exactly one opportunity. It does not explicitly name alternatives or exclusion criteria, but the 'single' and 'by id' wording gives clear contextual 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?

The readOnlyHint annotation already establishes that this is a safe read operation, and the description consistently describes a GET request. The description adds the endpoint string but does not disclose additional behavioral details such as error cases, required authentication, or response shape; the annotation carries most of the safety 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?

The description is two short sentences with no filler. The core operation is front-loaded, and the endpoint reference is compact and useful without bloating the 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 simple one-parameter, read-only tool, the description is nearly complete: it identifies the operation, the parameter, and the API endpoint. It does not describe the return value or error behavior, but given the low complexity and the readOnlyHint annotation, this is a minor gap rather than a critical 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 coverage is 100%: the single parameter task_id is already documented as 'The task id.' The description repeats that the lookup is 'by id' but adds no format, constraints, or additional meaning 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?

The description states a specific verb and resource: 'Get a single task by id.' It also names the exact Keap endpoint, which clearly distinguishes this retrieval tool from create/list siblings like keap_create_task and keap_list_tasks.

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 'single task by id' gives clear context for when to use this tool: when the agent already has a task_id and needs exactly one task. It does not explicitly mention alternatives or exclusions, but the single-task framing is enough to separate it from list operations.

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

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

Annotations declare readOnlyHint=true, and the description adds useful behavioral context by calling out filtering, ordering, and cursor pagination. This goes beyond the schema and gives the agent a clear picture of how the operation behaves.

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 with no filler. The core purpose is front-loaded, supported behavior is stated compactly, and the endpoint reference is useful without being verbose.

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, zero-required-parameter list operation with fully documented schema properties, the description is essentially complete. It could optionally describe the return payload shape since there is no output schema, but the verb 'List' plus endpoint makes the expected result unambiguous enough.

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 parameters are already fully documented. The description's mention of filtering, ordering, and cursor pagination loosely maps to filter, order_by, and page_token, but adds no new semantic detail beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('List') and resource ('referral-program affiliates'), and adds the Keap endpoint 'GET /affiliates' for unambiguous identification. It is clearly distinct from the sibling list tools because it targets affiliates specifically.

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 states the use case directly: listing referral-program affiliates, with filtering, ordering, and pagination supported. It does not mention alternatives or exclusions, but among the provided siblings there is no competing affiliate-list tool, so the intended context is clear.

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. The description adds behavioral context by specifying the supported capabilities (filtering, ordering, cursor pagination) and the underlying Keap endpoint GET /campaigns. This goes beyond the annotation and helps set expectations for paginated read 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?

The description is two concise sentences, front-loaded with the main purpose, and every clause adds relevant information. No filler or redundant detail.

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 operation with all optional parameters and no output schema, the description plus schema cover the essential invocation details. It could be slightly more complete by noting what the response contains, but the pagination and filtering context is sufficient for an agent to call it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the parameter meanings are already documented. The description's mention of filtering, ordering, and cursor pagination loosely aligns with filter, order_by, and page_token, but it adds no specific semantic value beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the action ('List') and resource ('marketing campaigns (automation sequences)'), adding useful context that campaigns are automation sequences. It does not explicitly distinguish itself from sibling list tools, but the verb+resource makes the purpose unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states that filtering, ordering, and cursor pagination are supported, implying when the tool is useful for listing campaigns. However, it provides no explicit guidance on when to choose this tool over sibling list tools or when NOT to use it.

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 communicates that this is a safe read operation. The description adds context beyond annotations by mentioning filtering, ordering, field selection, and cursor pagination, plus the underlying endpoint. However, it does not disclose response shape, pagination termination, or other behaviors an agent might need.

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 description is two sentences, front-loaded with the core operation and resource, and includes the key capability summary without redundant prose. 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?

For a simple list operation with no required parameters and fully documented schema properties, the description plus annotations are nearly sufficient. It lacks explicit guidance on sibling routing and return-value details, but the endpoint and capability list provide enough context for a competent agent to invoke it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents each parameter with examples. The description only restates capabilities like filtering and pagination that map to the schema parameters, adding no meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb-resource pair: 'List companies in the Keap CRM', which is specific and unambiguous. It differentiates from single-entity get_company by the 'List' operation and from other list_* tools by the 'companies' resource, but it does not explicitly call out the distinction.

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 is given on when to choose this tool over alternatives such as keap_get_company for a single company or keap_list_contacts for a different entity. The usage context is only implied by the tool name and sibling list, with no exclusions or 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 only provide readOnlyHint=true; the description adds meaningful behavioral context by disclosing supported query capabilities (filtering, ordering, field selection) and cursor pagination with page_size/page_token. Matching the GET /contacts method reinforces the read-only nature without contradicting 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?

Two compact sentences front-load the purpose and capability list, then close with the endpoint. No filler or redundant restatement of parameter names.

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 list operation with no required parameters and a fully documented schema, the description covers the important calling context: it identifies the resource, supported query features, and pagination mechanism. It does not describe the response envelope, but the schema's page_token explanation references next_page_token, and the endpoint is simple enough that 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?

All 5 parameters are already described in the input schema (100% coverage), so the schema carries the semantic burden. The description's brief mention of filtering/ordering/field selection/pagination aligns with the parameters but adds little detail beyond what the property descriptions already say.

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?

Clearly states a specific verb ('List') and resource ('contacts in the Keap CRM'), and reinforces the operation with the actual endpoint 'Keap: GET /contacts'. The plural resource and listing verb differentiate it from sibling get_contact/single-object 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?

Implied usage is clear: use this when you need to enumerate or search contacts in Keap rather than fetch a single contact or list a different entity. However, it does not explicitly state when to choose this over alternatives (e.g., get_contact for one record) 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?

With readOnlyHint=true already covering safety, the description adds useful behavioral context: it supports filtering, ordering, field selection, and cursor pagination, and it identifies the underlying HTTP API. It does not disclose response envelope details, but none are required for a simple read-only list operation.

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 concise sentences, front-loaded with the core action and resource, followed by capability summary and endpoint reference. Every sentence earns its place with no repetition.

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 operation with no output schema and a simple parameter set, the description is sufficiently complete. It states what the tool lists, the endpoint, and the key interaction patterns. It could mention that results are paginated, but that is already implied by 'cursor pagination' and explicitly covered in the page_token parameter.

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 parameters are already documented in the schema. The description adds a general summary of capabilities ('filtering, ordering, field selection, cursor pagination') that maps to the parameters, but does not add meaningfully beyond the existing parameter descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource: 'List sales opportunities (deals) in the pipeline.' It names the exact endpoint and differentiates the operation from sibling single-item tools like keap_get_opportunity.

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 clearly indicates this tool is for listing pipeline opportunities and mentions supported capabilities like filtering, ordering, and pagination. It does not explicitly name sibling alternatives for single-record lookups, but the verb 'list' and endpoint provide sufficient context.

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?

Beyond the readOnlyHint annotation, the description discloses that the tool supports filtering, ordering, and cursor pagination, and identifies the HTTP GET endpoint. It does not describe the response shape, but the read-only safety profile is already covered by 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?

The description is three short sentences with no filler. It front-loads the core purpose, then lists capabilities, then gives the endpoint, making it quick for an agent to parse.

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 four fully documented parameters, the description covers the key invocation details. The lack of an output schema means response shape is not described, but the essential behaviors and endpoint are 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 description coverage is 100%, so the parameters are fully documented in the schema itself. The description adds only a high-level mention of filtering, ordering, and pagination, which maps to the existing parameter descriptions without adding 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?

The description clearly identifies the action ('List') and the resource ('e-commerce orders'), and the 'Keap: GET /orders' line reinforces the scope. It does not explicitly differentiate from sibling list tools, but the resource noun is unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance is provided about when to use this tool over sibling list tools such as keap_list_subscriptions or keap_list_products. There is no discussion of optionality, prerequisites, or when filtering versus pagination is appropriate.

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 already declare readOnlyHint=true, and the description adds the endpoint and mentions cursor pagination. It does not disclose response shape, limits, or other behavioral details, but the read-only nature is established.

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 description is compact and readable, with the core purpose stated first followed by key capabilities and the endpoint. The phrase 'List products in the catalog' is somewhat redundant with the title, but the overall structure is efficient.

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 operation with no required parameters and fully documented schema fields, the description covers the essential usage context: endpoint, filtering/ordering, and pagination. A return-shape description is missing, but the schema and tool name compensate for most needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all four parameters and their formats. The description's mention of filtering, ordering, and cursor pagination loosely maps to the parameters but adds no extra meaning beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb and resource: it lists products from the catalog, and adds that filtering, ordering, and cursor pagination are supported. It does not explicitly differentiate this from sibling list tools, though the resource name 'products' provides some distinction.

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. It does not mention exclusions, prerequisites, or compare against sibling list tools, so an agent must infer usage from the resource name alone.

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 already declare readOnlyHint=true, and the description is consistent with that by saying 'List' and GET. It adds useful behavioral detail beyond the annotation: the operation supports filtering, ordering, and cursor pagination, and identifies the exact Keap endpoint. It does not disclose response shape or rate limits, but for a read-only list operation these omissions are 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?

Three short sentences: the first defines the action and resource, the second summarizes capabilities, and the third gives the endpoint. It is front-loaded, with no filler or repetition of the title beyond 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?

For a read-only list tool with no required parameters and full schema coverage, the description is nearly complete. It conveys the resource, pagination model, and endpoint. It does not explicitly describe the response format or next_page_token semantics, but these are largely implied by 'cursor pagination' and are absent from the output 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?

The schema already documents all four optional parameters at 100% coverage, so the baseline is 3. The description's mention of filtering, ordering, and cursor pagination summarizes the parameter capabilities but adds no new syntax, constraints, or examples beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific action ('List') and resource ('recurring subscriptions / payment plans'), and names the underlying endpoint (GET /subscriptions). This makes the tool's function unambiguous and implicitly distinguishes it from sibling list tools for orders, contacts, products, etc.

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 intended use is implied by the resource name ('subscriptions') and the list action, but the description does not explicitly state when to use this tool versus sibling list_* tools or when not to use it. There are no exclusionary conditions or alternative tool pointers.

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 no extra credit for safety. The description adds genuine behavioral context beyond annotations: account-level scoping, the fact that filtering/ordering are supported, and specifically that pagination is cursor-based. The GET /tags reference reinforces that this is a direct read with no side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Three short sentences, each earning its place: purpose/scope, capability summary, and the endpoint hint. The core purpose is front-loaded in the first sentence and there is zero filler or repetition of schema details.

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 zero required parameters and full schema coverage, an agent can determine a correct invocation from the description plus schema. The only gap is that the description does not hint at the response shape (fields of a tag object), which matters when chaining results into siblings like keap_apply_tag, but no output schema exists to carry that burden.

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 fully documents all four parameters (filter, order_by, page_size, page_token). Per baseline, the description need not add param-level detail; it only summarizes capabilities already visible in the schema rather than adding new syntactic or format guidance.

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 ('List') and resource ('tags defined in the account'), and adds purpose context ('used to segment contacts'). It clearly distinguishes this from the many sibling list_* tools because the resource is named explicitly, and the 'Keap: GET /tags' reference removes any ambiguity about the 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?

The account scoping and segmentation purpose give an agent clear context for when to select this tool among the 10+ sibling list tools. It does not explicitly name alternatives or give when-not-to-use exclusions, but since each sibling targets a different resource, the resource-name clarity largely carries the routing decision.

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 known. The description adds useful behavioral context by stating it supports filtering, ordering, and cursor pagination, and identifies the HTTP endpoint, but does not disclose rate limits, default page size, or response 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?

Two concise sentences with no filler. The core action, resource clarification, and key capabilities are front-loaded, and the API endpoint is included as a compact reference.

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 fully described parameters and sensible annotations, the description is mostly complete. It could be more complete by explaining return values or explicitly nameing keap_get_task as the single-record alternative, but the current level is adequate for correct selection and 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%, so every parameter is already documented with meaningful descriptions. The description's reference to filtering, ordering, and cursor pagination maps to those parameters but does not add semantic detail beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it lists tasks, clarifying they are follow-ups/to-dos, and identifies the underlying Keap GET /tasks API. This unambiguously separates it from keap_get_task (single task) and keap_create_task (write operation) based on the verb and resource.

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 no guidance on when to choose this tool over alternatives like keap_get_task or keap_create_task. The mention of filtering, ordering, and pagination implies collection use, but there is no explicit when-to-use or when-not-to-use instruction.

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 flag destructiveHint=true, so the mutation risk is disclosed. The description adds the key behavioral trait that unprovided fields remain unchanged, and it maps the operation to Keap PATCH /contacts/{contact_id}, preventing an agent from assuming a full replace. No contradiction with 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?

Two concise sentences front-load the core action and then pack the essential behavior and endpoint into a compact second sentence. 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?

Given the tool's moderate complexity (7 params, nested objects, no output schema), the description covers the target, allowed fields, partial-update behavior, and the HTTP endpoint. It omits response shape details, but no output schema exists, and the schema handles parameter documentation.

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. The description adds meaning by explaining that the named fields are the updatable set and, crucially, that only supplied fields are changed—this is not evident from the individual property descriptions. It also hints at how the 'extra' object merges other Keap fields, though this is mostly repeated 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?

States a specific verb and resource ('UPDATE an existing contact by id') and clarifies partial-update semantics with 'only supplied fields are changed'. This clearly differentiates it from keap_create_contact since it targets an existing contact.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description makes the usage context clear: update an existing contact by id, and only supplied fields are modified, implying a PATCH-like partial update. It does not explicitly mention alternatives such as keap_create_contact or when a different tool should be used, but the context is sufficient.

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