Emma MCP by usefulapi

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

Adds real context beyond the readOnly/openWorld annotations: what the response contains (all custom fields and status) and the concrete not-found signal ('a 404 means the address is not in the audience'). It does not mention the archived-member case, which is left entirely 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?

Two tight sentences with zero waste; the primary purpose and the not-found semantics are both front-loaded. Nothing is repeated 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?

With no output schema, the description usefully sketches the return shape (custom fields + status) and the failure mode. A brief note on archived members and how they are excluded by default would close the only 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%, so both parameters are already documented, including include_deleted ('Find the member even if archived'). The description adds nothing about parameters, so the baseline 3 applies.

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

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

States a specific verb and resource ('Find one member by email address') and identifies the key scope distinction — lookup by email rather than by id or a listing. It is distinguishable from siblings like emma_get_member and emma_list_members, though it never names them.

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

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

Usage is only implied: the 'by email address' framing suggests when this is preferable to id-based or list-based lookup, but no alternative tool or exclusion is stated. An agent must infer that emma_get_member is the id-based counterpart.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), so the description's job is to add context — and it does by disclosing the return contents: active, opted-out, and error member counts. That is real value beyond the annotations, especially since no output schema exists. It stops short of describing count semantics (e.g., whether counts are scoped or cached).

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 sentence, front-loaded with the action and resource, with the return payload appended. No filler and nothing an agent must read twice.

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 whose annotations already declare it non-destructive and open-world, the description covers what the tool does and roughly what comes back. With no output schema, a bit more on the return shape (e.g., whether group metadata accompanies the counts) 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?

One parameter with 100% schema description coverage, including range bounds and the provenance hint (member_group_id from emma_list_groups). The description adds nothing about group_id beyond what the schema already says, 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 ('Get one member group') and scopes it to a single record, which distinguishes it from the sibling list tools (emma_list_groups, emma_list_group_members). It also names the returned payload (member counts). It never names a sibling explicitly, so the differentiation is 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?

The phrase 'one member group' implies this is the single-record lookup versus the list tools, and the schema hints the id comes from emma_list_groups. But the description itself gives no explicit when-to-use, when-not-to-use, or alternative routing 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 and openWorldHint=true, so the safety profile is covered. The description adds meaningful behavior beyond that: the same tool returns either a single object or a list depending on whether import_id is supplied, which is not inferable from the annotations. It does not describe result shape or paging semantics, but paging is delegated 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?

A single compact sentence covering both call modes, with the primary case (single import) front-loaded before the fallback (list all imports). Nothing is redundant.

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

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

There is no output schema, so the description must at least gesture at what comes back; 'status and results' does that adequately for a read-only lookup tool. Paging is fully handled by the start/limit schema descriptions, so the remaining gaps are 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 description coverage is 100%, so the baseline is 3; the description earns above that by explaining that import_id is optional and that its absence switches the tool into list mode, which the schema alone (min 1, no required fields) communicates only implicitly.

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 combination (status and results of a bulk member import) and clearly names the two modes: single import by id, or full list of account imports. It is unambiguous and no sibling tool overlaps on imports, so further differentiation isn't required, though none is offered.

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 gives the condition that selects each mode: pass an import id for a single import's status/results, omit it to get the list of all imports. There is no guidance on exclusions or on when to reach for a sibling tool instead, which keeps it short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds real behavioral value by disclosing the shape of the returned payload (HTML and plain text content, recipient groups/searches/segments, links, schedule, status) in the absence of an output schema. It does not mention auth needs or the effect of the include_* flags, 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?

A single dense sentence with the main payload facets front-loaded and zero redundant restatement of the name or title. Every clause names a distinct returned data category.

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

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

For a read-only single-record getter with a fully documented three-parameter schema and no output schema, the description sufficiently conveys what comes back that an agent could not infer from structured fields. A brief note on the optional include_* flags would make it 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%, including a helpful pointer that mailing_id comes from emma_list_mailings, so the schema carries the parameter burden. The description adds nothing about the include_segment_names / include_subscription_names flags, only implying segment data is returned; 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 ('Get one mailing in full') and enumerates the returned facets (content, recipients, links, schedule, status), which clearly separates it from the list-style siblings and from the narrower emma_list_mailing_links / emma_get_mailing_response tools. It stops short of explicitly naming a sibling it is not, 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 'Get one mailing in full' — an agent can infer this is the detail-view counterpart to emma_list_mailings. However, there is no explicit when-to-use/when-not-to-use guidance or routing to alternatives like emma_get_mailing_response for stats.

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 and openWorldHint, so the safety profile is covered. The description's metric list adds real value given there is no output schema, but it does not say whether figures are counts or rates, how fresh the data is, or that a nonexistent mailing_id errors.

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 with a compact metric list; every element earns its place. It is a noun phrase rather than a verb-led statement, which slightly weakens the opening.

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

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

