Notifyre MCP by usefulapi

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

Goes beyond the annotations (which cover readOnly/destructive/idempotent/openWorld) by disclosing that adding to a group sends nothing immediately, that a later send to the group will reach the contact, and that existing group memberships are preserved. It stops short of explaining partial-failure or invalid-id behavior.

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

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

Four tight sentences with the 'WRITE:' safety signal and the core operation front-loaded; the side-effect clarification is placed exactly where it matters. No filler.

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

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

For a two-parameter write tool with annotations covering the safety profile and no output schema, the description supplies the operation, the limits, and the send-side-effect semantics. Only edge-case behavior (invalid ids, partial application of the batch) is unaddressed.

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

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

Schema description coverage is 100% and both parameters are documented there, so the schema carries the load. The description's mention of 'up to 100 contacts and 20 groups' merely restates the schema's maxItems constraints, adding no syntax or format detail beyond structured data.

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 ('adds existing contacts to existing groups') with explicit scope limits. It is clearly distinguishable from siblings like notifyre_create_contact and notifyre_create_group, which create new entities rather than link existing ones.

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 'existing contacts to existing groups' phrasing implicitly tells the agent not to use this for creating new contacts or groups, and the note about later sends clarifies why one would do this. However, it never explicitly names the alternative tools or states a when-not-to-use condition.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, but the description adds real value beyond them: duplicate contacts may be created on repeat calls, and group_name silently CREATES a group as a side effect. That side-effect disclosure is the kind of context annotations cannot express. It stops short of 5 because it does not state auth/permission needs.

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?

Six tightly packed sentences, front-loaded with the write scope and the invocation constraint, with no filler. Every clause carries either a requirement, a side effect, or a routing 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?

Important for a tool with zero required parameters — the description supplies the 'at least a name or a number' constraint the schema cannot. Since no output schema exists, it could have said what is returned (e.g., the new contact id), which is 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 the baseline is 3, but the description adds cross-field meaning the flat schema cannot: the at-least-one-of-name/number constraint, the group_ids (existing only) vs group_name (auto-creating) distinction, and a concrete international number example. These are genuine semantic additions, not restatements.

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 an explicit verb+scope ('WRITE: adds one contact to the Notifyre address book'), which immediately separates it from the read-oriented siblings like notifyre_list_contacts and notifyre_get_contact. The endpoint note (POST /addressbook/contacts) reinforces the write nature.

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 concrete invocation guidance: 'Give at least a name or a number', plus the group_ids-vs-group_name choice rule and the duplicate-creation caveat. It does not explicitly route the agent against the sibling notifyre_add_contacts_to_groups for post-creation grouping, so it falls short of a full 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=false, idempotentHint=false, openWorldHint=true and destructiveHint=false, so the write/idempotency profile is covered. The description usefully confirms this with the 'WRITE:' marker and the underlying POST endpoint, but says nothing about duplicate-name behavior, auth requirements, or rate limits.

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

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

Two terse sentences, front-loaded with the operation type, and each sentence carries distinct information (semantics and API endpoint). Nothing is padded or redundant.

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

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

For a single-parameter creation tool with full annotation coverage and no output schema, this is close to complete: the agent knows the action, the resource, and the HTTP semantics. The only meaningful gap is conflict behavior when a group name already exists, which matters given idempotentHint=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?

With one parameter at 100% schema description coverage, the schema already documents 'name' fully, including its 1-100 length bounds. The phrase 'with the given name' adds no syntax, format, or constraint 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 ('creates one address book group') plus the operation type ('WRITE'), which cleanly separates it from notifyre_list_groups and notifyre_add_contacts_to_groups. It does not explicitly name a sibling or contrast against one, so it falls just short of a 5.

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

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

The description says what the tool does but never says when to use it versus notifyre_add_contacts_to_groups or notifyre_list_groups, nor does it state any prerequisites. An agent must infer the usage context entirely.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety and scope are covered. The description adds the plain REST endpoint (GET /addressbook/contacts/{id}) but says nothing about auth, rate limits, or error behavior for a missing 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 tight sentences, field list up front and endpoint reference at the end, with no filler or restated boilerplate.

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 field enumeration (names, organization, email, fax, mobile, groups, custom fields, unsubscribed flag) usefully previews the response shape. Only minor gaps remain around failure cases and pagination-free single-record semantics.

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

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

