Sendlane MCP by usefulapi

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

With annotations already declaring write/destructive/idempotent, the description still adds real value: asynchronous acceptance via HTTP 202, the 100-contact cap, and the create-if-missing side effect. It leaves one meaningful gap for a destructive write — whether an already-existing contact's names, tags, or custom fields are overwritten or merged.

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-plus-clause block, front-loaded with the write marker and the core action, with constraints and the endpoint trailing. Every clause carries information an agent needs.

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 two-parameter write tool with no output schema, it covers limits, consent policy, async semantics, and creation behavior, which is enough to call it correctly. The unstated merge/overwrite behavior on existing contacts is the remaining hole.

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?

Top-level schema coverage is effectively absent (no description on list_id or contacts), so the description carries the load by stating each contact needs an email or a phone and that at most 100 are accepted. The endpoint path also clarifies that list_id is the target list.

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

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

The description names a specific verb and resource ('add one or more contacts to a list') and scopes it with a hard limit of 100. The front-loaded 'WRITE:' marker plus the endpoint 'POST /lists/{listId}/contacts' makes it unambiguous versus siblings like sendlane_add_contact_tags or sendlane_remove_contact_from_list.

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

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

It gives a clear positive-use condition ('Only add people who agreed to receive marketing') and resolves the main ambiguity by stating that non-existent contacts are created rather than erroring. It does not name a sibling alternative or an explicit when-not-to-use case, so it stops short of a 5.

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

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

Annotations already declare this is a write (readOnlyHint=false), destructive, idempotent, and open-world, so the description's 'WRITE:' prefix largely restates structured data. It does add two useful facts not in annotations: the exact endpoint path and the constraint that only pre-existing tags can be attached. It omits permission needs, the maxItems=100 limit, and partial-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?

Two sentences with zero filler; the write nature and the target endpoint are front-loaded ahead of the qualifier about existing tags. Nothing could be removed without losing information.

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

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

With only two params, rich annotations, and no output schema, the definition is minimally sufficient. However, for a destructive write tool it leaves gaps: no note that tags must be fetched via sendlane_list_tags, no mention of the batch limit or idempotent overwrite semantics that a caller would want before invoking it.

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 0%, so the description must carry parameter meaning. It conveys that tag_ids accepts one or more tags and that a contact is targeted, matching both params conceptually, but it never says these are integer IDs, where to obtain them, the 1-100 count bounds the schema enforces, or which field is contact_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 verb and resource ('put one or more existing tags on a contact') and even names the HTTP operation, so the action is unambiguous. The qualifier 'existing' implicitly distinguishes it from sendlane_create_tag, though it does not explicitly name that sibling or sendlane_remove_contact_tag.

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 word 'existing' hints that a tag must already be created (routing to sendlane_create_tag) before this tool can be used, which is useful implied guidance. There is no explicit when-to-use framing, no exclusion of the remove/get tag siblings, and no statement of prerequisites such as required contact ID origin.

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 'WRITE' label and 'not idempotent' note restate readOnlyHint=false and idempotentHint=false, but the concrete consequence ('calling it twice makes two lists') and the endpoint (POST /lists) do add usable context. It does not explain the destructiveHint=true implication or what the call returns, so it adds only modest value over the annotations.

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

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

Three tight fragments, front-loaded with the operation type and immediately followed by the idempotency caveat and endpoint. No filler sentences; every clause carries information.

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

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

For a simple 2-parameter create tool with complete annotations and no output schema, the essentials (write, non-idempotent, endpoint) are covered, but the parameters are entirely undocumented and the return behavior is unaddressed, leaving a modest 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 0% and the description never mentions the two parameters (name, description). It doesn't clarify that 'name' is the required identifier of the new list or any constraints, so the schema carries all 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 precise verb+resource ('create an audience list') that is unambiguous against siblings like sendlane_update_list, sendlane_get_list, and sendlane_list_lists. The 'audience' qualifier further separates it from the tag-related create tool (sendlane_create_tag).

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, preconditions, or alternative routing is provided. It doesn't tell the agent how this relates to sendlane_add_contacts_to_list or when to prefer updating an existing list via sendlane_update_list, so usage must be inferred entirely from the name.

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=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the 'WRITE:' prefix is largely redundant with structured data. The description adds the endpoint (POST /tags) but nothing about consequences, such as what happens if the tag already exists given idempotentHint=false, or auth/rate-limit requirements.

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

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

Two short sentences, zero padding, with the write-nature of the operation front-loaded. The brevity is structurally sound, though it edges toward under-specification rather than tight conciseness.

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

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

For a single-parameter create tool with no output schema, the annotations cover the safety profile, so the description is minimally adequate. It still omits the one thing an agent would want: how create_tag differs from the tag-association siblings and what happens on duplicate names.

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?