For a simple single-parameter read with no output schema, the enumeration of returned metrics substantially fills the gap. Missing only data-freshness and error-behavior notes.

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

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

Schema coverage is 100% with a single documented mailing_id, so the schema carries the parameter burden. The description adds no syntax, scoping, or validity notes 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 (one mailing's response summary) and enumerates the metrics it covers, so an agent can tell it apart from emma_get_mailing (settings/details) or emma_get_response_summary (broader summary). It never explicitly contrasts those siblings, though, so the differentiation is inferential.

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: 'of one mailing' plus the required mailing_id signal a per-mailing report. There is no statement of when to prefer this over emma_get_response_summary or emma_list_mailing_activity, 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, so safety is covered. The description adds genuine value beyond that by enumerating the returned payload (custom fields, status, SMS status, bounce count), which matters because there is no output schema. It does not discuss error behavior for missing/archived members, which the schema's include_deleted hints at but never explains.

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 with no filler. The returned-field enumeration is compact and earns its place given the absence of an output schema.

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 tool with full schema coverage and read-only annotations, the description covers purpose and return shape adequately. Minor gap: it does not state what happens when the id does not exist or when a member is archived and include_deleted is false.

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%, including descriptions for both member_id and include_deleted, so the schema carries the parameter burden. The description restates only 'by id' and adds no format, range, or behavioral detail beyond what the schema already provides; 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?

Clear verb+resource ('Get one member') with the lookup key specified ('by id'). This implicitly separates it from emma_find_member_by_email and emma_list_members, though those siblings are never named, so differentiation is inferred 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?

The phrase 'by id' implies the precondition for use, but there is no explicit guidance on when to prefer this over emma_find_member_by_email or emma_list_members. The agent must infer the routing from the parameter name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds nothing beyond the one-line purpose: it does not mention pagination behavior, result ordering, or what happens for a member with no groups, which is the kind of context annotations cannot supply.

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 with no filler. The scope qualifier 'one member' is placed where it does the most work.

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 described three-parameter schema and explicit annotations, the description covers the essential contract. The only gap is that, with no output schema, it never indicates the shape of a returned group record.

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 limit/start/member_id all carry their own descriptions, including the next_start pagination hint. The description adds no parameter-level meaning 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?

The description states a specific verb and resource ('List the groups') scoped to a single member, so an agent can distinguish it from emma_list_group_members (the inverse direction) and emma_list_groups without opening schemas. It does not explicitly name those siblings, which keeps it from 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 only implied by the wording 'one member belongs to' — the agent can infer it applies when a member id is known and group-level listing is not what is wanted. There is no explicit when-to-use statement, no prerequisites, and no named alternative for the reverse lookup.

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 openWorldHint=true, so safety is covered. The description adds a useful behavioral signal that engagement ('what they did with them') is included in the result, but it says nothing about pagination, result ordering, or empty-history behavior beyond what the schema's start/limit fields imply.

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

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

A single front-loaded sentence with no filler; the scope and content are stated immediately. It is terse to the point of being a fragment, which limits how much structure it can offer.

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 retrieval tool with full schema coverage and no output schema, the description covers what is fetched. However, it does not describe the shape of the returned history (paginated list of send/engagement records), which matters since there is no output schema to fall back on.

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 parameters (member_id, limit, start) are already documented in the schema, including the next_start pagination hint. The description adds no parameter-level meaning beyond what the schema provides, 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?

States a specific resource and scope: the mailing history of one member, including sent mailings and engagement ('what they did with them'). It implicitly distinguishes itself from siblings like emma_list_mailing_activity and emma_get_member by being per-member mailing history, but 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?

There is no statement of when to use this versus emma_get_member, emma_list_mailing_activity, or emma_list_mailings. Usage is only inferable from the phrase 'one member' and the required member_id in the schema.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description still adds real behavioral context: aggregation granularity (month-by-month), scope (whole account, not one mailing), and the exclusion rule '(test mailings excluded).' It stops short of 5 because it doesn't say what period is used when 'range' is omitted (a real ambiguity given zero required params).

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

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

A single sentence, front-loaded with the core concept (month-by-month, whole-account response stats) followed by a compact metric enumeration. Every clause carries information; nothing is redundant.

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

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

For a read-only, zero-required-parameter aggregation tool with 100% schema coverage and no output schema, the description supplies enough: metric set, granularity, scope, and the test-mailing exclusion. The only missing piece an agent would want is the default date window when 'range' is omitted.

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

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

Schema description coverage is 100%, with 'range' documented as YYYY-MM-DD~YYYY-MM-DD with one side optional and 'include_deleted' as including archived mailings, so the baseline is 3. The description adds nothing about either parameter, and notably never clarifies the default window when 'range' is absent or how 'include_deleted' relates to the stated test-mailing exclusion.

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

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

States a specific resource with an explicit scope: 'Month-by-month response statistics for the whole account,' which the colon-list of metrics (mailings, sent, delivered, bounced, opened, clicked, forwarded, opt-outs, sign-ups) further pins down. The account-wide scope implicitly separates it from the per-mailing sibling emma_get_mailing_response, but no sibling is named, 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 only implied: an agent can infer 'use this for a full-account, per-month rollup rather than a single mailing.' There is no explicit when-to-use, no named alternative, and no statement about when this summary is or is not the right 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 already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds the pagination contract ('Paged: use next_start'), which is useful, but says nothing about whether results reflect a live recomputation of the search or a cached snapshot, nor about rate or size behavior.

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

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

Two compact sentences, front-loaded with the resource and followed by the operational hint. Minimal waste, though the paging note partly duplicates the schema.

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 could say what a returned member contains or how the page envelope looks, but it does not. For a simple read-only listing with full schema coverage this is adequate rather than complete.

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

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

Schema description coverage is 100%, so all three parameters are fully documented in the schema. The description only echoes the paging hint already present on the start field, adding no new syntax or constraint information.

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

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

States the resource precisely — members matching a saved search — which distinguishes it from emma_list_members (all members) and emma_list_searches (the searches themselves). It lacks an explicit verb, but the noun phrase plus the paging note leaves no ambiguity about what is returned.

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: call this with a saved search id to page through its matching members. The schema adds routing by noting search_id comes 'from emma_list_searches', but the description itself names no alternatives or when-not conditions.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and scope are covered structurally. The description adds the shape of returned records, but says nothing about pagination behavior, result-set size, or that deleted fields are hidden by default — context that would matter for a listing call.

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 sentence with the verb and resource front-loaded and the parenthetical earning its place by previewing the returned attributes. Nothing is padded or repeated.

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 parenthetical partially compensates by naming the fields returned. Pagination and soft-delete behavior live entirely in the schema, which is adequate for a simple zero-required-parameter read tool; only the return envelope (paging metadata) 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 description coverage is 100%: limit, start, and include_deleted are each documented with ranges and defaults, including the 'use next_start from the previous reply' hint. The description adds no parameter meaning 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?

Names a specific verb and resource ('List the custom member fields of the account') and the parenthetical enumerates what each field record contains (shortcut names, display names, types). The resource is distinct from every sibling, which all operate on members, groups, mailings, searches, or imports, so an agent can route here without ambiguity even though no sibling is named.

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 can infer this is the discovery call for custom-field definitions, but the description never states when to call it (e.g. before reading or filtering members by custom field) or how it relates to emma_list_members. No exclusions or prerequisites are given.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety profile is covered. The description adds genuine context beyond that: the pagination protocol ('use next_start for more') and the shape of the returned records, which no structured field provides.

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 waste, with the core purpose and the return content front-loaded before the pagination hint.

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 returned fields and explains continuation. For a four-parameter read tool whose remaining semantics are in the schema, that is close to complete, though a note on whether include_deleted changes counts would help.

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 limit, start, group_id and include_deleted all documented in the schema. The description's paging note echoes the start parameter's own description, adding little beyond 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 and resource ('List the members of one group') and previews the returned fields (email, status, custom fields). This distinguishes it from the broad emma_list_members, though it never names that sibling explicitly.

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

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

The one-group scoping implies when this is preferred over the all-members listing, but there is no explicit when-to-use/when-not guidance or named alternative. Usage must be inferred from the group_id requirement.

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 openWorldHint=true, so safety is covered. The description adds useful context — the counts returned and the default exclusion of test/hidden groups — but says nothing about pagination limits beyond the schema or the return envelope. Adequate but not rich beyond structured data.

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

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

Two tightly written sentences: first the resource and what the payload contains, second the scoping default and override. Every clause earns its place, with zero redundancy against the schema.

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

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

For a read-only, paginated list tool with full schema documentation, this is nearly complete: purpose, content of results, and default scoping are all present. The only shortfall is that return shape and pagination behavior are not mentioned and no output schema exists to cover that 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 every parameter (limit, start, group_types) is documented in the schema, including enum meanings and the next_start hint. The description restates the group_types default only, so the baseline 3 is correct — it 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 a specific verb+resource (list member groups/audience lists) and adds the distinctive detail that results include active, opted-out and error member counts. This clearly separates it from siblings like emma_get_group (single group), emma_list_group_members (members within a group) and emma_get_member_groups (groups for one member).

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 default behavior (normal groups only) and how group_types expands scope to test and hidden groups, which is real selection guidance. It stops short of naming sibling alternatives or stating when a caller should prefer emma_get_group or emma_list_group_members 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 readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds value beyond that by disclosing the row shape (member email + timestamp) and the pagination model ('use next_start'), which is exactly the context needed to consume 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 comma-separated kind list, then output and paging notes. Every sentence earns its place 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?

With no output schema, the description carries return-value information and does so adequately (row contents, paging). Minor gaps remain around kind-specific filters and whether mailing_id errors are surfaced, but an agent has enough to call it correctly.

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

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

Schema coverage is 100%, so baseline is 3, but the description adds semantic meaning to enum values ('in_progress = still in the queue', 'deliveries = delivered or bounced') that raw enum labels don't convey. It does not add detail on link_id/member_id/delivery_type filters, which remain schema-only.

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 ('Who did what with one mailing') and enumerates the activity kinds, so the agent knows exactly what is listed. It doesn't explicitly name siblings like emma_list_mailing_links or emma_get_mailing_response, but the per-mailing activity scope is clear.

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 mapping of kind values to activity types implies how to use the tool, but there is no explicit when-to-use or when-not-to-use guidance versus alternatives such as emma_get_mailing_response (aggregate) or emma_list_mailing_links.

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

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

The annotations already declare readOnlyHint=true and openWorldHint=true, so safety behavior is covered. The description adds useful return-content context by saying results include unique and total clicks, but it does not disclose pagination behavior, permissions, or error handling.

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 sentence with no filler, front-loading the resource and the key returned metrics. It is appropriately sized for a simple read-only listing operation.

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

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

The tool is a simple read-only listing operation; annotations cover safety, and the schema fully documents parameters including pagination. The description names the returned metrics but does not describe the return structure or distinguish this tool from related mailing-summary tools.

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

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

Schema description coverage is 100%, and all three parameters are documented in the schema, including defaults and pagination guidance for start and limit. The description adds no additional parameter meaning 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?

The description clearly states the resource (links of one mailing) and the returned metrics (unique and total clicks). It is specific enough to identify the operation, but it does not explicitly differentiate this tool from siblings such as emma_list_mailing_activity or emma_get_mailing_response.

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

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

There is no explicit guidance on when to use this tool versus alternatives, nor any mention of exclusions. The phrase 'of one mailing' implies the required mailing context, but an agent must infer when this is the right choice over related mailing tools.

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 openWorldHint=true, so the safety profile is covered without help from the prose. The description adds pagination behavior via 'Paged: use next_start', which is genuine added context, but says nothing about ordering, empty results, or what a member record contains. Adequate against a lower annotation-adjusted bar, 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 short sentences, zero filler, with the disambiguating scope parenthetical placed immediately after the resource so the reader hits it first. The pagination note trails as a secondary operational detail, which is the right ordering.

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 with fully documented parameters and no output schema, the description covers purpose, scope, and pagination — enough to call it correctly. It leaves the shape of returned member records and result ordering unstated, a minor gap given how shallow the operation is.

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 all three parameters carry their own descriptions with ranges and defaults, so the schema does the heavy lifting. The description's 'Paged: use next_start' merely echoes the schema's own start-parameter text ('Use next_start from the previous reply'), adding no new semantics. 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) and a precisely scoped resource (the individual members a mailing was sent to), and pre-empts confusion by excluding groups and searches. That negates the ambiguity with siblings like emma_list_members, emma_list_group_members, and emma_get_search_members in the same sentence.

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?

