moosend

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

Annotations only supply destructiveHint=true; the description goes well beyond that by disclosing the upsert behavior, the destructive clearing of omitted custom fields, the re-subscription side effect on unsubscribed addresses, and a concrete rate limit. These are exactly the side effects an agent needs before invoking a write 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?

Tight, front-loaded sentences: the WRITE marker and the core action lead, side effects follow, and the endpoint/rate limit close it out. No sentence is 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 7-parameter mutation with no output schema, the description covers the critical side effects, the upsert semantics, and throttling. It leaves some ambiguity about interaction with the sibling update/unsubscribe tools, but nothing essential to a correct call is missing.

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

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

Schema description coverage is 100%, so the schema already documents every parameter and the custom_fields clearing warning. The description adds no field-level syntax or format guidance beyond what the schema provides, so the baseline 3 is appropriate.

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

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

States a specific verb and resource ('WRITE: add one subscriber to a mailing list') and immediately resolves the ambiguity with the sibling moosend_update_subscriber by explaining that an existing email gets UPDATED instead. An agent can distinguish this upsert tool from the dedicated update tool 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?

Gives clear operational context: upsert-on-existing-email, auto re-subscribe of previously unsubscribed addresses, and the 10 calls / 10 s rate limit. It does not explicitly say when to prefer this over moosend_update_subscriber or moosend_subscribe-style flows, so it falls short of full alternative routing.

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

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

Goes beyond the annotation by clarifying that this write does not trigger a send, that content may come from HTML or a fetched URL (with CSS inlining), that sender addresses must pre-exist in the account, and that the new campaign ID is returned. The 'WRITE:' framing is consistent with destructiveHint=true, so there is no contradiction.

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

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

Four tight sentences: the write/draft/no-send semantics come first, then content sourcing, then prerequisites, then the return value and endpoint. No filler.

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

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