One parameter with 0% schema description coverage, but the schema does constrain it (required string, 1-255 chars). The description contributes nothing to parameter meaning beyond implying the value is a tag name; it does not say whether names must be unique or how they are normalized.

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: 'create a contact tag.' The agent knows this creates a tag entity. However, the phrasing 'contact tag' is ambiguous next to the sibling sendlane_add_contact_tags, which attaches an existing tag to a contact; the description never clarifies that this tool creates the tag itself rather than associating one.

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 mention of alternatives. With siblings like sendlane_add_contact_tags and sendlane_get_tag in the namespace, the agent gets no help deciding when this specific tool applies versus those.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing behavioral beyond restating the HTTP route: no mention of auth requirements, not-found/404 behavior, or rate limits. Raw endpoint syntax is the only added detail.

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 fragments, front-loaded, with no filler. It is appropriately sized for a simple read tool, though the second fragment is essentially raw HTTP metadata that adds little for an agent.

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 tool with no output schema, the description does not describe the returned campaign shape or any error conditions an agent should anticipate. Safety is covered by annotations, but the retrieval contract is under-specified.

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 0% for the single required campaign_id parameter. The description's 'by id' merely echoes the parameter name and adds no format, source, or validity context (e.g., where the id comes from, what happens for an unknown id). With 1 non-trivial parameter, the description fails to compensate for the schema 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?

The fragment 'One email campaign by id' identifies the resource (a single email campaign) and the retrieval key, which is clearer than a bare restatement of the name. However, it never states the verb explicitly and offers no differentiation from near siblings like sendlane_list_campaigns or sendlane_get_campaign_report, so an agent must infer singular-vs-list behavior.

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

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

There is no when-to-use or when-not-to-use guidance. Nothing tells the agent to prefer this tool over sendlane_list_campaigns for bulk retrieval, or how it differs from sendlane_get_campaign_report for reporting data. Usage is only implied by the name.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the metric inventory and the endpoint path, but omits notable behavior: what period is used when from/to are omitted, and whether unsent campaigns error. Useful but incomplete beyond structured 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?

Three tight sentences with the metric list front-loaded, followed by the period constraint and the endpoint. No filler; the REST path is the only mildly expendable element, but it does anchor the resource semantics.

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

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

With no output schema, the description carries the burden of describing returns and does so by enumerating every metric. For a 3-parameter read tool this is nearly sufficient; the main gap is undefined default period behavior when the optional from/to pair is omitted.

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 67%: from/to are well documented in the schema (ISO 8601 with timezone, to 'needs from'), while campaign_id has no schema description at all. The description only restates that from/to limit the period and implies campaign_id via the endpoint path, so it does not fully compensate for the undocumented required parameter.

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 ('Statistics of one email campaign') and enumerates the exact metrics returned, which is far more useful than a tautology. It implicitly separates itself from sendlane_get_campaign (details, not stats) and sendlane_get_sms_report (SMS vs email) by scoping to 'email campaign', but never names or contrasts a sibling explicitly.

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

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

The only usage signal is 'from/to limit the period', which describes parameter behavior rather than when to choose this tool. There is no guidance on when to prefer it over sendlane_get_campaign or sendlane_get_sms_report, and no mention of prerequisites such as the campaign having been sent.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuine value beyond that by scoping exactly what data comes back (lists, tags, custom fields, consent, lifetime value, subscribed/suppressed state), which is meaningful since no output schema exists.

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

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

Two tight sentences with no filler; the payload contents are front-loaded before the endpoint reference, so nothing has to be skimmed past.

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

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

With no output schema, the description carries the burden of describing return contents and does so concretely. It is nearly complete for a single-record read; only error/not-found behavior is unaddressed, which is minor.

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 0% and the single contact_id parameter carries no description, but its name and integer type make it self-evident. The phrase 'by id' confirms identity lookup but adds no format, range or lookup-failure semantics 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 (get) and resource (one contact) keyed by id, which clearly separates it from the sibling sendlane_list_contacts. It does not explicitly name the sibling it is the singular counterpart to, so it stops 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?

Usage is implied: the enumeration of lists, tags, custom fields, consent and subscription state suggests this single call can replace the narrower sendlane_get_contact_tags / sendlane_get_contact_subscriptions calls, but the description never says so outright and gives no when-not conditions.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description contributes nothing behavioral beyond restating the HTTP path: no mention of pagination semantics, result shape, empty-field handling, or permission requirements.

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

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