'(not groups or searches)' gives a clear scope boundary that implicitly routes the agent to the group/search-member siblings, and 'Paged: use next_start' tells the agent how to iterate. It stops short of naming an explicit alternative tool or stating when-not to call this one at all, so it is strong but not a full routing statement.

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 openWorldHint=true, so the safety profile is covered; the description adds the non-obvious default filter set and sort order, which the agent cannot infer from annotations. It doesn't mention the paging cap (limit max 500) or total counts, but those are largely in 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?

Front-loaded with purpose and returned fields, then defaults, then paging, in three tight sentences with no filler. The inline status-code legend is dense but earns its place for an agent printing results.

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 rightly lists returned fields, default scope, sort order, and how to paginate – enough to call it correctly. It omits filter interactions (e.g., how include_archived combines with mailing_types) but the gaps are minor 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%, so the baseline is 3. The status legend and type glosses repeat what the schema enums already say; the only genuine addition is the cross-reference that 'start' should come from next_start in 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?

Opens with a specific verb+resource ('List mailings (campaigns)') and enumerates the returned fields, so the agent knows exactly what comes back. It implies the distinction from emma_get_mailing (single) only through the plural noun, so it doesn't fully differentiate from 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?

States the default scope precisely ('standard and test mailings in all statuses, newest first') and gives an explicit paging protocol ('use next_start'). It never names an alternative tool or when-not to use this one, keeping it short of a 5.

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

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