With no output schema the description supplies the essential return info (the new campaign ID) and covers the two non-obvious constraints (content source, sender validation). Remaining gaps are minor, e.g. whether mailing_lists targets are validated against existing lists.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning: html_content and web_location are alternative content sources rather than complementary, and sender_email/reply_to_email must resolve to account senders (a validation constraint not stated 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?

States a specific verb (create), the resource (draft campaign), and an important scope qualifier: regular, non-A/B. This lets an agent separate it from any A/B-test creation or sending path 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?

Explains the key usage context — the result is a draft and is never sent, sending remains a human action — and gives prerequisites for sender_email/reply_to_email with a pointer to moosend_list_senders. It does not name a sibling for reading/updating the campaign afterward, so it falls just short of explicit alternatives.

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

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

The annotation already declares destructiveHint=true, and 'WRITE:' plus 'empty mailing list' and the POST endpoint add useful context. However, it omits auth/permission needs, duplicate-name handling, and side effects beyond list creation, so it adds only moderate value over the annotation.

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, front-loaded with the operation type and resource, then return value, then endpoint. No filler or repetition.

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

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

With no output schema, the description usefully fills the gap by stating it returns the new list's ID, and the nested preferences object is fully documented in the schema. It is only slightly thin on prerequisites and error behavior for a mutation tool.

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

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

Schema description coverage is 100%, so the schema already documents name, preferences, confirmation_page, and redirect_after_unsubscribe_page. The description adds no parameter-level detail beyond the schema, which is the expected baseline when the schema carries the full burden.

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

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

States a specific verb and resource ('create a new, empty mailing list') and clearly separates it from read siblings like get_mailing_list and list_mailing_lists. The 'WRITE:' prefix and endpoint reinforce the action unambiguously.

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 verb — create a list when one doesn't exist — but there is no explicit when-to-use vs. when-not guidance, no mention of behavior on duplicate names, and no routing to a sibling such as list_mailing_lists for checking existing lists.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description still adds useful behavioral context beyond that: the scope of the payload (which fields are and are not included) and the underlying endpoint GET /campaigns/{CampaignID}/view.json. It does not, however, note auth requirements, error behavior, 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 tight clauses, zero filler, and the payload scope is front-loaded before the exclusion and endpoint. Every sentence earns its place.

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

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

There is no output schema, and the description compensates by enumerating the returned fields and explicitly flagging the excluded statistics, which is precisely what an agent needs to choose this tool over its siblings.

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?

Only one parameter and schema description coverage is 100% – the schema already documents campaign_id as a GUID sourced from moosend_list_campaigns. The description adds nothing about the parameter, so the baseline 3 is correct.

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

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

States a specific verb+resource ('Get one campaign's details') and then enumerates the exact fields returned: subject, sender/reply-to, HTML and plain content, target lists/segments, schedule, status, A/B data. It also names the sibling it is not (campaign_summary), so an agent can distinguish it without opening a schema.

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

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

Explicitly states a negative boundary ('No statistics') and routes the agent to the correct alternative for that need ('use moosend_get_campaign_summary'). That is exactly the when-not/alternative guidance that disambiguates it from the several get_campaign_* siblings.

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

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

Annotations only declare readOnlyHint=true, so the description earns credit for disclosing the hard rate limit of 2 calls per 60 seconds per API key and the paging bounds (default 50, max 1000). That is genuine behavioral context an agent needs to plan calls. It stops short of describing the response shape or ordering of results.

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 the core purpose, then types, paging/date behavior, and the rate limit in a compact NOTE. The REST path reference is arguably redundant given the tool already calls it, but it is short and does no harm.

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 more burden than it does here: it never characterizes the return payload (fields per recipient, ordering, empty-result behavior). Rate-limit, paging, and type coverage are solid, so it is adequate but has a clear gap on the output side.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds two facts not fully in the schema: the page_size default of 50 and the 'Activity (all)' semantics of the type enum, plus the date-filtering behavior. This meaningfully reinforces the parameter contract rather than just restating it.

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

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

States a specific verb+resource ('per-recipient activity for a campaign') and enumerates the exact activity types, so the scope is unambiguous. It does not, however, explicitly distinguish itself from close siblings like moosend_get_campaign_link_activity or moosend_get_campaign_summary, leaving the agent to infer the boundary.

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

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

The description gives operational context (paging defaults, date filtering, rate limit) but offers no explicit when-to-use guidance or alternatives relative to the sibling activity/summary tools. Usage is implied by the 'per-recipient' framing 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?

readOnlyHint=true already tells the agent this is a safe read. The description usefully adds the metric granularity (total and unique opens per country) and the underlying REST path, but says nothing about rate limits, pagination, or granularity limitations on the country breakdown.

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

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

Two compact sentences, with the substantive metric description front-loaded ahead of the API path. Nothing is padded, though the raw endpoint string adds little for an agent that only needs selection and invocation.

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 readOnlyHint and no output schema, the description covers what is returned and how to obtain the ID. It is essentially complete, with only minor gaps around response shape and any scope limits.

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, and the schema already explains campaign_id is a GUID sourced from moosend_list_campaigns. The description adds nothing beyond that, which is the expected baseline when the schema fully documents the 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?

The description states a specific verb+resource: retrieving a campaign's opens broken down by country code, including both total and unique opens. This is clearly more specific than the sibling moosend_get_campaign_activity, though it never names that sibling to sharpen the distinction.

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

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as moosend_get_campaign_activity or moosend_get_campaign_summary. The agent must infer from the resource name alone that this is the country-level breakdown variant.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful return semantics (link-level total and unique clicks) but says nothing about pagination, result limits, or whether a campaign with no clicks returns empty. Adequate but not rich for a stats endpoint.

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

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

Two tight sentences with the payload description front-loaded and the endpoint appended as reference. Zero wasted text.

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, and the description does step in to summarize the return shape (links plus total/unique click counts). That is sufficient for a read-only, single-parameter tool, though pagination behavior is left unstated.

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 single campaign_id param is documented in the schema (GUID, sourced from moosend_list_campaigns). The description adds no format or provenance detail beyond what the schema already 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?

States a specific verb ('List'), resource ('every link in a campaign'), and returned metrics ('total and unique click counts'). An agent can distinguish it from siblings like moosend_get_campaign_summary or moosend_get_campaign_activity, which cover different aggregates, 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 description says what the tool returns but never states when to reach for it versus the other campaign-stats siblings (activity, activity_by_location, summary). No preconditions or alternatives are given, leaving selection to inference.

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

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

The readOnlyHint annotation already establishes this is a safe read, so the bar is lower. The description still adds value by noting results are cumulative 'to date' and that the target must be a sent campaign, but it says nothing about rate limits, permission requirements, or behavior for unsent/invalid campaign IDs.

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 the core purpose and the enumerated metrics, followed by the REST endpoint reference. It is efficient with no filler, though the raw endpoint string is metadata of marginal value to an agent choosing a tool.

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

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

With no output schema, the description compensates well by listing the exact returned metrics (opens, clicks, bounces, complaints, forwards, unsubscribes). An agent knows what it will get; the only gap is guidance on scoping or alternatives.

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

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

Schema description coverage is 100%; the single campaign_id parameter is fully documented in the schema, including that it is a GUID from moosend_list_campaigns. The description adds no further parameter detail, so the baseline of 3 is appropriate.

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

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

States a specific verb (Get) and resource (a sent campaign's results to date) and enumerates the exact metrics returned, which implicitly separates it from sibling activity/link-activity tools. It stops short of naming those siblings explicitly, so differentiation still requires the agent to compare names.

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 'a sent campaign's results' implies the tool only applies to already-sent campaigns, which is a mild usage constraint. However, there is no explicit statement of when to prefer this over moosend_get_campaign_activity or moosend_get_campaign_link_activity, so routing is left to inference.

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

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

The readOnlyHint=true annotation already tells the agent this is a safe, non-mutating read, so the bar is lower. The description usefully adds what the response contains (including the latest import operation) but says nothing about auth requirements, rate limits, or error behavior for a missing/invalid 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?

One front-loaded sentence covering the payload, plus a short endpoint reference — no filler. The trailing 'Moosend: GET /lists/{MailingListID}/details.json' is mildly redundant but does anchor the operation 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 compensates well by enumerating the returned fields. Both parameters are documented in the schema and the read-only nature is annotated, leaving only error/edge-case behavior 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 parameters are documented there, including that mailing_list_id is a GUID sourced from moosend_list_mailing_lists and that with_statistics defaults to true. The description adds no parameter-level meaning 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?

States a specific verb and resource ('Get one mailing list') and then enumerates the concrete payload (name, member counts, status, custom field definitions, preferences, latest import operation). The word 'one' implicitly separates it from the sibling moosend_list_mailing_lists, so an agent can tell the two apart 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?

The singular 'one mailing list' plus the required mailing_list_id imply this is the detail-fetch for a known list, but the description never states when to prefer it over moosend_list_mailing_lists or what happens if the ID is unknown. Usage is implied rather than guided.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds useful scope context (criteria, not members), but says nothing about authentication requirements, error/not-found behavior, or response shape that would deepen behavioral understanding.

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 scope constraint and the exclusion, with zero redundant filler.

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

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

With no output schema, the description does useful work by clarifying that segments' criteria are returned rather than members. Nothing critical is missing for a simple read-only lookup, though it could note what the criteria payload contains.

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

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

Schema description coverage is 100% and both parameters are documented with source hints (GUID from moosend_list_mailing_lists, integer from moosend_list_segments). The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb ('Get'), resource ('one segment's details and criteria'), and explicitly scopes out membership data. The parenthetical distinguishes it from the sibling members-listing tool, so an agent can route correctly 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?

The '(not its members)' clause implicitly steers the agent away from member data, hinting that moosend_list_segment_subscribers is the alternative, but it never names that tool or states an explicit condition for choosing one over the other. Usage is implied rather than instructed.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds the underlying REST route (GET /subscribers/{MailingListID}/find/{SubscriberID}.json), which confirms the read-only, ID-scoped nature, but says nothing about rate limits, 404 behavior, or error handling for a nonexistent subscriber.

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

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

Two short sentences, zero filler, with the tool's purpose front-loaded and the API route as supporting detail. 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?

For a simple two-parameter read-only getter with full schema coverage and readOnlyHint, the definition covers everything needed to invoke it correctly. The absence of an output schema means return shape is unspecified, but that is a mild gap for a single-record fetch.

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 are documented there as GUIDs, including the note that the mailing list ID comes from moosend_list_mailing_lists. The description adds only the route template placement of the two IDs, which the schema effectively already conveys — baseline 3.

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 ('Get one subscriber in a mailing list') and pins the lookup key as the subscriber ID, which implicitly distinguishes it from the sibling moosend_get_subscriber_by_email. It doesn't explicitly name that sibling, so it falls short of a 5.

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

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

No guidance on when to use this instead of moosend_get_subscriber_by_email, moosend_list_subscribers, or moosend_list_segment_subscribers. The description states what it fetches but leaves the selection decision entirely to inference.

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

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

With readOnlyHint=true already declaring the safety profile, the description adds real value: it documents the returned shape (ID, name, custom fields, tags, preferences) and decodes the SubscribeType status values (1 subscribed, 2 unsubscribed, 3 bounced, 4 removed), which appear nowhere in the schema or annotations. It does not cover not-found/error behavior, keeping it short of a 5.

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

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

One front-loaded sentence that leads with the action and key dimensions before listing return fields. It is dense but everything earns its place except the raw REST path, which 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?

No output schema exists, so the description correctly compensates by enumerating returned fields and decoding the status enum. It is nearly complete for a simple lookup, missing only error/empty-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 both parameters are already documented (email format, list ID as GUID sourced from moosend_list_mailing_lists). The description adds nothing about parameter format or constraints 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 ('look up a subscriber'), constrains scope ('in one mailing list by email address'), and enumerates what comes back. The 'by email address' key implicitly distinguishes it from the sibling moosend_get_subscriber (keyed by ID) and moosend_list_subscribers.

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 'look up a subscriber in one mailing list by email address', and the schema notes the list ID comes from moosend_list_mailing_lists. However, there is no explicit when-to-use-vs-alternative guidance (e.g. use moosend_get_subscriber when you have the subscriber ID, or list_subscribers for broad retrieval).

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds real behavioral context beyond that: the pagination ceiling of 1000 per page and the underlying endpoint. It does not cover auth needs, rate limits, default page size, or sort defaults, so it is useful but not rich.

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

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

Two dense sentences that front-load what is listed and follow with pagination and endpoint details. The status code enumeration is long but genuinely informative; nothing here is filler, though the run-on status list slightly dilutes the front-loading.

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 reasonably compensates by naming the fields a caller can expect (status, dates, target lists, sent/opens/clicks/bounces/unsubscribes/complaints). Combined with the readOnly annotation, an agent has enough to call this correctly; only the absence of use-case routing keeps it from being fully complete.

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

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

Schema description coverage is 100%, so the schema documents page, sort_by, sort_method and page_size with enums and defaults. The description adds essentially nothing on parameters (the '1000 per page' note merely echoes the page_size maximum), so the baseline 3 is correct.

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 campaigns') and enumerates the returned fields (status, delivery/schedule dates, target lists, headline stats), which is more than a bare restatement of the title. It is clearly a bulk/paged listing rather than the single-resource sibling moosend_get_campaign, though it never names that distinction 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 guidance on when to reach for this tool versus moosend_get_campaign, moosend_get_campaign_summary, or moosend_list_mailing_lists. The description only describes contents and pagination ('Paged, up to 1000 per page'); the use case is left to inference with no exclusions or alternatives named.

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

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

Annotations already declare readOnlyHint=true, and the description adds meaningful context beyond that: the exact endpoint and pagination structure (GET /lists/{Page}/{PageSize}.json), plus the specific return payload fields. It does not address rate limits or default sort behavior, which keeps it below a 5.

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

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

Front-loaded with the payload scope, then a short rationale, then the endpoint. Three compact sentences with little waste, though the parenthetical field enumeration makes the first sentence slightly dense.

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

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

With no output schema, the description compensates by naming the returned fields (member counts, custom fields, preferences, paging), so an agent knows what to expect. Combined with readOnlyHint and a fully documented input schema, the definition is nearly self-sufficient; only default-ordering behavior is left implicit.

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

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

Schema description coverage is 100% (page, page_size, sort_by, sort_method all documented with defaults and ranges), so the schema carries parameter meaning. The description only adds 'paging info' generically and the endpoint path showing {Page}/{PageSize}, providing 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?

States a specific verb and resource ('List the active email (mailing) lists in the account') and enumerates the returned content: member counts, custom field definitions, preferences, and paging info. This clearly separates it from siblings like moosend_get_mailing_list and moosend_create_mailing_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?

Gives a concrete usage context — 'a cheap way to confirm the API key works and to find list IDs' — which is actionable discovery guidance. It stops short of naming alternatives or exclusion conditions (e.g., when to prefer get_mailing_list for full detail), so it is clear but not fully routing.

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

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

readOnlyHint=true already tells the agent this is a safe read, and the description adds genuinely new context: the payload includes each segment's criteria, a match type with its enum meaning (0 all / 1 any), and a readable description. No pagination or rate-limit behavior is disclosed, so it stops short of a 5.

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

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

Two tight sentences with zero waste; the resource scope is front-loaded and the return-content detail follows immediately. The endpoint reference is compact and useful.

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 of explaining the return, and it does so at a high level (criteria, match type, description). For a one-parameter read-only tool this is largely sufficient, with only pagination/shape detail missing.

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

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

Schema coverage is 100% and the single parameter's GUID origin is documented in the schema itself, so the description need not repeat it. The match-type values referenced belong to the response, not the input, so they add no parameter meaning. Baseline 3 applies.

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

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

States a specific verb and resource (list the segments of one mailing list) and distinguishes itself from siblings get_segment (single segment) and list_segment_subscribers (subscribers of a segment). It even names the underlying endpoint, so the agent knows exactly which resource is read.

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 requirement of a single mailing list ID, which routes the agent through moosend_list_mailing_lists, but the description never states when to pick this over get_segment or list_segment_subscribers. No exclusions or alternative routing 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 readOnlyHint=true, and the description reinforces this with the GET endpoint and resource path. The word 'currently' usefully signals that membership is evaluated live against segment criteria rather than a static list, but nothing is said about result size, pagination, or what happens for an empty/invalid segment.

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: purpose first, then the concrete API mapping. Nothing is redundant and nothing is 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 two-parameter read tool with no output schema, the description covers what it does, its scope, and the underlying endpoint. It is slightly thin on result behavior (pagination/limits), but an agent has enough to invoke it correctly.

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

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

Schema description coverage is 100%, so both parameters (segment_id, mailing_list_id) are fully documented in the schema, including their provenance tools. The description only restates the identifiers via the URL template and adds no format or constraint detail beyond the schema.

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

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

States a specific verb (List) and resource (subscribers), with the scoping condition 'that currently match one segment's criteria' distinguishing it from moosend_list_subscribers. It does not name the sibling tool explicitly, so it is clear but not fully differentiated.

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

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

Usage is implied by the phrase 'match one segment's criteria' – an agent infers this is for segment-scoped lookups – but there is no explicit when-to-use, when-not-to-use, or named alternative (e.g. use moosend_list_subscribers for the whole 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?

readOnlyHint=true already tells the agent this is a safe read. The description adds the domain constraint tying senders to draft-campaign validity and the HTTP endpoint, but says nothing about pagination, result size, or ordering.

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 purpose and followed by the key constraint. The trailing 'Moosend: GET /senders/find_all.json' is largely redundant plumbing but costs little.

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

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

With no output schema, the description usefully names the fields returned and explains the value of the result for draft campaigns. Combined with the readOnly annotation, an agent has enough to call this correctly without further input.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline for a no-param tool is 4. The field list describes the payload rather than inputs, which is a mild bonus.

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

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

Starts with a specific verb+resource ('List the account's campaign senders') and enumerates the returned fields (name, email, enabled, SPF/DKIM verification). No sibling tool covers senders, so the unique resource is unambiguous to an agent.

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 'A draft campaign's sender and reply-to must be one of these' gives a concrete reason to call this tool before creating a draft campaign. It states clear context but offers no explicit exclusion or named alternative tool.

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

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

Annotations only declare readOnlyHint=true, so the description adds real value: it discloses that results are paged and enumerates the returned fields (name, email, custom fields, tags, preferences, dates). It does not state pagination limits or how to know when to stop paging, keeping it below 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?

Front-loads the core operation and deliverable fields, then adds paging and the API endpoint. Efficient, though the raw endpoint string is marginal information 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 helpfully names the fields returned and flags paging, which is what an agent needs. It leaves pagination termination behavior unstated, but otherwise the definition is complete for a read/list tool.

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

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

Schema description coverage is 100% (page, page_size, status enum, mailing_list_id with GUID hint), so the schema already documents every parameter. The description adds the status vocabulary and notes paging, but nothing the schema does not already convey — baseline 3.

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), resource (subscribers), scope (one mailing list), and the status dimension (Subscribed/Unsubscribed/Bounced/Removed). An agent can distinguish it from sibling reads like moosend_get_subscriber (single) and moosend_list_segment_subscribers (segment scope) 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 phrasing (filter one list's subscribers by status), but the description never states when to prefer this over siblings such as moosend_list_segment_subscribers or moosend_get_subscriber_by_email, nor any prerequisites. Adequate but with clear gaps.

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

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

Annotations only declare destructiveHint=true; the description adds real value beyond that: it labels the operation WRITE, clarifies it is list-scoped rather than account-wide, and discloses that the change is reversible by re-adding the subscriber. It does not cover auth requirements or rate limits, which keeps it below 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 tightly packed segments with the operation type front-loaded as 'WRITE:'. Every clause earns its place: scope, reversal path, and endpoint mapping.

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 two-parameter write with no output schema, the description covers scope, reversibility, and endpoint, which is enough to invoke correctly. It says nothing about the response or error behavior, a minor gap given no output schema exists to cover 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 coverage is 100% and both parameters are fully documented in-schema, so the baseline is 3. The endpoint template echoes {MailingListID} but adds no new semantic detail about the parameters beyond what the schema already states.

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

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

States a specific verb and resource ('unsubscribe one email address from one mailing list') and immediately bounds the scope with '(not account-wide)'. That scope qualifier lets an agent distinguish this from account-level or bulk unsubscribe operations without opening a schema.

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

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

Gives clear context: use when removing a single address from a single list, and it names the reversal path (moosend_add_subscriber). It does not state explicit when-not conditions or alternatives for removing on an account-wide basis, so it falls short of the top score.

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

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

Annotations only supply destructiveHint=true; the description adds the concrete destructive mechanic — omitted custom fields are cleared — plus the WRITE marker and the underlying API endpoint. It stops short of auth/permission requirements, but it substantially exceeds what the annotations convey and is consistent with them.

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 'WRITE:' and the core action, then the data-loss rule, then the endpoint. Two tight sentences plus a routing detail; nothing is padded, though the endpoint string is of marginal value to 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 an 8-parameter destructive mutation with a nested custom_fields object and no output schema, the description covers the highest-risk behavior (field clearing) that an agent must know before calling. Missing auth/permission context and explicit sibling routing keeps it from a 5.

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

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

Schema description coverage is 100%, so the schema already documents all 8 parameters, including the custom-field clearing warning. The description's field list and 'include every custom field' note largely restate that structured content, 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?

States a specific verb and resource ('update one subscriber (by ID) in a mailing list') and enumerates the updatable surface (email, name, custom fields, tags, preferences). The 'by ID' scoping and the WRITE marker clearly separate it from moosend_add_subscriber and the get_* siblings.

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

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

The description implies this operates on an existing subscriber and gives an operational rule ('include every custom field you want to keep'), but it never names alternatives or states when to prefer this over moosend_add_subscriber or moosend_unsubscribe_subscriber. Usage is inferable rather than explicit.

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