It is short and front-loaded with no filler, but the second sentence is a raw endpoint path that adds little beyond what the name and annotations already convey, and the whole text is a fragment rather than a complete statement of behavior.

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 a 3-parameter tool where contact_id is undocumented, the description would need to explain the return content (which custom fields come back, pagination shape). It does none of this, leaving the agent to infer everything from the name and 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 67%: page and limit are documented in the schema, while contact_id has no description anywhere. The description adds no syntax, format, or meaning for any parameter, so it does not compensate for the contact_id gap or explain pagination behavior.

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

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

The description names a specific resource and scope ('The custom field values of one contact') plus the underlying endpoint, so an agent can tell it apart from sendlane_list_custom_fields (definitions) and sendlane_set_contact_custom_fields (write). It is a noun phrase rather than a verb-led sentence, but the GET endpoint supplies the implied action.

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 sendlane_get_contact, sendlane_get_contact_tags, or sendlane_set_contact_custom_fields. The 'one contact' scoping implies it needs a single contact id, but no conditions, prerequisites, or alternatives are stated.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true and destructiveHint=false, so safety is covered. The description adds value by listing what the response contains (subscription list, state, attribution, timestamp), but says nothing about pagination, ordering, or auth requirements.

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

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

Two short elements, the resource summary front-loaded followed by the endpoint path. No wasted sentences, though the phrasing 'The list subscriptions of one contact' is slightly awkward.

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?

A simple single-parameter read-only getter with annotations covering the safety profile and a description covering the return shape; nothing an agent critically needs is missing. Pagination/ordering details would be the only marginal addition.

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 0%, but there is only one required parameter and the description supplies its identity via the GET /contacts/{contactId}/subscriptions path. It adds no format, constraint, or sourcing guidance beyond what the schema type already conveys.

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 (get/list) and resource (subscriptions of one contact), and even enumerates returned fields (list, subscribed/suppressed state, who added it and when). This distinguishes it from siblings such as sendlane_get_contact_tags and sendlane_get_contact_custom_fields, though it does not name those alternatives explicitly.

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

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

There is no when-to-use guidance, no condition for choosing this over sendlane_get_contact or the other per-contact getters, and no prerequisites stated. Usage is only implied by the resource name.

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, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds nothing behavioral on top of that: it never mentions that results are paginated or that page/limit control the traversal, which is the one behavior an agent actually needs here.

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?

It is short and front-loaded, but the second sentence merely restates the HTTP route already implied by the tool name, which is space that could have carried pagination or return-shape 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?

With no output schema and a paginated endpoint, the description should at least note that the reply is pageable and how to advance. Instead it leaves the agent to reverse-engineer pagination behavior from the parameter descriptions alone.

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

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

Schema description coverage is 67%: page and limit are documented in the schema, while contact_id carries no description but is self-evident from the endpoint. The description contributes no additional parameter meaning, so it sits at the baseline.

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

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

The description names the exact resource ('the tags on one contact') and pins it to a concrete endpoint, so an agent knows this returns tags for a single contact. It does not, however, distinguish itself from the adjacent sendlane_list_tag_contacts, which traverses the same relationship in the opposite direction.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no routing to alternatives such as sendlane_get_contact or sendlane_list_tags. The endpoint path is the only contextual clue.

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, destructiveHint=false, and openWorldHint=true, covering the safety profile. The description adds nothing beyond the safety information already structured — no note on pagination, missing-list errors, or the shape of a returned list.

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

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

Two short fragments, front-loaded with the resource before the endpoint. It earns its place without padding, though the second sentence is largely a restatement of the operation as a path.

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 one simple read parameter and annotations covering safety, the description is minimally adequate. However, with no output schema it says nothing about what a returned list contains or how failures surface, leaving gaps an agent would want covered.

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

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

Schema description coverage is 0%, so the schema supplies no meaning for list_id. The description partially compensates by saying retrieval is 'by id,' implying list_id is the identifier, but adds no detail on its integer/positive constraint or behavior for invalid ids.

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

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

States a specific resource and scope: 'One audience list by id,' which clearly contrasts with the plural sibling sendlane_list_lists. The verb is only implied ('GET'), so it falls short of the crisp verb+resource phrasing that earns 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?

Gives no when-to-use guidance and names no alternative. An agent must infer that this is for fetching a single known list versus sendlane_list_lists for enumeration; nothing in the text says so.

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, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds useful context by naming the metric set the report returns and the underlying endpoint, but says nothing about auth requirements, rate limits, or behavior for a missing/invalid message_id.

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

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

Three short, front-loaded sentences with no padding; the metric list comes first and the period constraint follows. The trailing endpoint string is mildly redundant but cheap.

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 metric enumeration is valuable, but the description is thin for a report tool: it omits whether results are aggregated or per-event, and leaves the required message_id entirely unexplained. Adequate but with clear gaps.

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

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