With readOnlyHint and openWorldHint already covering safety, the description adds real value: it enumerates returned fields, decodes the status codes (a/o/e), and explains pagination and count_only response shapes. It doesn't mention rate limits or ordering, but the behavioral disclosure is well above the annotation baseline.

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

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

Three tight sentences, front-loaded with the core purpose, then paging and the count_only variant. No filler or redundancy.

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 listing the returned fields and status codes is essential and done well. The archived-member toggles are covered by the schema rather than the description, which is acceptable given 100% coverage, but a brief note on deleted handling would have made it fully self-contained.

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 every parameter is already documented in the schema. The description reinforces next_start and count_only semantics but adds little beyond that, leaving deleted_only, include_deleted, and exclude_fields solely to the schema. 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 ('List the members (contacts)') and scopes it to 'the whole audience', which implicitly distinguishes it from group- or search-scoped siblings like emma_list_group_members and emma_get_search_members. It stops short of naming those alternatives explicitly, so differentiation is inferable rather than spelled out.

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 operational guidance for paging ('use next_start for more') and for count_only, but never states when to choose this tool over siblings such as emma_list_group_members, emma_get_search_members, or emma_find_member_by_email. Usage is implied by the 'whole audience' scope rather than stated.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds that results carry their criteria, but says nothing about default exclusion of deleted searches or the paginated shape of the response. Useful but not rich behavioral context.

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

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

A single front-loaded sentence with zero filler; the resource and its qualifier come first. Nothing is wasted or buried.

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

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

For a simple read-only list tool with no output schema, the description tells the agent what entities are returned and that criteria are attached. Pagination details are supplied by the schema, so the remaining gap is only the sibling-relationship guidance.

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 pagination guidance and the include_deleted flag, so the schema does the heavy lifting. The description adds no additional meaning about limit/start/include_deleted, so the baseline 3 applies.

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

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

States a specific verb and resource ('List the saved searches') and clarifies the domain term with a synonym ('dynamic segments'), plus notes that criteria are included. It does not distinguish itself from sibling emma_get_search_members, which is the nearest alternative for search-related data.

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 listing nature implies when to use it (browsing saved segments), but there is no explicit when-not or alternative named. An agent must infer whether to use this versus emma_get_search_members or emma_list_fields.

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