Cyberimpact MCP by usefulapi

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

Adds real context beyond the annotations: the write bypasses double opt-in, existing members are rejected (consistent with idempotentHint=false), calls are throttled, and the underlying route is POST /members. It stops short of describing response payload or what the throttle limit actually is, so a 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?

Leads with a 'WRITE:' marker that front-loads the mutation risk, then packs consent, alternative, dedup, and throttle notes into a short block with no filler. It is dense to the point of being run-on and could be split for scanability, but every clause carries information.

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

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

Covers everything an agent needs to call this safely: consent precondition, the opt-in alternative, duplicate handling, volume limits, and the endpoint. With no output schema required and full schema coverage, no material gap remains.

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

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

Schema description coverage is 100%, so every parameter including the nested customFields map is already documented and cross-referenced to cyberimpact_list_custom_fields. The description only restates the group_ids role ('put it in the given groups') and adds no syntax, 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?

Names a specific verb and resource ('add a contact as a subscribed member') and pins down the distinguishing behavior: membership is created WITHOUT a confirmation email, i.e. implied consent. That scope statement separates it cleanly from cyberimpact_send_optin and cyberimpact_update_member 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 explicit when-to-use ('only for people who really gave their consent (CASL)'), an explicit alternative with its triggering condition ('to ask the person to confirm first use cyberimpact_send_optin'), and a volume-based redirect ('for many contacts use the app's import'). Nothing about tool selection 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?

Goes well beyond the annotations: the parenthetical '(existing group memberships are kept)' confirms additive, non-replacing semantics, and the mailings consequence discloses the downstream effect of the write. It also discloses the return value ('the member's groups after the update'), which matters since there is no output schema, and this is consistent with idempotentHint=true and destructiveHint=false.

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 the WRITE marker, the scope, and the non-destructive guarantee; the endpoint is placed last where it is least needed. No sentence is redundant with the schema or annotations.

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

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

For a two-parameter write with no output schema, the description covers the precondition, the additive semantics, the business consequence, and the return value. Nothing an agent needs in order to call this correctly is missing.

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

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

Schema description coverage is 100%, and the schema documents both 'key' (email or numeric id) and 'group_ids' with min/max item bounds, so the schema carries the burden. The description adds only the implicit constraint that the member must already exist; it adds no format or batching detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('add an existing member to more groups') and tags it WRITE, so it is immediately distinguishable from the read-only sibling get_member_groups and from add_member, which creates a new member. The endpoint POST /members/{key}/groups reinforces the resource scope.

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?

'add an existing member to more groups' makes the precondition (member must already exist) explicit, which is the key when-to-use signal versus add_member. It explains the consequence ('being in a group makes the member a recipient of mailings'), but never names an alternative tool such as get_member_groups for reading memberships or list_group_members for the inverse view.

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 annotations by noting the group is created empty and cannot be deleted through this server, a meaningful lifecycle constraint on a non-idempotent write. It also explains the consequence of the public flag. It omits any note on response contents or failure modes.

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 a WRITE marker and the verb+resource, with no filler. Every clause carries information an agent can act on.

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 create tool with no output schema, the description covers intent and constraints but says nothing about what comes back (e.g., the new group ID) that an agent would need for follow-up calls. Annotations cover the safety profile, so the gap is limited but real.

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 real meaning to is_public — public groups surface on subscription forms, private ones stay internal — beyond the schema's bare 'true = public group'.

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 group') and clarifies terminology by equating group with mailing list, which matters because a sibling is named create_mailing. It does not explicitly contrast itself with that sibling, so it stops short of a 5.

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

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

The public/private explanation implies when each variant is appropriate, but there is no explicit guidance on when to create a group versus using create_mailing or add_member_to_groups. 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.

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

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is known. The description still adds real value: the email is actually sent unless cancelled in the Cyberimpact app before send_at, and a mailing cannot be deleted through this server. It does not describe what the call returns (e.g. a mailing ID) or failure/partial-group 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?

Front-loaded with the write/send warning, then preconditions and the deletion caveat, with no filler. The 'POST /mailings' tail is mildly extraneous but harmless.

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

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

For an 11-parameter destructive send with no output schema, the description covers the key risks (real send, cancellation window, non-deletable, sender validation, approval gate). Remaining gap is the response contract and what happens on scheduling failure, minor given the schema's thoroughness.

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

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

Schema description coverage is 100%, so every parameter including send_at timezone, language enum, group_ids and confirm_send is already documented. The description only restates confirm_send=true and mail_from validation, adding no syntax or format detail the schema lacks, so it sits at the baseline.

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

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

States a specific verb (create a mailing scheduled to be sent at send_at), the resource, and the recipient scope (every member of the chosen groups). The 'WRITE, SENDS EMAIL TO CUSTOMERS' lead makes it unmistakably a mutating send tool, distinct from the read/list siblings like cyberimpact_get_mailing and cyberimpact_list_mailings.

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 gates usage: only after the user has approved subject, body, sender and groups, and confirm_send must be true. It also states the prerequisite that mail_from be a validated sender and the cancellation window, so an agent knows both when to call and what must be true beforehand.

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?

Adds real context beyond the annotations: the operation is a save-only write with no delivery side effect, and the underlying endpoint is disclosed. It doesn't mention what happens on duplicate titles or that repeat calls create distinct templates (annotations already mark it non-idempotent), so a little remains uncovered.

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 the WRITE marker and the core action; each sentence carries distinct information (action, side-effect scope, endpoint) with 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 3-parameter creation tool with full schema coverage and no output schema, this covers what the tool does and its key non-behavior (no sending). It stops short of saying what comes back (e.g. a template id for later get_template calls), which would help an agent chain the next step.

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 states that at least one of bodyHtml or bodyText is required. The description's 'from HTML and/or text' only restates that constraint, adding no format, length or title-uniqueness detail.

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 email template') plus the accepted inputs (HTML and/or text), and the 'nothing is sent' clause separates it from send/mailing siblings. An agent can distinguish it from get_template and list_templates without opening any schema.

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

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

'WRITE: create...' plus 'only saved in the account; nothing is sent' gives a clear context for when this is the right call rather than a send operation. It never names the alternatives (list_templates, get_template, create_mailing), so there is no explicit when-not guidance.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real context beyond that: it names the underlying endpoint (GET /ping) and the fields surfaced, confirming this is a lightweight identity probe with no side effects.

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

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

A single front-loaded sentence: purpose first, returned fields in parentheses, endpoint last. 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 no-param read-only tool with no output schema, the description discloses the return shape (username, email, account name) and the endpoint, which is everything an agent needs to call it correctly.

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

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

The tool takes zero parameters, so per the baseline this scores 4. Nothing in the description needs to explain inputs, though it also does not mention that no arguments are required.

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?

Uses a specific verb+resource ('show which Cyberimpact account the API token belongs to') and enumerates the identity fields returned. It is inherently distinguishable from every sibling, which all operate on members, groups, mailings, or templates, though it never says so 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?

'Check the connection' tells the agent this is a token/connectivity verification call, which implies running it before other operations when credentials are uncertain. It does not spell out exclusions or when to skip it, but there is no competing sibling it could be confused with.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the returned payload scope (status plus result) and the endpoint path, but says nothing about whether polling is expected, how long batches take, or what the result looks like structurally.

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 purpose, followed by the actionable parameter hint and the endpoint for traceability. Nothing is redundant and nothing could be cut 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 two-parameter read-only lookup with full schema coverage and no output schema, the description covers purpose, states, and the optional error-expansion flag. The only gap is that no output schema exists and the description does not sketch the shape of the returned result, leaving the agent to discover it at call time.

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: the schema says only 'Include the details of each error', while the description clarifies these are per-member errors for a bulk member operation. That extra specificity helps the agent decide when to enable the flag.

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: fetches the status of a bulk batch job, and enumerates the possible states (NEW, PROCESSING, COMPLETED) plus the result payload. It does not need to differentiate from named siblings because no other batch-related tool exists in the sibling list, so it is clear without being maximally explicit.

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

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

Usage is only implied – an agent infers this is the tool to poll when tracking a bulk job, but there is no statement of when to call it versus other tools or of prerequisites (e.g. where the batch_id comes from). The one conditional hint, setting show_error_details, is genuinely useful guidance for a specific scenario.

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 readOnly/openWorld/non-destructive, so the description's main added value is naming what the payload contains (member count, mailing count, flags) — meaningful since there is no output schema. It omits behavior for a nonexistent or unauthorized id, which keeps it from 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 front-loaded sentences with no filler; the return fields come first. The trailing 'GET /groups/{id}' is near-redundant with the name but cheap and aids API 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 one-parameter read tool with full annotation coverage, this is nearly complete: it says what comes back and implies id-scoped lookup. Only the failure mode for an unknown id 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?

Single parameter with 100% schema description coverage ('Cyberimpact group id.', positive integer), so the schema does the work. The description's 'by id' merely confirms the schema's intent rather than adding format or constraint detail.

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 ('One group by id') and enumerates the returned fields (member count, mailing count, flags). It is clearly distinguishable from list_groups by the singular scope, though it never names the sibling explicitly.

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

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

Usage is only implied: fetch a single group when you have its id. There is no explicit guidance on when to prefer this over cyberimpact_list_groups or cyberimpact_get_member_groups, and no precondition/error notes.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful behavioral detail beyond annotations, especially the returned metrics and that HTML/text body is cut at 20,000 characters.

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

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

The definition is a single front-loaded sentence with no filler: it states the retrieval scope, summarizes the payload, and includes the endpoint. Each clause contributes useful information.

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

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

With no output schema, the description compensates by enumerating the returned fields and mentioning truncation of body content. Together with annotations and the fully documented single parameter, this is sufficient for correct invocation.

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

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

Schema coverage is 100% and the single mailing_id parameter is already documented in the schema as "Cyberimpact mailing id." The description only says "by id" and adds no format or usage detail beyond the schema baseline.

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

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

The description names a specific verb and resource, "One mailing by id," and enumerates the result payload, so an agent can distinguish it from list-oriented siblings like cyberimpact_list_mailings.

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 "by id" phrasing implies the tool is for retrieving a single known mailing, but the description gives no explicit when-to-use guidance, prerequisites, or alternatives such as list_mailings for finding IDs.

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 and destructiveHint already covering safety, the description adds meaningful context by disclosing exactly what the payload contains: all attributes, consent type, mailing activity, and custom fields. It does not mention behavior when the member is not found or any error/rate-limit conditions, keeping 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?

One front-loaded sentence lists the member scope and return contents, followed by the endpoint. Every clause 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?

Because no output schema exists, the description usefully enumerates the return contents and points to cyberimpact_list_custom_fields for custom field key interpretation. It is nearly complete for a read tool, though a note on missing-member behavior would close the remaining gap.

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

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

Schema coverage is 100% and already documents the single key parameter as an email address or numeric id. The description restates the same accepted forms without adding format constraints or examples, so 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 clearly states it retrieves a single member by email or id and enumerates the returned data (attributes, consent, mailings, custom fields), distinguishing it from list_members by scope. It lacks an explicit verb like 'retrieve' and does not name sibling tools it should not be confused with, so it stops short of a 5.

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

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

Usage is implied—use when you need one member's full record—but there is no explicit when-to-use versus get_member_consent, get_member_groups, or get_member_mailings. The only routing hint is to see cyberimpact_list_custom_fields for interpreting custom field keys, not for choosing this tool over 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?

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds the record's field composition (consent type, relation type, date, expiration, proof) and the underlying endpoint, but says nothing about what happens when a member has no consent record or whether any authorization scope is required.

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 fragments totalling one line, with the substantive field list front-loaded. It is efficient, though the absence of a verb makes it read more like a field dump than a sentence.

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 with no output schema, listing the returned fields is exactly the right compensation. The only meaningful gap is error/empty-state behavior when no consent record exists.

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 'key' parameter is fully documented in the schema as an email address or numeric id. The description only repeats the path placeholder {key} and adds no format, encoding, or lookup-fallback guidance 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?

Names a specific resource (a member's consent record) and enumerates the fields it carries, which distinguishes it from the sibling cyberimpact_get_member profile lookup. It omits an explicit verb but the title and name supply 'get', so the intent is unambiguous.

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

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

The parenthetical 'for CASL compliance checks' gives an implied usage context, but there is no explicit statement of when to call this versus cyberimpact_get_member or the list/unsubscribed tools, 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.

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds that id, title, visibility and dynamic-ness are returned, which is genuinely useful given there is no output schema, but it says nothing about pagination, empty results, or membership edge cases.

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

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

Two compact fragments, front-loaded with the resource and return fields, with zero filler. It is terse enough that it reads more like a note than a full spec, but nothing is wasted.

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

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

For a simple read-only list tool with a fully documented schema and annotations, the description covers the essentials and hints at return shape. With no output schema, it could have said more about the returned array structure or pagination behavior, but the gaps are modest.

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%, documenting key, page, sort, and limit, so the baseline is 3. The description only echoes the path parameter and adds no 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 the specific resource and relationship clearly ('The groups a member belongs to') and names the returned fields. An agent can distinguish it from the inverse sibling list_group_members and from add_member_to_groups, though the verb is implied rather than stated.

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

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

Usage is only implied by the phrasing; there is no explicit statement of when to call this versus list_group_members or get_member. The sibling names make the distinction inferable, but nothing in the text routes the agent.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, openWorldHint=true, so the safety profile is covered. The description adds little beyond restating that these are received mailings and citing the GET path, which duplicates what readOnlyHint already tells the agent; pagination behavior is only implied through the schema.

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

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

A single front-loaded clause states the resource before any qualifier. The trailing 'GET /members/{key}/mailings' is mildly redundant with readOnlyHint but does anchor the endpoint.

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 should say more about what a mailing record contains (subject, date sent, date opened) — it gestures at 'what was sent and when' but not the shape. For a paginated, four-parameter read tool this is adequate but leaves the return payload underspecified.

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% — key, page, sort enum, and limit are all documented in the schema, including the 'pass the previous reply's next_page' hint. The description adds no parameter meaning beyond that, so the baseline 3 applies.

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

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

States a specific verb-like resource and scope: mailings received by a specific member, with the parenthetical clarifying it shows what a contact was sent and when. It is distinguishable from cyberimpact_list_mailings (account-wide) and cyberimpact_get_mailing (single mailing), though it never names those siblings explicitly.

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

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

The parenthetical '(use it to see what a contact was sent and when)' gives an implied use case, but there is no explicit when-not guidance and no named alternative (e.g., list_mailing_recipients for the inverse direction). The agent must infer routing from the resource name alone.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds genuinely non-obvious behavior beyond that: the template body is truncated at 20,000 characters, which materially affects an agent's interpretation of the result.

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

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

Two short sentences, front-loaded with the resource and followed by the truncation caveat and endpoint. Nothing is wasted.

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

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

For a single-parameter read with no output schema, the description covers what is returned (HTML and text body) and the truncation limit, which is the main thing an agent needs. A brief note on missing-id behavior would close the remaining gap.

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

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

Schema coverage is 100% and the single parameter template_id is fully documented in the schema. The description only restates 'by id' without adding format, range, or sourcing hints, 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 ('One template by id') and names the returned content (HTML and text body), which distinguishes it from the sibling list_templates. The endpoint reference reinforces that it is a single-resource fetch, though it never names list_templates as the way to obtain ids.

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 'by id' against the sibling cyberimpact_list_templates, but the description gives no explicit when-to-use or when-not guidance and no note about what happens when the id does not exist.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds one meaningful behavioral nuance — that membership is based on the LAST mailing's hard bounce, not cumulative bounce history. It does not disclose pagination behavior or the member fields returned.

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 front-loaded sentences with no filler; the defining condition precedes the endpoint path. 'GET /members/bounced' is mildly redundant given the tool name but cheap and useful for API-literate agents.

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 all-optional, paginated read with no output schema, the description says what population is returned and what key field accompanies it. Missing only return-shape hints (e.g., which member fields appear) and a note that results are paged.

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%, including the unusual page guidance ('Pass the previous reply's next_page') and date-range semantics, so the schema does the heavy lifting. The description adds nothing about the seven parameters, which is acceptable at full coverage — 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 ('Members whose last mailing hard-bounced') and defines the qualifying condition precisely, including the returned datum ('with the bounce date'). This clearly separates it from cyberimpact_list_members and cyberimpact_list_unsubscribed_members.

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 '(invalid addresses to clean up)' implies the cleanup use case, which is useful context. However, it never states when to choose this over the sibling list tools (list_members, list_unsubscribed_members) or any exclusions such as soft bounces being absent.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds useful context about the return payload shape but says nothing about pagination, ordering, or whether results are account-scoped in practice beyond 'the account's'.

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, front-loaded with what the resource is, then the key relational fact, then the endpoint. Nothing is padded, though the endpoint notation 'GET /customfields' is low-value for an agent that never constructs the call.

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 parameters and no output schema, the description carries the return-value burden and does so by naming id/name/type and the allowed type values. It is adequately complete for a trivial read-only list tool, missing only pagination/volume expectations.

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 4 applies. The enumerated return fields are a bonus rather than a substitute for parameter documentation.

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 (lists the account's custom member fields) and enumerates the returned fields (id, name, type with allowed types). It is clearly distinct from siblings like list_members or list_groups, though it never names those alternatives 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?

Usage is implied rather than stated: 'Member customFields are keyed by these ids' tells the agent this is the lookup you need before interpreting or writing member custom-field values. There is no explicit when-to-use, no prerequisites, and no named alternative.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds only the HTTP path (GET /groups/{id}/members), which conveys little beyond confirming the read; nothing is said about pagination behavior, result caps, or 404 handling for an unknown group id.

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

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

Two very short sentences with no filler, and the scoping fact comes first. The trailing raw path is slightly redundant for an agent that never issues HTTP calls directly, but it 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?

For a filtered read-only listing tool whose full parameter set is documented in the schema and whose safety profile is in annotations, this is largely sufficient. The remaining gap is that an agent must infer pagination and empty-result behavior solely from the schema's next_page hint.

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

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

Schema description coverage is 100%, so every parameter is already documented, and the baseline of 3 applies. The 'same member filters as cyberimpact_list_members' note adds only a weak cross-reference and does not clarify group_id semantics or the joinedOn/updatedOn ranges.

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 the specific resource (members of one group), which clearly separates it from the sibling cyberimpact_list_members that lists members globally. It is delivered as a noun phrase rather than a verb+resource, but the meaning is unambiguous.

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

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

It points to cyberimpact_list_members as the source of the filter semantics, which implies 'use me when you want those same filters scoped to a group'. However, there is no explicit when-to-use vs. cyberimpact_get_member_groups (the inverse lookup) and no exclusions or prerequisites.

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

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

Annotations already declare readOnlyHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds real value beyond them by disclosing the payload contents (member and mailing counts, public/private and dynamic flags) and the underlying GET /groups endpoint, though pagination behavior is left to the schema.

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

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

Three short sentences, front-loaded with the resource and payload, followed by usage and endpoint. Nothing is repeated from the schema 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?

With no output schema, the description usefully enumerates what a group record contains, and pagination is fully covered by the schema. What remains unstated is the response envelope shape (e.g., where next_page lives), a minor gap for a read-only 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% and all three params (page, limit, sort) are documented with defaults and ranges in the schema, including the next_page chaining hint. The description adds no parameter meaning beyond that, 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?

Specific verb plus resource ('List the account's groups') with an inline clarification of the domain term ('mailing lists') and an enumeration of the returned fields. The account-wide scope distinguishes it from the single-group sibling cyberimpact_get_group and from cyberimpact_list_group_members.

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?

'Use the ids to target mailings and opt-ins' gives the downstream purpose, which implies when to call it. However, no alternative is named and no exclusion is stated (e.g., when to prefer list_group_members or get_group), so usage is only implied.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered structurally. The description contributes the URL shape and the framing that results describe delivery/engagement outcomes, but says nothing about pagination limits or result volume, which matters for a potentially large recipient set.

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

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

Two sentences plus an endpoint reference, front-loaded with the outcome-oriented framing before the technical path. The enumeration of kind values partially duplicates the schema enum and costs some space, keeping it just short of ideal.

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 signals that records include delivery and engagement status, which tells the agent what comes back. Pagination mechanics are left entirely to the schema, and there is no note on result size, but for a filtered list tool this is close to sufficient.

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

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

Schema description coverage is 100%, including the enum for kind, page/limit defaults and the next_page continuation hint, so the schema carries the parameter burden. The description restates the kind values and mentions group filtering without adding format or default detail beyond the schema, so baseline 3 applies.

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

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

The opening phrase 'Who received a mailing and what happened' states the resource and the shape of the answer, and the endpoint 'GET /mailings/{id}/recipients[/{kind}]' pins down the operation precisely. It does not differentiate itself from near-neighbours like cyberimpact_list_bounced_members or cyberimpact_list_unsubscribed_members, so an agent must infer that this one is scoped to a single mailing.

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 only recipients from one group' gives one scoping hint, and the enumerated kinds imply the segmentation use case. However, there is no explicit when-to-use guidance and no statement of when to prefer cyberimpact_get_mailing or the sibling bounce/unsubscribe listers instead.

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 readOnly/openWorld/non-destructive, so the safety profile is covered. The description adds genuine context beyond that: the sent-state default excludes archived mailings, the returned fields (id, subject, language, send/schedule date, recipient count, sender), and the underlying GET endpoint shape.

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

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

Three short sentences, no filler: scope enumeration first, returned fields second, optional filter last, with the endpoint as a trailing technical cue. Every sentence carries information an agent needs.

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

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

With no output schema, the description usefully enumerates the returned fields, and the schema fully covers pagination/sort parameters. For a read-only list tool this is close to complete, though it doesn't say anything about page-size defaults or result ordering behavior beyond pointing at the sort enum.

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 expands the terse 'Which mailings (default sent)' enum note into per-state meanings, and adds the non-obvious fact that sent implicitly filters out archived. Page/sort/limit are left entirely to the schema, so the gain is real but partial.

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 opens with a specific verb+resource ('List mailings') and immediately enumerates the three scopes it can return, including the default. An agent can tell this is the listing tool rather than a single-mailing fetch, though it never names a sibling (e.g. get_mailing) to sharpen 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?

It clarifies what each state means — sent excludes archived, scheduled is 'queued to go out' — and notes the group filter is optional, which implies how to pick a scope. But it gives no explicit when-to-use vs alternatives (get_mailing, list_mailing_recipients) and no exclusions beyond the sent/archived default.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds scope details — default status of active, the meaning of 'active' and 'orphans', and inclusion of mailing counts and custom fields — that go beyond the annotations.

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

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

Front-loaded with the resource and returned fields, then status semantics, then filters. The trailing 'GET /members.' is minor filler but the rest is dense with no wasted sentences.

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's enumeration of returned fields (name, email, language, consent type, mailing counts, custom fields) is essential and present. Defaults and edge-case statuses are covered, leaving nothing critical unclear for calling the 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 coverage is 100%, so baseline is 3, but the description adds real semantics: it clarifies what status=active vs orphans means and that joined/updated filters apply. Sort and pagination details are left to the schema.

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

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

States a specific verb and resource (list subscribed contacts/members) and enumerates the fields returned, so the agent knows exactly what it gets. It also differentiates from siblings by noting bounced and unsubscribed members have their own tools.

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

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

Explains the status modes and their defaults, date filtering, and points away from this tool for bounced/unsubscribed contacts. It doesn't explicitly compare against get_member or list_group_members, but the context is clear.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered. The description adds only the returned field set and the underlying endpoint, saying nothing about pagination behavior or ordering despite page/limit/sort params existing.

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

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

A single front-loaded sentence plus the endpoint reference, with zero filler. Every element earns its place and the key noun phrase ("email templates") appears first.

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

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

With no output schema, the description correctly compensates by listing the returned fields (id, title, created/updated), and the three optional params are fully covered by the schema. Only pagination/ordering behavior is left to inference, which is a minor gap for a read-only 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 coverage is 100% with self-documenting descriptions (page, limit, sort enum), so the schema carries the load and a baseline 3 applies. The description adds no meaning beyond the schema — it doesn't explain sort semantics or that next_page comes from the previous reply.

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

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

States a specific verb and resource ("List the account's email templates") and even enumerates the returned fields, which makes the scope concrete. It implicitly contrasts with cyberimpact_get_template and cyberimpact_create_template through the verb, but never names a sibling explicitly.

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

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

Usage is only implied by the verb "List" — an agent can infer this is the bulk-retrieval counterpart to get_template, but the description never says when to prefer it over get_template or that it should be used before creating a mailing. No exclusions or prerequisites are offered.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is covered. The description adds a genuinely non-obvious downstream rule - these contacts must never be re-mailed - which changes how an agent should act on the result. It omits anything about pagination behavior or response size, keeping 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?

Three short sentences, front-loaded with the resource and scope; nothing is padded. The trailing 'GET /members/unsubscribed' restates implementation detail an agent cannot act on, a minor waste.

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, zero-required list tool with no output schema, the description covers what the records are and one returned field (unsubscribe date). It does not convey the shape of the response or that results are paginated, which the agent must infer from the page/limit schema.

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

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

Schema description coverage is 100%, with all seven parameters (page, limit, sort, and the updatedOn/unsubscribedOn date bounds) fully documented including formats and defaults. The description adds no parameter 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?

States the specific resource (members who unsubscribed) and the key attribute carried (the unsubscribe date), which distinguishes it from the sibling list_members and list_bounced_members by name alone. It never explicitly says 'list' or names the sibling alternatives, 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?

Usage is implied by the resource itself, and 'These contacts must not be mailed again' signals the compliance/audit use case. However, it gives no explicit guidance on when to pick this over list_members, list_bounced_members, or get_member, and states no exclusions or prerequisites.

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

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

Annotations already declare destructiveHint/openWorldHint/idempotentHint=false, but the description adds value beyond them: the member record is created if absent, group membership is deferred until confirmation, sending is throttled by the provider, and the underlying endpoint is named. It does not cover re-send behavior or what happens if the address is already confirmed, which keeps it from 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 critical signal ('WRITE, SENDS AN EMAIL'), then scope, alternative, and guardrail. Every sentence carries weight, though the parenthetical nesting in the first sentence makes it denser than ideal, and the trailing 'POST /members/optins' is marginal value for an agent.

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

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

For a 14-parameter destructive send with a nested customFields object and no output schema, the description supplies the safety gating, the side effect on member creation, and the throttling caveat. Return-value expectations are the only real gap, and absent an output schema that gap is minor.

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

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

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining the timing semantics of group_ids (joined only after confirmation) and the approval meaning behind confirm_send. That is genuine added meaning rather than restating field descriptions.

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

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

States a specific verb (sends an email), the resource (an opt-in confirmation request to a given address), and the side effect (person is added to groups only after confirming). It explicitly contrasts with cyberimpact_add_member, so the agent can distinguish it from siblings without opening schemas.

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?

Names the alternative explicitly ('Use this instead of cyberimpact_add_member when you do not have the person's consent yet') and gives the precondition for calling ('Only call it after the user has approved sending to this address, and set confirm_send to true'). Both the when and the when-not are covered.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so safety is signposted; the description earns credit for adding specifics those hints cannot convey: unchanged attributes are preserved, changed values are overwritten, and the old values are not recoverable via the API. It stops short of auth requirements or any note about what the API returns on partial failure.

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 sentences, front-loaded with the WRITE marker and the core partial-update semantics, ending with the endpoint. Every clause carries information an agent cannot get from the schema or annotations.

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

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

For a 12-parameter mutation with a nested customFields object and no output schema, the description covers the things that matter most: mutation intent, partial-update behavior, irreversibility, and email-change routing, while the schema and annotations handle the rest. Minor gaps remain around what an update returns and behavior on an unknown key.

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

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

Schema coverage is 100%, so the baseline is 3. The description does add one genuinely useful clarification the schema cannot: that new_email, not key, changes the address, resolving the ambiguity created by key accepting an email address. Beyond that it restates the partial-update contract rather than adding field-level meaning.

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

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

"WRITE: change only the given attributes of a member" gives a specific verb and resource, and the parenthetical clarifies this is a partial update, not a replace. It never names the create counterpart (cyberimpact_add_member) or the read counterparts, so sibling differentiation is left implicit rather than stated.

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

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

Usage is implied: it is for modifying an existing member, and "Set new_email to change the address" steers the agent away from abusing the key field for email changes. But there is no explicit when-not guidance (e.g. use add_member for new members, get_member to read first) and no alternatives named.

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