Schema coverage is 67% and the required message_id parameter has no schema description at all; the description only implies it via 'one SMS message' and gives no format or validity guidance. from/to are already well documented in the schema, and the description's 'limit the period' adds no meaning beyond that.

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

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

States a specific verb+resource ('Statistics of one SMS message') and enumerates the metrics returned, which makes it distinguishable from sendlane_get_campaign_report and sendlane_list_sms_messages by scope. It does not explicitly name a sibling, so it falls just 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?

The only guidance is 'from/to limit the period,' which is parameter behavior rather than when-to-use. There is no statement of when to prefer this over sendlane_get_campaign_report or sendlane_list_sms_messages, and no prerequisites.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description adds nothing beyond restating the HTTP route - no error behavior, auth requirements, or note on what happens for a nonexistent id - so it earns little credit against the already-low annotated bar.

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 fragments with zero padding, and the resource is front-loaded. However, the second fragment ('GET /tags/{tagId}') largely repeats information already conveyed by the name and the first fragment, and the extreme terseness reads as under-specification rather than tight 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 simple, read-only single-entity getter whose annotations cover safety and which has no output schema, the description is minimally sufficient. It still omits where tag_id comes from and any notion of behavior on a missing id, which would be cheap to add.

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 0% for the single required tag_id parameter, and the description only supplies the fragment 'by id'. It does not say where a tag id comes from (e.g., from sendlane_list_tags) or what format to expect, leaving the parameter effectively undocumented.

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

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

The description names the resource (a tag) and the retrieval scope ('one tag by id'), which distinguishes it from siblings like sendlane_list_tags and sendlane_create_tag without needing their schemas. The verb is only implied by the 'by id' phrasing, but an agent can still tell this is a single-item fetch.

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

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

It states what the tool returns but gives no context on when to call it instead of sendlane_list_tags or sendlane_get_contact_tags. No prerequisites, no exclusions, no routing guidance at all.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower. The description adds real value beyond that by disclosing the returned field set (id, name, status, scheduled/sent time, automation) and the underlying endpoint, which matters because no output schema exists.

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 two-fragment telegraphic description with zero filler, and the resource is front-loaded before the field list. It is terse to the point of being under-written, but nothing is wasted.

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

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

For a simple two-param read tool the description is minimally adequate: it identifies the resource and the return fields, partly compensating for the missing output schema. It omits pagination/result-size behavior and any filtering caveats, leaving the schema to carry 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% and both parameters (page, limit) are well documented in the schema, including the next_page chaining hint. The description adds nothing about parameters, 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?

The description names the resource (email campaigns) and enumerates the fields returned, so an agent can tell it apart from sendlane_get_campaign (singular) and the other list_* siblings like sendlane_list_lists or sendlane_list_tag_contacts. It lacks an explicit verb but the fields plus endpoint make the list semantics 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?

There is no guidance on when to use this versus sendlane_get_campaign (single campaign) or sendlane_get_campaign_report, and no mention of prerequisites, filters, or sorting behavior. The agent must infer usage entirely from the name and schema.

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, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description usefully adds the returned field set and the server-side time filter, but says nothing about pagination behavior, result caps, or rate limits beyond what the schema already spells out.

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 fragments that front-load the resource and its returned fields, then the filter, then the endpoint. No wasted sentences, though the telegraphic style trades a little readability for brevity.

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 four-optional-parameter read tool with full schema coverage, the description covers what is returned and how to filter, which is largely sufficient. It stops short of routing the agent among the many sibling list tools, which is the main completeness 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 from, to, page, and limit in detail (ISO 8601 format, defaults, the next_page convention). The description only echoes the from/to filtering, adding no semantics beyond the structured fields. Baseline 3 applies.

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

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

States a specific verb+resource (list all contacts of the account) and enumerates the fields returned (email, name, phone, lists, tags, custom fields, subscription state), plus the endpoint. It does not differentiate itself from close siblings like sendlane_list_list_contacts, sendlane_list_segment_contacts, or sendlane_list_unsubscribed_contacts, so the agent must infer the scope boundary itself.

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 only usage hint is 'Filter by creation time with from/to.' There is no statement of when to choose this over sendlane_get_contact (single record) or the scoped listers (list_list_contacts, list_segment_contacts, list_unsubscribed_contacts), and no exclusions or prerequisites are given.

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

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

Annotations already declare the safe read profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the description need not restate safety. It adds that the payload carries id/name/type and cites the underlying GET /custom-fields endpoint, but says nothing about pagination behavior or result volume beyond what the schema implies.

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 fragments, front-loaded with what is returned, then the usage tip, then the endpoint. Nothing is padded, though the endpoint citation (GET /custom-fields) is arguably redundant for an agent.

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 correctly names the returned fields (id, name, type), covering the main gap. Pagination handling is only implied via the schema's next_page note, but for a simple two-param list tool this is close to 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% — both page and limit are fully documented in the schema, including the 'pass the previous reply's next_page' convention. The description adds no parameter detail, so the baseline 3 applies.

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

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