Only one parameter with 100% schema description coverage, so the schema fully documents contact_id. The description adds no formatting, source, or lookup 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?

States a specific verb and resource ('Get one contact') and enumerates the returned fields, which cleanly separates it from the plural sibling notifyre_list_contacts. An agent can tell what it fetches without opening the schema.

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

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

The singular 'Get one contact' implies lookup-by-id usage, but there is no explicit when-to-use statement or pointer to notifyre_list_contacts for bulk retrieval. Usage is inferable 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 safety and external-data expectations are provided. The description adds useful behavioral detail about what the returned object contains (every recipient, statuses, parts, cost) and the underlying API path. However, it does not disclose rate limits, pagination, or error behavior for missing ids.

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

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

Two efficient sentences. The result content is front-loaded, followed by the id source, then the API endpoint. Every sentence earns its place.

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

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

For a simple one-param read tool with annotations covering safety and open-world behavior, the description is nearly complete. It covers what is returned and where the id comes from. Missing only peripheral error/absent-id behavior.

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

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

Schema description coverage is 100%, and the schema's message_id description already distinguishes the SMS message id from the friendly id. The description points to sources for the id but adds no format, syntax, or validation 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 (Get) and resource (one sent SMS message) and enumerates what the result includes: recipient status, delivery status, message parts, cost. This distinguishes it from notifyre_list_sent_sms and notifyre_get_sms_recipient.

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 says where to get the id: notifyre_list_sent_sms or notifyre_send_sms. That is clear routing context, but it does not name what the tool should not be used for (e.g., getting a single recipient rather than the whole message).

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 useful detail about the returned fields (status, parts, cost) and the underlying API path, but does not mention auth needs, rate limits, or error behavior.

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

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

Two front-loaded sentences with no filler: the first states what is returned, the second maps to the API endpoint. Efficient and easy to scan, though the endpoint path is arguably redundant given the explicit 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 GET with no output schema, the description appropriately enumerates the returned fields and the endpoint. Combined with full schema coverage and readOnly/openWorld annotations, an agent has nearly everything needed; only auth/error context is absent.

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

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

Schema description coverage is 100%, so both parameters are already documented. The description's URL template illustrates how messageId and recipientId compose the path, adding marginal value over the schema, but does not elaborate on formats beyond it.

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

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

States a specific verb ('Get') and resource ('one recipient of a sent SMS') and enumerates what it returns (status, parts, cost). This clearly distinguishes it from message-level siblings like get_sent_sms and get_sms_reply.

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 description says it operates on 'one recipient of a sent SMS' and the schema ties recipient_id to get_sent_sms, suggesting a follow-up workflow. There is no explicit when-to-use vs when-not-to-use statement or alternative named.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the agent knows this is a safe remote read. Beyond that the description only discloses returned fields and the underlying endpoint (GET /sms/received/{id}), without noting error behavior or access requirements. Adequate with annotations, but not richly informative.

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 action and return content, then the sourcing hint, then the endpoint. No filler and every clause earns its place.

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

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

For a simple single-record read with no output schema, the description covers purpose, parameter provenance, and returned fields, which is nearly everything an agent needs. Minor gaps remain around failure modes and pagination/ID validity, keeping it just shy of a 5.

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

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

Schema description coverage is 100%, so the single reply_id parameter is already documented, making the baseline a 3. The description does add provenance ('from notifyre_list_sms_replies'), which is slightly more than the schema offers, but the param's core semantics live in the schema.

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

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

States a specific verb (Get) and resource (one received SMS reply), and enumerates the returned content (text, sender, receiving number). The singular 'one reply' clearly distinguishes it from the sibling notifyre_list_sms_replies, so an agent can separate the two without opening a schema.

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

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

