Read subscribers, groups, campaigns, fields, segments, automations, webhooks; safe additive writes.
The last two health checks of this connector failed. If this server requires authentication, missing or expired test credentials may be the cause. A test profile lets Glama authenticate for health checks and discover tools; it is separate from your personal connections.
If you are the author, claim ownership, then add or update a test profile under Admin → Test Profile.
Scored across 13 tools
Each tool targets a distinct resource and action. The potentially confusable pair (list_groups vs list_group_subscribers, list_subscribers vs list_group_subscribers) is clearly differentiated by the resource scoping and descriptions. No two tools appear to do the same thing.
All 13 tools follow a strict mailerlite_verb_noun snake_case pattern (list_*, get_*, create_*, assign_*, upsert_*). The convention is applied uniformly across reads and writes with no deviations.
13 tools is well within the sweet spot for a MailerLite integration. The count is justified by the breadth of read resources plus a few mutations, with no obviously redundant or filler tools.
Coverage is heavily read-biased: lists for campaigns, automations, fields, segments, and webhooks exist with no create/update/delete counterparts. Core subscriber flows work (upsert, assign, list), but notable gaps remain—no unassign/remove_from_group, no delete subscriber, and no get_group.
Adds a subscriber to a group (additive membership). MailerLite API: POST /subscribers/{subscriber_id}/groups/{group_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| group_id | Yes | Group id. | |
| subscriber_id | Yes | Subscriber id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation supplies destructiveHint=true, so the safety profile is partly covered. The description adds genuinely new context beyond the annotation: '(additive membership)' tells the agent existing group memberships are not removed, which sharpens the picture against a blanket destructive hint, and the POST endpoint is disclosed. It still omits idempotency (what happens if the subscriber is already in the group), auth requirements, and side effects such as notifications.
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 clauses with the mutation semantics front-loaded before the API detail. Every phrase earns its place and there is no filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a two-parameter mutation with no output schema and only a destructiveHint annotation, the description covers purpose and additive semantics adequately but leaves idempotency, error behavior for invalid ids, and permission requirements unstated. It is workable but not complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both subscriber_id and group_id are already documented in the schema. The endpoint template restates their roles in path order but adds no format, prefix, or validation detail beyond what the schema provides, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb and resource ('Adds a subscriber to a group'), which unambiguously separates it from the read-only siblings like mailerlite_list_group_subscribers or mailerlite_get_subscriber. The MailerLite endpoint template confirms exactly which resource pair is mutated.
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 explicit when-to-use or when-not-to-use statement, and no named alternative (e.g., mailerlite_upsert_subscriber, which can also carry group membership). The parenthetical 'additive membership' hints at the intended semantics but usage conditions must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates a subscriber group/list (additive). MailerLite API: POST /groups.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Name of the new group. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With only a title and destructiveHint=true in annotations, the description contributes the API endpoint (POST /groups) and the "additive" nature of the operation, which is useful risk context. It omits permissions/auth requirements, duplicate-name behavior, and what is returned — meaningful gaps for a creation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two compact sentences, front-loaded with the operation and scoped by the additive qualifier; the API endpoint is a useful terse addendum. Nothing is padded, though the sentence fragment style is minimal rather than rich.
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 creation tool with no output schema, the description covers what the tool does and its additive character. It leaves unanswered what the agent gets back and what happens on a name collision, which a create operation should ideally address.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There is one parameter with 100% schema description coverage, so the schema already documents "name" fully. The description adds no format, constraint, or uniqueness detail beyond that, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: "Creates a subscriber group/list," which is unambiguous against siblings like mailerlite_list_groups or mailerlite_assign_subscriber_to_group. It does not explicitly name or contrast an alternative, but the verb+resource pairing alone is enough for correct selection.
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 "(additive)" implies this adds a new group rather than modifying an existing one, which is a mild usage signal, but there is no explicit when-to-use, no exclusions, and no pointer to alternatives such as mailerlite_assign_subscriber_to_group. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single campaign by id. Read-only. MailerLite API: GET /campaigns/{campaign_id}.
| Name | Required | Description | Default |
|---|---|---|---|
| campaign_id | Yes | Campaign id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and 'Read-only' in the description merely restates that. The one genuinely additive piece is the underlying API mapping (GET /campaigns/{campaign_id}), which gives the agent endpoint-level context, but nothing is said about not-found/error behavior beyond that.
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 clauses with zero filler, and the core purpose is front-loaded in the first sentence ahead of the read-only note and endpoint reference.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a single-parameter read tool with annotations covering the safety profile and no output schema to explain, this is essentially complete: it states what it returns (a campaign), how to identify it (id), and the backing API endpoint. Only minor gaps, such as error behavior, remain.
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% with a single parameter ('Campaign id.'), so the schema fully documents the input. The description's 'by id' adds no format, source, or constraint detail beyond it, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Fetch a single campaign by id'), and the 'single ... by id' phrasing implicitly separates it from the sibling mailerlite_list_campaigns. It stops short of naming the alternative explicitly, but an agent can tell a by-id fetch from a list without opening either schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied by the fact that the tool takes a single campaign_id, so it is clearly the by-id lookup as opposed to a listing. However, there is no explicit statement of when to use this vs mailerlite_list_campaigns, and no mention of prerequisites such as the campaign having to exist.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch a single subscriber by id or email address. MailerLite API: GET /subscribers/{id}.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Subscriber id OR email address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered. The description adds the dual lookup key (id or email) and the underlying API path, which is useful context, but does not describe error behavior (e.g., not found) or return format.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the action and lookup keys, with no filler. The API endpoint line is slightly redundant but harmless.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only, single-param tool with full schema coverage, the description covers purpose, lookup keys, and endpoint. Missing only edge-case behavior like not-found handling, which is minor here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the schema already documents 'id' as accepting an id OR email. The description's mention of 'id or email' is redundant with the schema. Baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (Fetch) and resource (a single subscriber), and clarifies the singular scope distinguishing it from mailerlite_list_subscribers. The API endpoint reference adds precision.
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 singular 'single subscriber' phrasing implies this is for one-record retrieval versus the list sibling, but there is no explicit when-to-use guidance or named alternative. Usage is inferable but not stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List automations (workflows), optionally filtered by enabled state. Page-paginated. MailerLite API: GET /automations.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (page-based pagination). | |
| limit | No | Max automations per page (default 25). | |
| filter_enabled | No | Filter by enabled state (→ filter[enabled]). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The readOnlyHint annotation already communicates this is a safe read operation. The description adds useful context that results are page-paginated and the underlying API endpoint, but doesn't describe return format, pagination limits, or behavior when no results exist.
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 zero waste. The purpose, optional filter, pagination, and API mapping are all communicated efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only list tool with full schema coverage and a readOnlyHint annotation, the description is nearly complete. It could mention the response structure or pagination metadata, but the core calling information is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents all three parameters thoroughly, including defaults and the filter mapping. The description adds only a brief mention of optional enabled-state filtering, not meaningfully beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List automations (workflows)') and clarifies terminology by equating automations with workflows. It doesn't explicitly differentiate from siblings like list_campaigns or list_segments, but the resource name is distinctive enough.
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 mentions an optional enabled-state filter, which implies a usage scenario, but provides no explicit when-to-use or when-not-to-use guidance versus sibling list tools. Usage is 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.
List campaigns, optionally filtered by status. Page-paginated. Read-only — this server does NOT send campaigns. MailerLite API: GET /campaigns.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (page-based pagination). | |
| limit | No | Max campaigns per page (default 25). | |
| status | No | Filter by status (→ filter[status]): sent | draft | ready. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, but the description adds meaningful context beyond that: it explicitly rules out sending campaigns from this server, which is a genuinely useful behavioral boundary an agent could otherwise get wrong. It also discloses page-based pagination. It stops short of describing result size, ordering, or error behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short, front-loaded statements with no filler; the key scoping fact (read-only, does not send) appears early. The trailing 'MailerLite API: GET /campaigns' is marginally useful for grounding the endpoint but is the least load-bearing sentence, keeping this just shy of a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple three-parameter, zero-required list tool with full schema coverage and readOnlyHint already set, the description covers purpose, pagination, safe-read behavior, and the send boundary. With no output schema present, nothing further is strictly needed for an agent to call this 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%, and the schema already documents page semantics, the default limit of 25, and the status enum values with the underlying filter[status] mapping. The description only restates pagination and status filtering at a high level, adding no syntax or format detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List campaigns') and adds a scope clarification ('this server does NOT send campaigns'), which separates it from send-oriented operations. It does not, however, explicitly contrast itself with the closest sibling, mailerlite_get_campaign (single vs. collection), so sibling differentiation is only partial.
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?
'Optionally filtered by status' implies the usage context for the filter parameter, and the read-only note implies when to reach for this tool. There is no explicit when-to-use or when-not-to-use guidance, nor any routing to mailerlite_get_campaign for a single campaign, 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.
List custom/default subscriber fields, optionally filtered by type or keyword. Page-paginated. MailerLite API: GET /fields.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (page-based pagination). | |
| type | No | Filter by field type (→ filter[type]): text | number | date. | |
| limit | No | Max fields per page (default 25). | |
| keyword | No | Filter by keyword (→ filter[keyword]). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotation already declares readOnlyHint=true, so the safety profile is covered. The description adds that the result set is page-paginated and discloses the underlying endpoint (GET /fields), which is modest extra context but no detail on default page size, ordering, or total counts.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, zero filler, and the resource plus its optional narrowing are front-loaded before the pagination and endpoint notes.
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 paginated list tool, the description plus the readOnlyHint annotation and fully-documented schema give an agent everything needed to call it. It does not mention return shape, but with no output schema that is a minor omission for a simple list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so page, limit, type and keyword are all documented in the schema, including the filter[...] mapping and the type enum values. The description only restates the filtering idea, adding no syntax or format meaning 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 (list) and resource (custom/default subscriber fields), plus what the returned set can be narrowed by. The resource is clearly distinct from siblings like list_groups, list_segments and list_subscribers, though no sibling is named as an alternative.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'optionally filtered by type or keyword' implies when the filters are useful, but there is no explicit when-to-use vs when-not, no prerequisite or scope guidance, and no named alternative among the many list_* siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List subscriber groups/lists, optionally filtered by name. Page-paginated. MailerLite API: GET /groups.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Filter by name (→ filter[name]). | |
| page | No | Page number (page-based pagination). | |
| sort | No | Sort field, e.g. name, total, -total, created_at. | |
| limit | No | Max groups per page (default 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds that results are page-paginated and maps to GET /groups, but pagination is also conveyed in the schema's page parameter, so the incremental disclosure is modest and return shape is not described.
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 clauses with the operation and scope front-loaded, then pagination and the backing endpoint. No filler and nothing buried.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read-only list tool with full schema coverage and no output schema, the description covers purpose, optional filtering, and pagination adequately. Only minor gaps remain, such as the default sort order or total-result behavior.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so all four parameters (name, page, sort, limit) are already documented in the schema. The description's only added semantic is that name filtering is optional, which the schema implies; baseline 3 applies when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('List subscriber groups/lists') and notes the optional name filter. It is clearly distinguishable from create_group or assign_subscriber_to_group, though it does not explicitly differentiate itself from list_segments or list_group_subscribers, which sit in the same family.
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?
'Optionally filtered by name' implies when the filter applies, but there is no explicit when-to-use guidance, no mention of alternatives such as list_group_subscribers for group membership, and no stated prerequisites or auth context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the subscribers belonging to a group, optionally filtered by status. Cursor-paginated. MailerLite API: GET /groups/{group_id}/subscribers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max subscribers per page (default 25, max 100). | |
| cursor | No | Pagination cursor from a previous response's meta.next_cursor. | |
| status | No | Filter by status (→ filter[status]). | |
| group_id | Yes | Group id. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already grant readOnlyHint=true, so the safety profile is covered. The description adds genuine behavioral context beyond that: cursor-based pagination and the underlying API endpoint GET /groups/{group_id}/subscribers, which tells the agent how results are retrieved. It still omits rate limits or return shape, hence 4 rather than 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three terse sentences, front-loaded with the core purpose, followed by pagination behavior and the API reference. Every sentence carries information; nothing is padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
There is no output schema, but the description flags cursor pagination and the meta.next_cursor convention is documented in the schema, so an agent knows how to iterate. Combined with the readOnly annotation, this is sufficient for a filtered list tool, though return-field details are absent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents limit, cursor, status, and group_id. The description only echoes the status filter and pagination, adding no syntax or format detail beyond the schema. 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 and resource ("List the subscribers belonging to a group") and scopes it narrowly enough to distinguish it from mailerlite_list_subscribers, which lists subscribers globally. The optional status filter is also named. It stops short of naming the sibling alternative explicitly, so it is not a full 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 description implies usage (list group members, optionally filtered by status) but never states when to choose this over mailerlite_list_subscribers or mailerlite_list_groups. No prerequisites or exclusions are given, leaving the agent to infer routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List segments. Page-paginated. MailerLite API: GET /segments.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (page-based pagination). | |
| limit | No | Max segments per page (default 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
readOnlyHint=true already tells the agent this is a safe read, so the bar is lower. The description adds that results are 'Page-paginated' and cites the underlying API endpoint (GET /segments), which is modestly useful behavioral context, but it does not disclose anything about result ordering, filtering, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three terse fragments, front-loaded with the operation, and every sentence carries some information (pagination behavior, API mapping). It avoids padding but is close to under-specification rather than elegant 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 read-only, two-optional-parameter listing tool with 100% schema coverage, the description is minimally adequate. However, with no output schema, it says nothing about what is returned (segment shape, total counts), leaving that gap unaddressed.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and both page/limit are fully documented in the schema, so the baseline of 3 applies. The description adds no meaning beyond the schema, merely confirming that pagination is page-based.
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 segments' precisely names the operation and the resource being listed. It is distinguishable from sibling list tools (list_groups, list_fields, list_campaigns) by resource alone, though it makes no explicit contrast between them.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no when-to-use, when-not-to-use, or alternative guidance. The statement 'List segments' is essentially a restatement of purpose, so an agent gets no help deciding between this and sibling listing tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List subscribers, optionally filtered by status. Cursor-paginated. MailerLite API: GET /subscribers.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max subscribers to return per page (default 25, max 100). | |
| cursor | No | Pagination cursor from a previous response's meta.next_cursor. | |
| status | No | Filter by status (→ filter[status]): active | unsubscribed | unconfirmed | bounced | junk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so safety is covered and the description's bar is lower. The description does add the pagination model ('Cursor-paginated') and the underlying endpoint, which is genuinely useful context, but it says nothing about rate limits, ordering, or the shape of the result envelope.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three short sentences, front-loaded with what the tool lists and its filter, followed by pagination and endpoint metadata. Nothing is padded or 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?
With no output schema, the description partly compensates by disclosing cursor pagination, and all three parameters are documented in the schema. It stops short of describing the response payload (subscriber fields, meta cursor location), which an agent stitching pages might want.
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%: limit, cursor, and status are each fully documented in the schema, including enum values and the filter[status] mapping. The description's 'optionally filtered by status' merely restates the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List subscribers') plus an optional filter, so the agent immediately knows this is the account-wide subscriber read. It does not, however, differentiate itself from siblings like mailerlite_get_subscriber (single) or mailerlite_list_group_subscribers (scoped list), which an agent would have to infer.
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?
'Optionally filtered by status' implies the filtering use case, which is the only guidance given. There is no statement of when to prefer this over get_subscriber or list_group_subscribers, and no prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List configured webhooks. Page-paginated. MailerLite API: GET /webhooks.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number (page-based pagination). | |
| limit | No | Max webhooks per page (default 25). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds two pieces of behavioral context beyond the annotations: that results are page-paginated and the underlying endpoint (GET /webhooks). It does not describe defaults, ordering, or empty-result behavior, so it 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?
Three short fragments with zero waste, and the core purpose is front-loaded in the first sentence. The endpoint note is slightly redundant with the tool name but is cheap and useful for tracing to the API.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only paginated list with no output schema and 0 required parameters, the description covers the essentials: what it returns, that it paginates, and which API call it maps to. Nothing an agent needs in order to invoke it correctly is missing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so page and limit are already fully documented in the schema, and the baseline is 3. The description's 'Page-paginated' note reinforces the pagination model but adds no syntax or default detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List configured webhooks'), which is unambiguous and distinguishes it from the other list_* siblings that target different resources (groups, campaigns, subscribers). It stops short of explicitly naming a sibling, but the resource is narrow enough that confusion is unlikely.
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 gives no when-to-use or when-not-to-use guidance and names no alternatives; the agent must infer that this tool is the only webhook-listing option. It is a simple read tool so the risk is low, but no usage context is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Creates or updates a subscriber (upsert by email). Additive — does NOT send any email. MailerLite API: POST /subscribers.
| Name | Required | Description | Default |
|---|---|---|---|
| Yes | Subscriber email address (upsert key). | ||
| fields | No | Custom/default field values keyed by field key, e.g. { name, last_name, company }. | |
| groups | No | Group id strings to add the subscriber to. | |
| status | No | Subscriber status: active | unsubscribed | unconfirmed | bounced | junk. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply destructiveHint=true, so the description must carry the rest. It does usefully disclose the POST endpoint and that no email/automation is triggered, but it does not explain what 'upsert' overwrites — whether existing custom fields or status are replaced or merged — which is the key question given destructiveHint=true. The word 'Additive' without qualification could also mislead, though the 'does NOT send any email' clause scopes it to side effects rather than data.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero padding; the core operation and its resolution key come first, followed by the side-effect caveat and endpoint. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a four-parameter upsert with no output schema, the definition covers the operation, the key, the endpoint, and the absence of email side effects. It falls short on overwrite/replacement semantics and on group assignment being available via the groups parameter, but no return-value documentation is required here.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% and the schema already documents email as the upsert key, fields, groups, and the status enum. The description adds nothing beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Creates or updates a subscriber') plus the resolution key ('upsert by email'), which is exactly the semantics an agent needs. It also distinguishes itself from the list/get siblings by naming the side effect it does not have ('does NOT send any email').
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 clarifies the create-or-update behavior and the no-email side effect, which is useful context, but it never says when to prefer this over mailerlite_get_subscriber, mailerlite_list_subscribers, or mailerlite_assign_subscriber_to_group, nor that group membership can be set here instead of via the assign tool. Usage is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read audiences, members, campaigns and reports; add, update, tag and archive subscribers.
Read lists, contacts, campaign stats; add contacts; draft, schedule and send campaigns and SMS.
Read Enginemailer subscribers, lists and campaigns; add subscribers, create and send campaigns.
Send email and read templates, marketing contacts, lists, stats, bounces and unsubscribes.
Add one secure layer between your agents and this server.