States the resource (custom contact fields of the account) and the fields returned (id, name, type), which is specific and actionable. It does not explicitly distinguish itself from the similarly named sendlane_get_contact_custom_fields sibling (per-contact values vs. account-level definitions), leaving that differentiation to inference.

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

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

The sentence 'Use the ids when setting field values' implies the workflow leading to sendlane_set_contact_custom_fields, which is useful routing. However, it never states when to prefer this over sendlane_get_contact_custom_fields, nor any exclusions or prerequisites.

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

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true), so the bar is lower; the description still adds real value by disclosing the shape of the payload returned (a field inventory) where no output schema exists. It omits pagination/rate-limit behavior, but those are covered by the schema's page/limit params.

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 fragments, zero padding, with the resource scope and the returned field inventory front-loaded. It could be marginally better structured as a sentence, but nothing wastes the agent's attention.

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, filter-and-paginate list endpoint with a fully documented parameter schema but no output schema, the description covers the missing piece (what fields come back). The only gap is the absence of explicit routing guidance to sibling list/segment/tag contact tools.

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

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

Schema description coverage is 80%, so the schema already documents from/to/page/limit with formats and defaults. The description adds only the list scoping implied by 'on one list' and no extra syntax or semantics beyond that; 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 states a specific verb+resource scope: contacts belonging to one list, and enumerates the returned fields (email, name, phone, subscription state, tags, custom fields, LTV). 'On one list' is enough to separate it from bulk-list siblings like sendlane_list_contacts and tag/segment variants, though it never names those alternatives explicitly.

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

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

Scope is implied by 'on one list', which hints that this is the list-scoped counterpart to a global contacts listing, but there is no explicit when-to-use/when-not statement and no named alternative among sendlane_list_contacts, sendlane_list_segment_contacts, sendlane_list_tag_contacts, or sendlane_list_list_unsubscribed.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the GET /lists endpoint and enumerated return fields, but says nothing about pagination behavior, which with 2 pagination params would be valuable.

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

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

A single compact sentence followed by the endpoint hint; front-loaded with the action and its return fields, 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?

Adequate for a simple read-only listing tool, but with no output schema the description could better cover pagination semantics and the default page/limit behavior, which agents need to iterate results correctly.

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

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

Schema description coverage is 100%, so both page and limit are fully documented in the schema. The description adds no pagination syntax or format 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?

Specific verb+resource ('List the audience lists of the account') and enumerates returned fields (id, name, description, status, created date), clearly distinguishing it from the sibling sendlane_get_list and sendlane_list_list_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?

Usage is implied by the listing nature, but there is no explicit when-to-use guidance or routing to alternatives like sendlane_get_list for a single list or sendlane_list_list_contacts for members.

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, destructiveHint=false and openWorldHint=true, so the safe-read profile is covered. The description adds only the endpoint path and no pagination, rate-limit, or result-shape context beyond what the schema's page/limit params already say.

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 fragments with zero filler, and the resource scope is front-loaded before the endpoint reference. The extreme terseness borders on under-specification rather than being genuinely tight, but nothing is wasted.

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

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

For a 5-parameter read tool with no output schema, the description omits what the response contains (contact fields, next_page linkage) and gives no disambiguation against the near-duplicate sibling. The schema carries most of the parameter burden, so this is adequate but with clear gaps.

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

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

Schema description coverage is 80%, with from/to/page/limit all documented inline in the schema, so the baseline of 3 applies. The description contributes nothing about parameter usage, such as the from/to pair dependency or pagination flow, that isn't already in 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 names a specific resource ('Contacts that unsubscribed from one list') and scopes it to a single list via the listId path, which implicitly distinguishes it from an account-wide unsubscribed listing. However it is a noun fragment with no verb, and it does not explicitly name the very similarly named sibling sendlane_list_unsubscribed_contacts, so an agent could still conflate the two.

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

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

There is no when-to-use or when-not-to-use guidance, and no mention of alternatives such as sendlane_list_unsubscribed_contacts or sendlane_list_list_contacts. The only context is the raw GET endpoint path, which tells the agent nothing about selection criteria.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the returned field set (id, email, name, phone) and the REST path, which is useful beyond the annotations, but it says nothing about pagination behavior or response size 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 compact clauses, front-loaded with what the tool returns and immediately followed by the endpoint. It is telegraphic but there is no wasted sentence; the only cost is that the terse style omits the surrounding context that would make it self-sufficient.

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 carry the return-field information, which is good. But for a paginated list tool in a family of four near-identical listing tools, it omits the routing guidance and pagination context an agent needs to select and iterate 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 67%: page and limit are well documented in the schema (including the 'next_page' continuation hint) while segment_id has no schema description. The description adds no parameter meaning of its own, so it neither helps nor harms beyond the schema baseline.

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

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