Explicitly routes the agent: 'Use the replyID from notifyre_list_sms_replies,' naming the upstream sibling that supplies the required parameter. It gives clear context but stops short of stating when-not-to-use or what happens with an invalid/stale ID.

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 and reach profile is covered structurally. The description adds the account scoping ('the account's registered') and the underlying HTTP endpoint, but says nothing about pagination, result size, or return 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?

Two short sentences with zero filler, and the purpose is front-loaded ahead of the API implementation detail. Every sentence earns its place.

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

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

For a parameterless read-only list tool with no output schema, the description covers what is returned at a high level and how it maps to the API. Only pagination or result-limiting behavior is unaddressed, which is a minor gap for this complexity level.

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 the schema baseline of 4 applies; there is no parameter syntax for the description to clarify or omit. The description correctly implies an unfiltered account-level listing.

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

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

States a specific verb (List) and resource (the account's registered 10DLC brands), and the parenthetical gloss 'US SMS sender registration' decodes the jargon an agent might not know. It is distinguishable from siblings like list_sms_numbers or list_contacts by the resource noun, though no sibling is named 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: an agent can infer this is the tool for enumerating brands, but there is no when-to-use guidance, no prerequisites, and no stated alternative for adjacent needs. Adequate but with a clear gap.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered by structured data. The description adds the underlying endpoint (GET /numbers/campaigns), which is useful provenance, but says nothing about pagination, result volume, or account scoping for what is implicitly a full listing.

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

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

Two compact sentences with the purpose and scope front-loaded, followed by endpoint provenance. No filler, no restatement of the title, and every clause earns its place.

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

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

For a zero-parameter read-only list tool with no output schema, the definition covers what is returned (campaigns plus their status) adequately. The only omission is whether results are paginated or bounded, which is a minor gap given the tool's simplicity.

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 rubric the baseline is 4 and there is nothing the description needs to compensate for. No parameter-level detail could add value here.

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 gives a specific verb+resource ("List the account's 10DLC campaigns") and helpfully glosses the jargon as "US SMS use-case registrations" with explicit status reporting. However, it offers no differentiation from closely related siblings such as notifyre_list_brands or notifyre_list_sms_numbers, so an agent must infer where 10DLC campaigns sit in the registration hierarchy.

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 tool versus alternatives, no prerequisites, and no exclusions. The presence of notifyre_list_brands (a directly related 10DLC registration resource) makes the absence of routing guidance a real gap rather than a trivial one.

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 genuinely new behavioral facts: unsubscribed contacts are omitted unless include_unsubscribed is true, and the unsubscribe key is never returned, which tells the agent what it will and won't see in 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?

Compact, front-loaded sentences that each carry a distinct fact (filters, pagination base, exclusion defaults, hidden field, endpoint). The trailing endpoint note is mildly redundant with the title but confirms the read semantics of the POST.

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

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

For an 8-parameter read tool with no output schema, the description covers filtering, pagination origin, and result-content caveats well enough to call it correctly. It stops short of describing the response envelope or pagination metadata, which the absent output schema leaves undocumented.

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 largely restates schema text (page starts at 0, search_query matches name, type keeps contacts with that number) and says nothing about sort_by, sort_dir, or limit, adding no syntax or format 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?

Starts with a precise verb+resource ('Search the address book') and names the exact endpoint (POST /addressbook/contacts/search), making it instantly distinguishable from the singular notifyre_get_contact and from the unrelated list_* 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 when each filter applies (search_query matches name, type keeps contacts with that number, group_ids limits by group) and states the default exclusion of unsubscribed contacts, giving clear context for how to narrow results. It never routes the agent away from alternatives (e.g. get_contact for a single contact), so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so safety is covered. The description adds real behavioral context beyond that: it discloses that the HTML body of each template is excluded from the response and names the underlying API endpoint (GET /fax/coverpages).

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

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

Two compact sentences with zero filler; the return-content caveat and the endpoint are both front-loaded and each sentence earns its place.

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

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

With no output schema, the description compensates by naming the fields returned (name and default flag) and excluding the HTML. For a zero-parameter read-only list this is nearly complete, though it says nothing about ordering or whether results are paginated.

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 and the schema is empty, so there is nothing for the description to disambiguate. The baseline for a parameterless tool applies.

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

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

States a specific verb (list) and a precise resource (fax cover page templates of the account), plus what each entry contains. The resource is unambiguous and cannot be confused with sibling list tools such as notifyre_list_fax_numbers or notifyre_list_sent_faxes.

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 you call this to discover available cover page templates (e.g., before sending a fax). There is no explicit when-to-use, when-not-to-use, or named alternative among the siblings, so it sits at minimum viable.

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 value by enumerating the returned fields, but says nothing about pagination, result limits, or empty-account behavior, which would be relevant for a listing endpoint.

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

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

Two compact sentences, front-loaded with the action and followed by the endpoint reference. Every clause carries information 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 zero-parameter list tool with annotations covering the safety profile and no output schema, the description gives enough: action, returned fields, and API endpoint. Minor gap is the absence of any pagination or rate-limit note.

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 the baseline is 4. The schema is empty and fully covered, and the description appropriately adds the shape of the response (E.164, region, status) rather than parameter 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 ('List the account's fax numbers') and even names the returned fields (E.164, region, status). It is clearly distinct from the similarly named sibling notifyre_list_sms_numbers, though it does not call that sibling out by name.

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

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

There is no explicit when-to-use guidance, no prerequisites, and no mention of alternatives. The description only states what the tool does, leaving the agent to infer that this is the read/list counterpart to other fax 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 safety is covered. The description adds the endpoint mapping (GET /fax/send/prices) and the shape of the returned records, which is useful context, but says nothing about auth requirements, rate limits, or the fact that pricing may be extensive per country.

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: the first front-loads what is returned, the second gives the API route. No redundancy or filler, and 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?

With no output schema, the description usefully names the four returned fields, so an agent knows what to expect from an otherwise schema-less call. It is nearly complete for a trivial read-only endpoint; only auth/pagination notes are 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; per the rubric a 0-parameter tool baselines at 4. The description correctly implies no filtering input is 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?

States a specific verb and resource ('List the price of sending a fax per destination country') and enumerates the returned fields (country code, calling prefix, price, currency). It does not differentiate itself from the sibling notifyre_list_sms_prices, but the resource 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 intent (retrieve fax pricing) is implied by the description, but there is no explicit when-to-use guidance, no mention of prerequisites, and no pointer to the near-identical sibling notifyre_list_sms_prices for an agent choosing between pricing endpoints.

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 underlying endpoint (GET /addressbook/groups) and notes that contact counts are included in the response, which is modestly useful context. It says nothing about pagination, result size, or auth requirements.

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

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

Two tight sentences with zero waste; the resource and payload are front-loaded ahead of the incidental API path. Every clause earns its place.

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

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

With no output schema, the note about contact counts partially compensates for return-value opacity, and the endpoint reference helps. However, it omits pagination behavior and any other returned fields, leaving the agent with an incomplete picture of the response shape.

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 sort_by, sort_dir, and search_query all documented and enum values listed, so the baseline is 3. The description adds nothing about filtering or sort syntax beyond what the schema already provides.

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

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

States a specific verb and resource ('List the address book groups') and even previews the payload ('with their contact counts'). It is clearly distinguishable from list_contacts or list_campaigns, though it does not explicitly name a sibling to differentiate against.

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

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

There is no guidance on when to use this versus alternatives such as notifyre_list_contacts or notifyre_create_group, nor any stated preconditions. The list-everything use case is only implied by the name.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds non-obvious behavior beyond that: documents are NOT downloaded, the implicit 30-day default window, and the pagination contract via next_skip.

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

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

Four tight sentences: scope and returned fields first, then the important 'not downloaded' caveat, then defaults and pagination. No filler, and the most decision-relevant facts are front-loaded.

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

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

There is no output schema, but the description enumerates the returned fields (sender, number, time, pages, duration, read flag), covers the default date window, and explains paging — 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?

Schema description coverage is 100%, so the baseline is 3. The description adds meaning the schema doesn't: the from_date default window of 30 days and the pagination flow (skip = next_skip), which clarifies how skip is meant to be used across calls.

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 (faxes received on the account's fax numbers), then enumerates the returned fields. The word 'received' cleanly separates it from the sibling notifyre_list_sent_faxes, so an agent can pick the right tool 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 actionable usage context: the default 30-day window when from_date is omitted, and that paging uses skip = next_skip. It doesn't explicitly say when to prefer this over sibling list tools, but the 'received' scope makes the alternative self-evident.

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 genuinely useful context beyond that: the implicit 30-day default window, the valid status values, and the pagination convention. It stops short of describing rate limits or ordering guarantees.

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 dense sentences with the core purpose front-loaded and no filler. The parenthetical field list and endpoint reference are compact and informative rather than padding, though the endpoint line is arguably optional.

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 implies the response carries a next_skip value for pagination. It still leaves limit/sort/search behavior to the schema, but for a filtered list tool this is close to complete.

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

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

Schema coverage is 100%, so all seven parameters are already documented, and the description mostly restates status values and the from_date default. It adds slight value by linking skip to the next_skip value, but that is barely 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 and resource ("List faxes sent from the account") and immediately enumerates the returned fields, which cleanly separates it from the sibling notifyre_list_received_faxes. It even names the underlying endpoint, so the scope 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?

Gives clear operating context: the default 30-day window when from_date is omitted, how to filter by status, and how to page with skip = next_skip. It does not explicitly name an alternative tool or state when-not to use this one, so it falls short of the 5 bar.

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 safety is covered. The description still adds real behavior: default descending date sort, an implicit 30-day lookback window, and the pagination cursor convention, which is exactly the kind of context not present in 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?

Four tight sentences with no filler: identity and return fields first, then default window, then filters, then paging. Every sentence carries distinct operational information, and the API route is tucked at the end where it belongs.

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 9 optional parameters, no output schema, and a read-only annotation set, the description covers the lookback window, sorting default, filter dimensions, and pagination — enough to call it correctly. Missing only edge details such as how many records a reasonable page size is or any rate-limit/auth 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?

Schema description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema by grouping filters ('by status, numbers, or a message id in search') and by revealing that the response carries a next_skip value to feed back into skip. The from_date default it cites is largely a restatement of 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?

It states a specific verb and resource ('List SMS messages sent from the account') plus the returned fields (recipient, status, cost) and even the backing endpoint (GET /sms/send). The list/get distinction from siblings like notifyre_get_sent_sms is only implied by scope, not named, so it falls short of full sibling differentiation.

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

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

It gives clear invocation context: the default 30-day window when from_date is omitted, the filterable dimensions (status, numbers, message id in search), and the paging convention (skip = next_skip). It never says when to prefer notifyre_get_sent_sms for a single message instead, so there is no explicit exclusion 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 real context beyond that: the account-scoped nature of the data, the exact fields each entry carries (E.164, status, 10DLC campaign), and the underlying endpoint. It omits pagination/rate-limit behavior, keeping it short of a 5.

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

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

Three short sentences with zero padding; the resource scope and returned fields come first, then the practical use, then the API grounding. Nothing could be removed without losing information.

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

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

For a parameterless read with no output schema, the description adequately compensates by enumerating the returned fields and the endpoint. Only the absence of any pagination or result-size note keeps it from being fully complete.

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

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

The tool takes zero parameters, so the baseline is 4. The description adds a relevant cross-tool note about the `from` field value this list supplies, which is useful framing even though there are no parameters to disambiguate.

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

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

Specific verb+resource: lists the account's SMS numbers and approved alphanumeric sender IDs, with the key returned fields named inline. It is clearly distinguishable from siblings like list_fax_numbers, list_brands, and list_campaigns 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?

It gives a downstream use ('Use one of them as `from` when sending'), which implies the reason to call it, but never states when to prefer it over alternatives or any prerequisites/exclusions. Usage is implied rather than stated.

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

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

Annotations already cover the safety profile (readOnlyHint=true, openWorldHint=true), and the description adds useful context beyond them: the exact cost formula (price x message parts x recipients) and the underlying endpoint GET /sms/send/prices. It does not mention auth, rate limits, or pagination, so it is strong but not exhaustive.

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, each earning its place: what it returns, how to apply the price, and the backing endpoint. The purpose is front-loaded 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?

A no-parameter read tool with no output schema, and the description compensates by describing the returned fields and how to interpret the price. Nothing an agent needs to call it correctly is missing.

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

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

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to disambiguate on the input side. The field list it provides pertains to output rather than parameters, so it neither helps nor hurts here.

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 price of one SMS per destination country') and enumerates the returned fields (country code, calling prefix, price, currency). This clearly separates it from sibling price/inventory tools like notifyre_list_fax_prices or notifyre_list_sms_numbers.

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 it before sending' explicitly signals the use case and links the tool to the sending flow. It stops short of naming notifyre_send_sms as the alternative or stating any exclusions, so it is clear but not fully routing.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, so the safety profile is covered. The description adds useful behavior beyond that: the 30-day default window, the page-size cap of 20 when include_reply_content is set, and the underlying GET /sms/received endpoint. It says nothing about rate limits or response shape, but the additions are substantive.

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

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

Four short, front-loaded sentences carrying defaults, cross-parameter constraints, and paging guidance with no filler. Every sentence earns its place.

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

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

With no output schema, the description still conveys enough to call the tool correctly: defaults, the paging pattern, and the content/limit interaction. It omits any indication of what a reply record contains, which would be the main remaining gap for a list endpoint.

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

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

Schema coverage is 100%, so all nine parameters are already documented, including the from_number/to_number pairing and the 20-record cap. The description mostly restates those same constraints; the only genuinely new semantic is the 'skip = next_skip' paging hint. Baseline 3 reflects that the schema does the heavy lifting.

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

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

States a specific verb and resource ('List SMS replies received on the account's numbers'), which an agent can distinguish from the single-item sibling notifyre_get_sms_reply by the list verb. It stops short of naming that sibling or any other alternative, so sibling differentiation is implicit rather than 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?

Gives concrete operational context: the default 30-day window when from_date is absent, the rule that from_number and to_number must be used together, and how to page via skip = next_skip. It does not state when to prefer this over get_sms_reply or other list endpoints, so the alternative-selection guidance is missing.

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 flag write/destructive/non-idempotent, but the description goes well beyond them: discloses balance spend, irreversibility, no automatic retry, the cost formula, character/part counting rules (160/70 per part), compliance obligations (opt-out link, Spam Act, 10DLC), and the specific uncertainty semantics of a timeout or HTTP 5xx. This is exactly the extra context annotations cannot carry.

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 most consequential facts are front-loaded in the first clause (writes real SMS, spends money, irreversible), which is the right ordering for a destructive tool. It is long and dense, and a few regulatory sentences could be compressed, but nearly every sentence carries distinct operational information rather than 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 destructive, non-idempotent send with no output schema, the description covers everything the agent needs: rate/cost model, format constraints, sender resolution, compliance preconditions, and what to do when the result is ambiguous. It even compensates for the absent output schema by naming the tool that confirms whether a message actually went out.

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

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

Schema coverage is 100%, so the schema already defines each parameter, setting the baseline at 3. The description adds real meaning on top: the part-count economics behind body length, that omitting `from` routes through a Notifyre shared number, and that add_unsubscribe_link defaults to false and can itself push the text into another billable part.

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 and resource plus the critical scope fact: it sends REAL SMS, spends the prepaid balance, and cannot be undone or recalled. This clearly separates it from read-only siblings like notifyre_list_sent_sms or notifyre_get_sent_sms without the agent needing to open 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?

Gives explicit when-to-use rules ('Only send what the user explicitly asked for: confirm the exact text, the recipients and the sender first'), explicit exclusions ('no contacts, no groups, no scheduling'), and routes to named alternatives for cost (notifyre_list_sms_prices), sender selection (notifyre_list_sms_numbers), and retry verification (notifyre_list_sent_sms).

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