The description states a specific resource and scope ('contacts in one segment') and lists returned fields, so an agent can tell it differs from a generic contact listing. However, it never names the near-identical siblings (sendlane_list_list_contacts, sendlane_list_tag_contacts, sendlane_list_contacts) that share this exact shape, so the differentiation is left implicit in the word 'segment'.

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

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

There is no when-to-use guidance at all — no mention of when to prefer this over list_contacts, list_list_contacts, or list_tag_contacts. The endpoint fragment hints at the underlying resource but never states the conditions or prerequisites (e.g., that segment_id must come from list_segments).

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds the concrete return fields and endpoint path, but says nothing about pagination behavior, result ordering, or rate limits, which would be the valuable additions beyond the annotations.

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

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

A single compact sentence plus the endpoint, with the returned-field list front-loaded. No filler, though the endpoint string adds little beyond what the tool name already conveys.

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

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

For a zero-required-parameter list tool with full schema coverage and safety annotations, most needs are met, but the absence of output schema and of any pagination guidance in the description leaves an agent reliant on the schema alone. Adequate but with visible gaps.

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

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

Schema description coverage is 100% and both page/limit params are fully documented in the schema with defaults and ranges. The description contributes nothing about parameters, 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?

The description names the resource (segments of the account) and enumerates the returned fields (id, name, list, match rule, last count), plus the underlying endpoint GET /segments, so an agent knows exactly what this returns. The listing verb is only implied, and it does not distinguish itself from similarly named siblings like sendlane_list_segment_contacts or sendlane_get_list.

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

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

There is no when-to-use guidance, no statement of when to prefer this over sendlane_list_segment_contacts or sendlane_get_list, and no prerequisites mentioned. Usage is only inferable from the name and field list.

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, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds the field set and raw endpoint, which is useful but thin behavioral context; it says nothing about pagination defaults or response shape beyond 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?

A single terse line with zero waste, front-loading the returned fields. It reads as a fragment rather than a sentence, but nothing needs to be trimmed.

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 two-param read-only list with no output schema and full annotation and schema coverage, the description supplies enough to call it correctly. Only the absence of any return-format note (e.g. whether results are paginated envelopes) 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 description coverage is 100% and both page/limit are fully documented in the schema, including the next_page chaining hint. 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?

The description identifies the resource (sender profiles) and enumerates the fields each profile contains, so an agent knows exactly what it retrieves. The verb is implied rather than stated ('GET /senders'), and there is no competing sender-profile sibling to disambiguate against, so it lands at a clear but not standout 4.

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 statement of when to call this versus alternatives, no prerequisite context, and no exclusions. Among the many list_* siblings the agent gets no routing guidance at all.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that results span both campaign and automation SMS types and names the returned fields, which is useful context, but it says nothing about the raw HTTP endpoint behavior beyond 'GET /sms-messages'.

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 short and front-loads the resource, but it is a telegraphic fragment rather than well-formed prose, and mixing the endpoint path into the same breath adds little agent value. No wasted sentences, but no real structure either.

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 some burden for return shape; it partially discharges this by listing a few fields. It omits pagination/result-count behavior, though the schema's page/limit fields imply it, leaving the definition merely adequate.

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

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

Schema description coverage is 100%, with page and limit fully documented in the schema (including default and pagination chaining). The description adds no syntax or semantics beyond the structured fields, 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?

The description pins down the exact resource — SMS messages — and further narrows scope to campaign and automation types, then enumerates the returned fields (id, name, campaign status, automation). The verb is only implied (the name/title carry 'List'), so it isn't the full 'specific verb+resource' of a 5, but the resource is unambiguous relative to siblings like list_campaigns or list_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?

The description offers no when-to-use guidance, no preconditions, and no routing to alternative tools. There is no other SMS-message list sibling, but the agent still gets no statement of context or exclusions — it is left to infer intent entirely.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description adds only the HTTP route, which largely restates the name; it does not mention pagination behavior (next_page chaining), date-range filtering, or what the response contains. With annotations carrying the burden, this is adequate but thin.

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

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

Two short fragments with zero filler, and the scoping constraint is front-loaded. It errs toward under-specification rather than verbosity, so it is efficient without being wasteful.

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 paginated, date-filterable list tool with no output schema, the description omits the pagination contract and the fact that results are time-windowable, relying on the schema to surface both. Annotations cover the read-only safety profile, so the missing pieces are moderate rather than critical.

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 80%, so the schema already documents from, to, page, and limit in detail. The only undocumented parameter, tag_id, gets implicit meaning from 'one tag' and the {tagId} route, but the description adds no syntax or format detail beyond that. Baseline 3 is appropriate when the schema does the heavy lifting.

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

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

The description identifies the resource and scope ('Contacts that carry one tag') and the backing route (GET /tags/{tagId}/contacts), which makes the tag-filtered list operation unambiguous. However, it is a noun fragment without an explicit verb and never names the siblings it differs from (sendlane_list_contacts, sendlane_list_list_contacts, sendlane_list_segment_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?

There is no when-to-use guidance, no prerequisites, and no alternatives named. An agent must infer from the name that this is the tag-scoped counterpart to sendlane_list_contacts and sendlane_list_list_contacts, but nothing in the description says so.

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, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned field set, which is modestly useful, but says nothing about pagination semantics or total-count behavior even though the schema exposes page/limit.

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 short sentence with no padding; the resource and return fields are front-loaded. It is a noun phrase rather than a verb-led statement, but it wastes no space.

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 lists the returned fields, and the annotations carry the safety profile while the schema covers pagination. For a simple read-only list tool, little is missing beyond an explicit pointer to sibling tools.

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

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

Schema description coverage is 100% – both page and limit are documented in the schema with defaults and the next_page hint. The description adds nothing about parameters, 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?

Names the resource precisely (the account's contact tags) and even enumerates the returned fields (id, name, audience count), so an agent knows exactly what comes back. It does not, however, distinguish itself from near-siblings such as sendlane_get_tag or sendlane_list_tag_contacts, so an agent must infer the difference from names alone.

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

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

There is no when-to-use guidance, no exclusions, and no mention of alternatives. With siblings like sendlane_get_tag and sendlane_list_tag_contacts in the namespace, this omission is a real gap.

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, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond that — no disclosure of pagination behavior, result shape, or rate limiting — so it contributes no behavioral context of its own.

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 fragments with zero padding, and the resource scope is front-loaded ahead of the endpoint reference. It is terse to the point of under-specification, but nothing is wasted.

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

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

No output schema exists, so the description carries some burden for return behavior, and it says nothing about pagination fields (next_page) hinted at in the page parameter. With params fully documented in the schema and annotations covering safety, this is minimally adequate rather than 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%: from/to ISO 8601 ranges, page, and limit are all documented in the schema itself. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific resource and scope: contacts that unsubscribed from the account, with the backing endpoint GET /contacts/unsubscribed. This clearly separates it from sendlane_list_contacts, but it never explicitly contrasts with the sibling sendlane_list_list_unsubscribed, so the scope distinction remains inferable 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?

No when-to-use guidance, no prerequisites, and no mention of the near-identical sibling sendlane_list_list_unsubscribed (unsubscribes scoped to a specific list). The agent must infer account-wide vs list-scoped semantics on its own.

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=false, destructiveHint=true, and idempotentHint=true, so the safety profile is largely covered. The description still earns credit by disclosing the scope of destruction — the contact is removed from the list but preserved in the account — which is exactly the kind of consequence detail an agent needs before invoking a destructive write.

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

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

A single front-loaded sentence plus the endpoint template, with the WRITE marker and the containment clarification placed first. No filler and nothing redundant.

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

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

For a two-parameter destructive write with no output schema, the description plus annotations cover what is removed, what is preserved, and that the call is idempotent. Only parameter-level detail (ID formats, error behavior) is left entirely to the schema, which 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 description coverage is 0%, so the description carries the burden for both parameters but adds little: 'one contact from one list' only loosely maps to list_id and contact_id, and the endpoint template restates the same two identifiers without type, format, or constraint detail. The heavy lifting is left undone.

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 (remove one contact from one list) and immediately scopes it by clarifying the contact stays in the account, which separates it from siblings like sendlane_unsubscribe_contact and sendlane_remove_contact_tag. An agent can identify the operation 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?

The parenthetical '(the contact stays in the account)' implies this is a list-membership removal rather than an unsubscribe, which gives some contextual steering. However, it never explicitly names an alternative tool or states when to prefer this over unsubscribe_contact or remove_contact_tag, so the guidance remains inferred rather than stated.

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

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

Annotations already declare write/destructive/idempotent/openWorld, and the description adds real value beyond them: it clarifies that only the association is removed while the tag persists, which precisely scopes what 'destructive' means here. The 'WRITE:' prefix and HTTP verb reinforce the mutation without contradicting the annotations.

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

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

One front-loaded sentence beginning with 'WRITE:', followed by the endpoint. No filler; every element (operation class, action, scope caveat, route) 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 two-parameter mutation with no output schema, the description covers the operation class, effect, scope caveat, and endpoint, which is nearly everything an agent needs. Return-value behavior is unspecified, but no output schema exists and none is strictly required for a simple untag 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 coverage is 0%, so the description must compensate. The endpoint template 'DELETE /contacts/{contactId}/tags/{tagId}' does map the two integer parameters to their roles (contact and tag), adding meaning the bare schema lacks, but it provides no format or constraint detail beyond that.

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

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

States a specific verb and resource ('remove one tag from a contact') and the parenthetical '(the tag itself is kept)' clarifies the exact scope, distinguishing it from a tag-deletion operation or from the sibling add_contact_tags. It stops short of naming a sibling directly, but the operation is unambiguous.

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

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

The parenthetical implies the boundary against deleting the tag itself, giving some usage context, but there is no explicit when-to-use vs alternatives guidance or prerequisites (e.g. re-adding a tag, or how it compares to sendlane_remove_contact_from_list). Usage is only implied.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=true, and openWorldHint=true, so the safety profile is covered structurally. The description adds the POST endpoint and the field-id source, but does not disclose what 'add' does to pre-existing values despite destructiveHint=true, leaving the key behavioral question open.

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 fragments, each earning its place: the action marker, the id source, and the HTTP target. Front-loaded with 'WRITE:' so the mutating nature is the first thing read.

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 destructive, open-world POST with no output schema and 0% schema coverage, the definition covers the endpoint and id provenance but omits what happens to existing field values and any response behavior. Adequate but with a real gap on the destructive semantics.

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 0%, so the description must compensate but only partially does: it explains where the custom-field 'id' values come from. It says nothing about contact_id, the value format/limits, or the array bounds, leaving most of the parameter surface undocumented.

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: 'add custom field values to a contact', and the 'WRITE:' marker distinguishes it from the read siblings get_contact_custom_fields and list_custom_fields. It is clear, though the phrasing 'add' is slightly at odds with the tool name 'set', so the agent must infer whether values merge or overwrite.

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?

Routes the agent to sendlane_list_custom_fields for obtaining field ids, which is genuinely useful prerequisite guidance. However, it never states when to prefer this over get_contact_custom_fields or add_contact_tags, so usage is only implied.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true, openWorldHint=true, and readOnlyHint=false, so the safety profile is fully structured. The description adds genuine behavioral context by stating the outcome ('the contact stops receiving campaigns'), but says nothing about reversibility, permissions, or re-subscription.

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 with a 'WRITE:' marker, then the effect, then the endpoint — three tight clauses with no filler. The endpoint line is mildly redundant but does anchor the operation.

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

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

For a single-parameter mutation whose annotations already cover the safety profile and which has no output schema, the description supplies purpose, impact, and endpoint. Only the return value and error/permission behavior are absent, which is acceptable at this complexity.

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 0% and the schema adds only numeric bounds, so the description must carry param meaning. It conveys that contact_id is a path identifier via the POST /contacts/{contactId}/unsubscribe template, but adds no format or sourcing detail beyond that.

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

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

States a specific verb and resource ('unsubscribe one contact from email marketing') with the scope narrowed to a single contact, and even names the underlying endpoint. No sibling offers unsubscribing, so the agent can identify the intended action immediately.

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

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

Usage is implied by the description ('unsubscribe one contact'), and it clarifies email-marketing scope, but it never states when to use this versus related tools like sendlane_remove_contact_from_list or when not to unsubscribe. No prerequisites or alternatives are given.

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

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

Annotations flag destructiveHint=true but cannot say what is destroyed; the description explicitly warns that 'an omitted description may be cleared', which is exactly the destructive mechanism an agent must know before calling. It also discloses the required-field constraint and the PUT (full-replace) semantics, adding real context beyond the annotations.

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

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

A single dense sentence, front-loaded with the WRITE classification and the most consequential semantic (the possible clearing of description), with the endpoint as a trailing reference. 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?

For a mutation tool with no output schema, the description supplies the essential behavioral facts: write nature, required name, full-replace semantics, and the destructive description clearing. It stops short of naming the target list parameter explicitly or noting permission/idempotency implications, though idempotentHint already covers the latter.

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 0%, so the description must carry parameter meaning, and it does: name is required, description is optional and destructive when omitted. The list_id target is conveyed only indirectly via the PUT path template, leaving its role slightly implicit.

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

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

The description names a specific verb+resource ('rename a list and/or change its description') and pins down scope with 'a full update', which separates it from sendlane_create_list and sendlane_get_list. An agent can identify the operation without opening the schema.

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

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

Usage is implied by the 'WRITE' prefix and PUT semantics, which suggest updating an existing list, but no sibling is named and no when-not condition is given. Nothing tells the agent why to prefer this over create_list or get_list for a given intent.

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