SalesBlink Cold Email

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

Annotations already declare destructiveHint=true and openWorldHint=false, so the safety profile is covered and the bar is lower. The description adds real behavior beyond that — custom snake_case fields become list columns and `starred` is a contact setting rather than a column. However, it never says what happens to contacts already present in the list, whether existing records are updated or duplicated, or how destructive this really is for a 500-item batch.

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 core action and the data-provenance constraint are front-loaded in the first two sentences, before the field-format details. It is slightly long and the snake_case/`starred` point is partially duplicated in the schema, but no sentence is pure padding.

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

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

An output schema exists, so return values need not be explained. For a destructive batch mutation the description covers the two things an agent can't get elsewhere: the data-source attestation policy and the list-column side effect of custom fields. The remaining gap (duplicate/existing-contact behavior) is a minor edge case rather than a missing prerequisite.

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

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

Schema description coverage is 100%, so every one of the five parameters including the consent_basis enum is already documented in structured data. The description's snake_case naming convention and the `starred` clarification largely restate what the schema says. Baseline 3 applies when the schema does the heavy lifting.

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

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

States a specific verb and resource (add multiple contacts to an existing list), including the batch nature and the prerequisite that the list already exist. It also distinguishes itself from archive_contact by naming that sibling explicitly, so an agent can rule out the wrong 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?

The description gives a strong usage precondition (contacts must come from an evidenced import or consent source the account holder already has) and an explicit exclusion (do not assemble addresses from model knowledge or scraping). It also routes archiving to archive_contact. What it lacks is guidance against adjacent siblings such as add_user or create_list for the case where the list does not yet exist.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false, and openWorldHint=false, so the safety profile is covered externally. The description adds nothing beyond that: no disclosure of duplicate handling, whether blocking is idempotent, what happens to already-blocked addresses, or the effect on workspace scope.

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?

Very short and front-loaded, but the first clause ('Add to Blocklist') is a pure restatement of the name/title and consumes roughly half the text, leaving only one short functional clause.

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 simple, has full schema coverage, annotations, and an output schema, so the description needs little. Still, for a mutation it omits return behavior signals like whether blocked entries appear immediately and how duplicates are reported, leaving minor gaps.

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, including that the emails array accepts domains. The description's 'emails and/or domains' phrasing merely restates the schema rather than adding format or constraint details, 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 (add) and resource (emails/domains to the blocklist), so the operation is unambiguous. However, it does not distinguish itself from close siblings like remove_from_blocklist, check_blocklist, get_blocklist, or delete_blocklist_entry — the agent must infer the difference from names alone.

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

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

No when-to-use guidance is given: nothing about when to block versus check or remove, and no mention of prerequisites such as whether the sender must exist first. Usage is only implied by the tool 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=false, destructiveHint=true and openWorldHint=true, so the safety profile is covered. The description's added value is the word 'invite', which implies an outbound email/membership side effect, but it never says an email is dispatched, that a role is granted, or that role='admin' is privileged — all relevant given destructiveHint=true.

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

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

Two short clauses, front-loaded and waste-free, though 'Add a User' largely restates the tool name and title before the more informative 'Invite' clause.

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?

An output schema exists so return values need no explanation, and annotations carry the safety signal. However, for a mutation that grants account access and is flagged destructive, the description omits permission requirements, invitation/email behavior, and role implications, leaving meaningful gaps.

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 each parameter (url, role enum, email, workspace_id) is documented in the schema, so the baseline is 3. The description adds no meaning beyond the schema — nothing about what each role grants or how workspace_id scoping affects the invitation.

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 plus the key nuance that this is an *invitation* ('Invite a new user to your account'), which separates it from plain record creation. It does not explicitly distinguish itself from siblings like add_contacts or update_user, so an agent must infer the boundary.

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

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

There is no when-to-use guidance, no prerequisite (e.g. admin permission), and no mention of alternatives such as update_user for existing members or get_all_users to check for duplicates. The agent is left to infer all routing decisions.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds that archiving removes the contact from active campaigns, but does not say whether the action is reversible, whether data is retained, or what happens to sequence enrollments — meaningful gaps for a destructive mutation.

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 the action and its effect; nothing wasted. It is arguably too short rather than too long, but structure is sound.

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?

An output schema exists, so return values need no explanation, and all three params are described in the schema. However, for a destructive mutation tool the description leaves reversibility and side effects (campaign/sequence impact) unstated, which is more than trivial for correct invocation.

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

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

Schema description coverage is 100%, so id, archived, and workspace_id are fully documented in the schema. The description only echoes the archive/unarchive duality that the archived flag already encodes, adding no new semantics.

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 pair (archive/unarchive) and resource (Contact) plus the effect of archiving ('remove from active campaigns'). It implicitly distinguishes itself from siblings like archive_list, archive_sequence, and archive_template by naming the resource, though it never explicitly names an alternative.

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

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

The effect ('remove from active campaigns') implies the use case, but there is no explicit when-to-use, no when-not-to-use, and no routing to near-neighbors such as remove_contact, move_lead, or unsubscribe_lead_from_sequence, which an agent could easily confuse with archiving.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false, so safety framing is partly covered. The description adds genuinely useful context the annotations lack: the operation is bidirectional (archive/unarchive) and its effect is a visibility change rather than deletion, which softens the scary 'destructive' flag. It does not mention permissions or confirmation requirements, 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?

Two tight clauses with the action front-loaded and the effect immediately after. Slight redundancy between the title echo and the 'Archive lists to...' clause, but no wasted padding.

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

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

An output schema exists, annotations cover the safety profile, and all three parameters are fully described in-schema, including the default and workspace fallback. Nothing an agent needs to invoke this correctly is missing.

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

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

Schema description coverage is 100% — id, the archived boolean with its default, and workspace_id fallback behavior are all fully documented in the schema. The description adds no parameter-level detail beyond that, so the baseline 3 applies.

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

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

States a specific verb pair and resource ('Archive or Unarchive a List') plus the effect ('remove them from active views'), which is far more informative than the title alone. It is distinguishable from update_list or delete-style siblings by name, though it never explicitly contrasts with 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?

The phrase 'to remove them from active views' implies when to archive (to hide rather than delete), so usage is inferable. However, there is no explicit when-not guidance and no pointer to the sibling that should be used for other list changes (e.g., update_list for renaming).

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false; the description adds value by naming the effect (pausing and hiding) and implicitly signaling reversibility through the unarchive option. It does not explain what happens to active leads/enrollments in the sequence or what permission is required, which matters for a destructive-flagged mutation.

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

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

Two short clauses, front-loaded with the action. There is mild redundancy between the title echo and the second clause, but no wasted sentences.

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

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

Wrong — recomputing: with an output schema present, 100% schema coverage, and annotations covering the safety profile, only the side effects on enrolled leads and the relationship to update_sequence_status remain unexplained. That gap is modest but real for a destructive toggling 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%, including the archived boolean's 'true to archive, false to unarchive' semantics and the workspace_id fallback, so the schema already carries the parameter meaning. The description adds nothing about how the archived toggle interacts with the described 'pause and hide' behavior, 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 verb pair (archive/unarchive) and resource (sequence), and adds the effect ('pause and hide them'). The resource name alone distinguishes it from archive_list, archive_template, and archive_contact, so no further sibling disambiguation is strictly required.

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 via 'to pause and hide them'. It never addresses when to use this versus pause-style siblings like update_sequence_status or unsubscribe_lead_from_sequence, nor does it state prerequisites such as needing the sequence not to be actively sending.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=false, so the agent knows this mutates state. The description usefully signals that the operation is bidirectional (unarchive exists), implying reversibility, but it does not say what archiving does to a template already used in sequences, nor correct the arguably harsh destructive=true framing for a reversible toggle.

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?

Very short and front-loaded, but the second clause 'Archive email templates' is redundant with the first and consumes roughly half the text without adding 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?

Output schema exists and all three parameters are documented, so the structured data carries most of the load. Still missing is any note on side effects (e.g. whether archived templates still render in sequences) that would matter for a destructive-flagged toggle.

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%: id, archived (default true), and workspace_id fallback behavior are all documented in the schema. The description adds no syntax, defaults, or semantics beyond that, 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 verb pair (Archive/Unarchive) and resource (Template/email templates), which lets an agent distinguish it from archive_list, archive_sequence, and archive_contact. The trailing 'Archive email templates' merely restates the verb+resource rather than adding scope.

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

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

No indication of when to archive versus using update_template, delete_*, or get_template, and no mention of prerequisites or alternatives among the many archive_* siblings. Usage is only inferable from the word 'Archive' itself.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and closed-world scope, so the safety profile is covered. The description adds nothing beyond that—no statement about what is returned when the address is absent, whether matching is exact or domain-level, or rate limits—so it contributes no 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?

It is short and front-loaded, which is good, but the two clauses duplicate each other and the tool name, so only one sentence's worth of content is doing real 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?

The tool is simple, an output schema exists, and annotations plus schema cover safety and both parameters, so the thin description is adequate. It stops short of the small amount of extra context (match semantics, meaning of a negative result) that would make it genuinely complete.

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

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

Schema description coverage is 100%, so both the email and workspace_id parameters are fully documented in the schema, establishing the baseline of 3. The description adds no extra meaning about parameter semantics such as exact-vs-substring matching or workspace scoping.

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 ("check whether an email is blocked"), but it largely restates the tool name and title rather than extending them. It implies a single-email lookup in contrast to the sibling get_blocklist, but never makes that distinction 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?

There is no guidance on when to use this versus get_blocklist, add_to_blocklist, or remove_from_blocklist, nor any mention of prerequisites. The agent must infer the scoping from sibling names alone.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, and the description adds nothing on top of that — it restates the title. It does not say whether the copy is active/paused, whether leads, stats or schedules are carried over, whether the original is modified, or how the copy is named.

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?

Very short and front-loaded, which is good, but the second clause ('Create a copy of an existing sequence') simply restates 'Clone a Sequence', so half the text does not earn 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?

An output schema exists so return values need not be explained, but for a mutating clone tool the description leaves key questions unanswered — resulting sequence state, what content is copied, and workspace fallback behavior — which the schema and annotations do not cover.

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 id and workspace_id are already documented in the schema, and the description adds no extra semantics such as whether the clone lands in the source sequence's workspace or the one supplied. 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 (clone/copy) and resource (sequence), which cleanly separates it from create_sequence (new) and get_sequence (read). It stops short of naming a sibling or stating what makes a clone different, so it is clear but not maximally 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?

No guidance on when to clone versus create_sequence or update_sequence, no preconditions, and no mention of how workspace_id selection interacts with the operation. The agent must infer all usage context.

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, destructiveHint=false, and openWorldHint=false, so the mutation/safety profile is covered. The description adds a useful constraint about the email-sender folder type, but says nothing about permissions, duplicate-name behavior, or what happens when workspace_id is omitted (beyond what the schema states).

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 the actionable content first. Minor waste in the redundant 'Create a Folder - Create a new folder' opening, which repeats the title and name.

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 low-complexity, 3-parameter tool with full schema coverage and an output schema, the description covers the essential caveat (folder type scoping). Only the absence of selection guidance against sibling create_* tools keeps it from being complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description restates the 'type' field restriction that the schema already documents verbatim, adding no syntax, format, or constraint details 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 and resource ('Create a new folder for organizing items'), so an agent immediately knows the operation. It does not explicitly contrast with siblings like get_all_folders or create_list, but the resource is distinct enough within the toolset.

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 never says when to use this tool versus alternatives (e.g., create_list, create_workspace) or what prerequisites exist (workspace selection, permission requirements). The only conditional guidance concerns the 'type' field, which is parameter behavior rather than tool-selection 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 declare readOnlyHint=false and destructiveHint=true, so the safety profile is covered, but the description adds little beyond them. It does not disclose that the test actually dispatches real emails, what side effects or costs that entails, or any rate/permission requirements, despite the openWorldHint flag.

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?

It is a single short, front-loaded line with no wasted words, but the brevity reflects under-specification rather than efficiency for a 13-parameter mutation tool. The tagline earns little place given the missing functional detail.

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 complex tool with 13 parameters, conditional content_type requirements, mutually exclusive senders, and a nested email_senders structure, a one-line description is inadequate. Even though an output schema exists, the description should explain the creation workflow and key constraints the agent must reason about.

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 13 parameters are already documented in the schema, including conditional requirements and mutual exclusions. The description contributes no additional parameter meaning, which matches the baseline 3 when the schema does the heavy lifting.

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

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

The description restates the tool name ('Create Inbox Placement Test') and adds only a tagline ('Test email deliverability across providers') that describes the test rather than the action. It does not state what is created or how it differs from siblings like get_inbox_placement_tests, pause_inbox_placement_test, or delete_inbox_placement_test.

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

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

There is no when-to-use guidance, no mention of prerequisites (e.g., needing senders or a source), and no reference to alternative tools. An agent gets no signal about the conditions that should lead it to call this versus inspecting existing tests with get_inbox_placement_tests.

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 cover the safety profile (readOnly=false, destructive=false, openWorld=false), so the bar is lower; the description adds real value by disclosing a data-provenance constraint on which contacts may enter the list and by describing the returned fields array. It stops short of noting failure modes or whether the call is idempotent.

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 sentences, purpose first, then the policy constraint, then response shape. The long provenance clause is dense but every sentence carries information an agent would otherwise lack.

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 annotations, full schema coverage and an output schema, the description only needs to supply policy and return-shape context, which it does via the consent-source rule and the fields array note. Minor gaps like workspace defaulting behavior are already in the schema.

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

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

Schema description coverage is 100%, so all seven parameters are already documented in the schema, and the description adds nothing about them. The mention of the response `fields` array is return-value context, not parameter meaning, so baseline 3 applies.

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

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

The description opens with a specific verb and resource: 'Create a new contact list,' which is distinct from sibling create_folder and from read siblings get_list/get_all_lists. It doesn't explicitly name an alternative, but the resource is unambiguous enough that an agent can route correctly.

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 substantive rule about acceptable contact provenance ('evidenced import or consent source'), which is implied usage guidance, but it never states when to reach for create_list rather than create_folder or create_workspace, nor any prerequisites like permissions or workspace scoping.

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 only say the tool is a non-destructive write with open-world effects. The description adds policy context they do not cover: recipients must come from the account holder's own consented audience and must never be addresses the model assembled, suppression and blocklist are always enforced, and sequences are created paused by default. It also spells out the consequence of launching, which is that emails get sent.

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 sentences, front-loaded with the purpose and then with the highest-risk constraints. The only waste is the redundant 'Create a Sequence -' prefix that restates the title.

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?

Given 36 parameters, 100% schema coverage, and an output schema, the description carries only the non-schema-recoverable policies, which it does well. Minor gap: it does not tie recipients to the required `lists` UUID parameter, so the agent must connect the consent rule to that field on its own.

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

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

Schema description coverage is 100%, so every one of the 36 parameters, including launchTimingMode, confirm, and send_as nesting, is already documented inline. The description adds only the paused-by-default behavior, without extra argument formats. That baseline 3 is appropriate when the schema carries the parameter burden.

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

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

It states a specific verb and resource: 'Create a new email sequence/campaign.' That clearly separates it from read/update siblings, but the family of adjacent write tools (clone_sequence, update_sequence, update_sequence_status) is not named, so differentiation has to be inferred from the verbs alone.

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 an explicit precondition for the risky path: launching may happen only after explicit user confirmation. However, it never says when to prefer clone_sequence over create_sequence, or when to use update_sequence on an existing sequence instead. Usage is clear within the call, but not relative to alternatives.

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

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

Annotations already declare readOnlyHint=false, destructiveHint=false and openWorldHint=false, so the write-but-non-destructive profile is covered. The description adds the connector limitation on attachments, but says nothing about error behavior (e.g. duplicate names), permissions, or what the agent gets back — though an output schema exists.

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

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

Two short sentences, front-loaded with the action and followed by a genuine constraint. The opening "Create a Template -" partially restates the title before the useful clause, which is minor waste but not damaging.

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?

An output schema exists and all seven parameters are fully described, so the description needn't explain return values or param formats. It covers the one non-obvious behavioral constraint (attachments) that the schema also flags; nothing essential for calling the tool is missing.

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

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

Schema description coverage is 100%, so every parameter including the folder-typing constraint and the attachments limitation is already documented in the schema. The description adds no parameter-level meaning beyond what the schema provides, which is the baseline case.

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 concrete verb+resource ("Create a new email template"), which is more specific than the title's bare "Template" and separates it from update_template/get_template/archive_template by verb. It does not explicitly name siblings or contrast scope, so it stops short of a 5.

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

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

The create verb implies the when (making a new template rather than editing an existing one via update_template), and the attachment caveat routes the agent to the web app for files. There is no explicit statement of prerequisites, workspace scoping, or when to prefer an alternative tool.

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

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

Annotations already disclose write-type, non-destructive, closed-world behavior, so the bar is lower. The description adds the useful 'owner only' permission constraint, but says nothing about duplicate-name handling, workspace limits, or whether creation switches the active workspace.

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 short line with the action front-loaded and no filler. It is appropriately sized for what it says, though that is largely because it says very little.

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

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

For a mutation tool that creates a top-level resource, the description omits the things an agent most needs: idempotency/duplicate behavior, the effect on the caller's active workspace, and any post-conditions. The presence of an output schema offsets return-value concerns but not these gaps.

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 already documented, and the baseline is 3. The description adds no meaning about why workspace_id/workspaceName appear on a create operation, which is the schema's most confusing aspect.

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 verb plus resource ('Create a new workspace'), so the action is identifiable, but the phrasing is nearly a restatement of the title 'Create Workspace' and offers no differentiation from siblings such as list_my_workspaces, get_all_workspaces, select_workspace, or update_workspace.

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?

'(owner only)' gives one precondition for use, but there is no guidance on when to create vs. select an existing workspace, what happens if one already exists, or how this relates to the sibling workspace 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 destructiveHint=true and readOnlyHint=false, so the safety profile is known. The description adds meaningful context beyond that: the consequence is immediate breakage of any live integration and a user-confirmation gate. It does not say whether revocation is reversible or how to recover a mistakenly deleted key.

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

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

Two sentences, zero waste, and the consequence/confirmation requirement is front-loaded where an agent will see it before acting.

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 three-parameter tool with annotations and an output schema, the description covers the essential risk and the confirmation gate. Minor gaps remain around reversibility and the workspace_id default, which the schema states but the description never reinforces.

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

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

Schema coverage is 100%, and the schema already documents id, confirm, and workspace_id thoroughly. The description reinforces the confirm requirement but adds no syntax, ID-source, or workspace-scoping detail beyond the schema, so the baseline of 3 applies.

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

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

States a specific verb+resource ('Revoke an API key') and clarifies that delete means revoke, which is more precise than the tool name alone. It is clearly distinguishable from read-side siblings such as get_api_keys and get_api_key_refresh_link.

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

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

Gives a clear precondition — explicit user confirmation is required before calling — which frames when this tool is appropriate. It does not name alternatives (e.g., listing keys first with get_api_keys) or state when-not-to-use, 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 destructiveHint=true and readOnlyHint=false, so the description doesn't need to disclose that this is destructive. It goes beyond the annotations by stating the practical consequence of removal (the address becomes eligible for outreach again) and by restating the confirmation requirement, which adds real context about the side effect.

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

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

Two sentences, front-loaded with the action and then the consequence and the precondition. The opening clause slightly restates the title ('Delete Blocklist Entry by ID'), which is mildly redundant, but the rest of the text is efficient.

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 destructive single-record delete with a full schema and an output schema, the description covers the side effect and the confirmation requirement. The main gap is not distinguishing this tool from the sibling remove_from_blocklist, so the agent could pick the wrong 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 description mentions 'by its ID' but adds no syntax, format, or meaning beyond what the schema already documents for id, confirm, and workspace_id.

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 and resource: 'Delete Blocklist Entry by ID - Remove a single blocklist entry by its ID.' It's clear what it does, but the sibling remove_from_blocklist is not mentioned, so an agent must infer the difference between deleting a blocklist entry record and removing an address from the blocklist.

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 names one precondition (explicit user confirmation) and the consequence of deleting (address becomes eligible for outreach again), which implies when it's appropriate. It doesn't say when to prefer remove_from_blocklist or add_to_blocklist, so the sibling routing is left to inference.

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

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

Annotations already declare destructiveHint=true and readOnlyHint=false. The description adds useful context beyond annotations by stating that deletion cannot be undone and requires explicit user confirmation, though it could also mention permission requirements or associated data effects.

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

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

Two short sentences, front-loaded with the action and followed by the key constraint. No unnecessary words.

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 destructive delete with full schema coverage, an output schema, and annotations covering safety, the description supplies the essential confirmation and irreversibility context. Nothing further is needed for correct invocation.

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

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

Schema description coverage is 100%, so the schema already documents id, confirm, and workspace_id. The description adds no parameter-specific meaning beyond the confirmation precondition, so 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?

The description states a specific verb ('Delete') and resource ('Inbox Placement Test'), clarified as 'a deliverability test.' This clearly distinguishes it from siblings like create_inbox_placement_test and pause_inbox_placement_test.

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 states a confirmation prerequisite but does not explicitly say when to use this tool versus alternatives such as pause_inbox_placement_test. Usage is implied by the destructive nature, but no exclusions or alternatives are 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, destructiveHint=false and closed-world, so an export being a safe read is covered. The description adds one genuine piece of new behavior: the result is CSV. It says nothing about size, cost, or the default 10k / max 50k cap that matters for a bulk export.

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?

It is short, but the first clause just echoes the name and title, so the sentence is mostly redundant rather than front-loaded with useful content. Only 'as CSV' 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 an output schema present, return-shape explanation is not required, but the description still leaves out how this differs from get_sequence_leads and what a bulk export entails (size, time, truncation at limit). For a tool an agent must choose over a sibling, that is a meaningful 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 description coverage is 100%, so the schema already documents id, limit (default 10000, max 50000) and workspace_id fallback behavior. The description adds no parameter meaning beyond that. Baseline 3 applies when the schema carries the parameter burden.

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

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

The description restates the tool name/title almost verbatim ('Export Sequence Leads - Export sequence leads as CSV'). The only new information is the output format (CSV), which hints at how it differs from get_sequence_leads, but the tool's actual scope (which leads, what columns, per-sequence) is never 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?

No when-to-use guidance is given. The sibling list contains get_sequence_leads, which is the obvious alternative, and the description does nothing to explain when an agent should export versus read leads via that tool. Nothing about prerequisites (sequence must exist, workspace scoping) is mentioned.

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 establish that this is a safe read-only, non-destructive, closed-world operation. The description adds useful behavioral context beyond the annotations: it returns both sent emails and received replies, caps results at 50 messages, and supports pagination via 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?

The description is a single, front-loaded sentence with no wasted wording. It states the core action, scope, result limit, and pagination mechanism efficiently.

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

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

With rich structured metadata (100% schema coverage, annotations, and an output schema), the description covers the essential purpose, result limit, and pagination. It is complete enough to call correctly, though it could be stronger with explicit alternative-tool routing.

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 input schema already documents all three parameters including ids, skip, and workspace_id. The description reinforces pagination via skip but does not add parameter meaning beyond the schema, so the baseline 3 is appropriate.

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

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

The description uses a specific verb and resource: retrieve sent emails and received replies across multiple senders. It clearly implies a bulk/multi-sender scope that differs from the singular fetch_sender_messages sibling, but it does not explicitly name or route to that alternative.

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

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

Usage is only implied by 'Bulk Fetch' and 'across multiple senders.' The description mentions the max 50 limit and skip-based pagination, but it does not explicitly say when to use this tool instead of fetch_sender_messages or other message-fetching siblings.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral fact beyond that — the 50-message result cap and the skip-based pagination pattern — but says nothing about ordering, completeness of the sent/replies union, or truncation behavior when the cap is hit.

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 tight sentence with the pagination constraint placed where an agent will see it. The leading restatement of the title ('Fetch Sender Messages -') is redundant, which keeps it just short of a 5.

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

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

An output schema exists so return values need no explanation, and the schema fully documents the inputs. What is missing for a tool with a very similar sibling is any disambiguation from fetch_multiple_sender_messages, which is the main decision an agent has to make here.

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

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

Schema description coverage is 100%, and all three parameters (id, skip, workspace_id) are documented in the schema, so the baseline of 3 applies. The description only restates the pagination role of skip and adds nothing about defaults or the workspace fallback that the schema does not already convey.

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 with scope: retrieves both sent emails and received replies for a single sender. This is clear, but it does not distinguish the tool from the sibling fetch_multiple_sender_messages, leaving the singular-vs-multiple distinction to inference.

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 only usage guidance is operational: results are capped at 50 and 'use skip for pagination'. There is no statement of when to choose this over fetch_multiple_sender_messages or other message-reading siblings like get_thread_messages or get_lead_messages, so the usage context is only implied.

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

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true, so safety profile is covered. The description adds a genuinely useful constraint – attachments are unsupported and file paths cause an error – but says nothing about irreversibility of sending or how scheduling affects delivery.

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

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

Two short sentences, front-loaded with the action and followed by the key operational caveat. No filler, though it spends its second sentence on a constraint the schema already repeats.

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?

An output schema exists, so return values need not be described, and annotations carry the safety profile. However, for a 10-parameter mutation tool with scheduling and timezone options, the description leaves the forward-vs-reply decision and delivery timing behavior unexplained.

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 10 parameters are already documented in the schema, including defaults for email/content and tzMode. The description adds only the attachments caveat, which the schema itself also states, 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 verb and resource ('Forward an email to another recipient'), which clearly separates it from mutating siblings like update_lead or archive_contact. It doesn't explicitly distinguish itself from send_reply, the closest sibling, but the action 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?

No guidance on when to forward versus send_reply, no mention of prerequisites (sender connectivity, workspace selection), and no exclusions. The only constraint given is about attachments, which is a limitation rather than usage 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=false, destructiveHint=false and openWorldHint=false, so the agent knows this is a non-destructive, closed-world mutation. The description adds that the link is time-limited, which is useful context, but it does not disclose that the result is a credential granting account access, nor any sensitivity, revocation, or rate-limit behavior. Given annotation coverage of the safety profile, a 3 is appropriate.

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 compact sentence, front-loaded with the core action. The 'Generate Login Link -' prefix restates the title and is mildly redundant, which keeps it from a 5.

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

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

An output schema exists, so return-value explanation is not required, and the schema itself covers all three parameters. But for a security-sensitive link generator, the description leaves out sibling differentiation and the fact that the output is a login credential with limited lifetime. Adequate but with clear gaps.

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%: redirect_url, workspace_id and expiry_minutes are all documented in the schema, including defaults and the 1–30 minute range. The description adds no parameter meaning beyond that, so baseline 3 is correct when the schema does the heavy lifting.

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

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

States a specific verb and resource: 'Create a time-limited magic login link for the authenticated user.' That is unambiguous about what the tool produces. It does not distinguish itself from similar-sounding siblings such as get_add_card_login_link or get_sender_connect_link, so it stops short of a 5.

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

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

The description gives no guidance on when to use this tool versus alternatives, and no prerequisites or exclusions. 'For the authenticated user' implies the caller context but doesn't tell the agent when this is the right choice over sibling link-generators.

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 indicate this is not read-only, not destructive, and not open-world. The description adds the domain-specific purpose of adding a payment card, but does not disclose token expiry, one-time use, permission requirements, or other behavioral details an agent might need.

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 description is short and front-loaded, with no extraneous sentences. It does repeat the title almost verbatim, which is slightly redundant but not harmful.

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?

An output schema exists, so return values need not be explained. However, for a non-read-only link-generation tool, the description lacks usage guidance and key behavioral context such as link lifetime or security constraints.

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 single workspace_id parameter is fully described in the schema, including behavior when omitted. The description does not add any parameter semantics, but with 100% schema coverage the baseline score of 3 is appropriate.

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

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

The description states a specific action and resource: generating a magic login link to add a payment card. It is clear enough to distinguish from many siblings, though it does not explicitly contrast with nearby tools like generate_login_link or get_remove_card_login_link.

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

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

The description implies the link is used to add a card, but gives no explicit guidance on when to use this tool versus generate_login_link, get_remove_card_login_link, or related login-link tools. No prerequisites or exclusions are 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, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds domain context about what each folder type contains, but nothing about pagination behavior, result size, or how search interacts with the type filter.

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

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

Two sentences, front-loaded with the core action, and no filler. The folder-taxonomy sentence is useful but partially duplicates the enum description already present in 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 a full output schema, 100% parameter coverage, and complete annotations, the description supplies enough context to call the tool correctly. Only minor gaps remain around search/filter interaction and pagination 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 coverage is 100%, so the baseline is 3. The description adds a small amount of meaning beyond the schema by explaining that general folders hold lists, templates, and sequences, but the enum semantics it describes are already in the schema's 'type' documentation.

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

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

The description states a specific verb and resource ('Retrieve all folders') and explains the folder taxonomy, which helps distinguish it from siblings like get_all_lists and get_all_senders. It stops short of naming those siblings or explicitly saying when to prefer 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: it says the tool retrieves all folders and that a type filter exists, but gives no guidance on when to use this versus get_all_lists/get_all_senders or when to paginate. No exclusions or prerequisites are 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?

Beyond the readOnly/destructive annotations, it discloses a non-obvious caveat: boolean starred/archived filtering is unreliable, which prevents a plausible agent failure. It also describes the shape of the returned data (a `fields` array of snake_case column names), adding useful read-side 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?

Three sentences: purpose, caveat, return shape — the most decision-relevant item (filter reliability) is placed before the filter inventory. Nothing superfluous beyond the mild title echo at the start.

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 8 optional params, an output schema present, and safe read annotations, the description covers what the agent needs: filter semantics, a reliability warning, and return field format. Minor gaps are pagination defaults and the valid sortBy/sortType values, though those are already documented in the schema.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real value by naming the exact supported filter set (folder, search, sortBy, sortType, integration) and flagging that boolean filters are not reliable — information the schema's field descriptions do not convey.

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 (Retrieve) and resource (all contact lists) plus the filtering capability, so the agent knows exactly what it returns. It does not differentiate from the sibling get_list (single list) or from create/update/archive_list, leaving that inference to the agent.

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

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

Enumerating the supported filters implies the browse/discovery use case and the "Note: boolean filters (starred/archived) are unreliable" line steers away from a failing path. However, it never says when to prefer this over get_list for a single record, nor any preconditions.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds the useful behavioral detail that results are a flat list rather than grouped by folder, but it does not mention pagination behavior, default limit, or workspace scoping beyond what the schema 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?

The description is a single front-loaded sentence with no wasted words. The key resource and the flat-list distinction are stated immediately.

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?

An output schema exists and parameter semantics are fully documented, so the description does not need to explain return values. The only minor gap is that “Retrieve all” could imply an unpaginated complete list, while the schema shows default limit and pagination behavior; the description does not mention this caveat.

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 skip, limit, filter, folder, search, and workspace_id are already documented in the input schema. The description does not add meaning beyond the schema, which matches the baseline of 3 when structured parameter documentation is complete.

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: retrieve email sender accounts. It also clarifies the result shape as a flat list not grouped by folder, which helps distinguish it from folder-oriented listing tools. It does not explicitly name a sibling alternative, so it falls short of the highest clarity tier.

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 “Retrieve all email sender accounts” implies the tool is for listing senders, and “flat list, not grouped by folder” gives useful scope context. However, there is no explicit when-to-use guidance, no when-not-to-use guidance, and no named alternative such as get_sender_health or get_all_folders for related tasks.

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 establish readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious behavioral context: that boolean filters (starred/archived) and owned_by are unreliable — information an agent could not get from any structured field.

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

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

Two sentences, front-loaded, zero filler. Mild redundancy in restating the tool title as the opening clause, but the warning is placed where an agent will see it immediately.

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?

An output schema exists, so return shape need not be explained, and all nine parameters are documented in the schema. The description covers the one thing the schema cannot: filter reliability. A note on how 'Supported filters' relates to pagination params would close the remaining gap.

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

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

Schema description coverage is 100%, so baseline is 3. The description earns above baseline by flagging filter reliability and enumerating supported filters, but its list omits skip, limit, and workspace_id — arguably pagination rather than filtering, yet it leaves the reader to infer that relationship.

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 ('Retrieve all sequences') with the scoping qualifier 'with optional filtering'. The word 'all' implicitly separates it from the single-item get_sequence sibling, 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 'Supported filters' list tells the agent which parameters are meaningful, and the reliability note steers it away from broken filters. However, there is no explicit guidance on when to prefer this tool over get_sequence or get_sequence_leads, so routing is only implied.

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

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

The note that boolean filters (starred/archived) are unreliable is genuine behavioral disclosure that annotations do not and cannot carry, which is valuable. However, those filters do not exist in the schema (additionalProperties: false, 9 params, none named starred/archived), so the warning is partly moot and risks confusing the agent. Nothing is said about the 100-result cap or what happens beyond it.

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

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

Two tight sentences with the purpose front-loaded and the caveat following immediately. There is minor redundancy between the title echo 'Get All Templates' and 'Retrieve all email templates', but 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?

An output schema exists, so return values need no explanation, and the schema covers pagination parameters. Still missing is any mention of the silent 100-result ceiling that would tell an agent to paginate with skip, and the filter caveat references parameters that do not exist. Adequate but with a real gap for a 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 schema already documents all nine parameters including defaults and the max limit. The description only restates a subset of filter names (folder, type, taskType, search, sortBy, sortType) and omits skip, limit, and workspace_id, adding no syntax or semantics beyond 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: retrieve all email templates with optional filtering. An agent can distinguish this from get_template (single fetch), but the description never names that sibling to make the distinction explicit.

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

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

Usage is only implied by 'retrieve all ... with optional filtering' and the list of supported filters. There is no explicit statement of when to use this versus get_template, nor any guidance on prerequisites or workspace scoping.

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, destructiveHint=false, openWorldHint=false), so credit goes to the added caveat that the endpoint ignores pagination and filtering and returns the entire user set — a real behavioral trait (result size, no batching) an agent needs. The value is slightly undercut because it describes parameters that do not exist in the schema, which can mislead.

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 key constraint is front-loaded in a single short 'Note:' sentence and nothing is padded. Minor waste in restating the title verbatim before the useful content.

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 an output schema present, return values need no explanation, and the description covers the main surprise (no pagination or filtering despite parameters). A brief note on workspace scoping or result size expectations would close the remaining gap.

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

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

Schema coverage is 100% and the single workspace_id parameter is fully documented there, so baseline 3 applies. The description adds no meaning to workspace_id and instead references pagination/filtering parameters that are absent from the schema, which is neutral-to-confusing rather than additive.

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 ('Retrieve all users in the account') and emphasizes scope with 'every user in the account', which implicitly separates it from the singular get_user sibling. It never names get_user explicitly, so the differentiation is inferable rather than stated.

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

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

Usage is only implied by the word 'all' — an agent can infer this is the list-everything path versus get_user for a single record, but the description never says when to prefer one over the other or what prerequisites (e.g. admin permissions) apply.

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 (readOnly, non-destructive, closed-world), and the description usefully adds the owner-only authorization constraint. It does not explain why a 'get all' operation takes a workspace_id scope, which leaves the caller's effective scope ambiguous.

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 short sentence with the scope qualifier front-loaded and no filler. The only waste is the leading 'Get All Workspaces -' prefix, which merely restates the tool name.

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 an output schema, full annotation coverage and a fully documented single parameter, the structural burden is low and mostly met. The remaining gap is routing: nothing in the description lets an agent separate this tool from its near-identical sibling list_my_workspaces.

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 there is only one optional parameter, so the schema itself explains workspace_id and the default-workspace fallback. The description adds nothing on top of it, which is the baseline for full coverage.

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 (retrieve workspaces) and a scope qualifier ('all accessible', 'owner only'). However, it never distinguishes itself from the sibling list_my_workspaces, which reads as the same operation, so an agent cannot tell which one to pick from the description alone.

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?

'(owner only)' is a genuine usage precondition that narrows who should call it. Beyond that there is no guidance on when to prefer this over list_my_workspaces, select_workspace, or create_workspace; the choice is left to inference.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. Beyond that, the description adds nothing: it doesn't say what a 'day' bucket covers, what the default time window is if from/to are omitted, or how aggregation works across workspaces. For a reporting tool with zero required params, that default behavior is exactly what needs disclosure.

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?

It is a single short phrase with no filler and the key idea (day-wise stats) is front-loaded. It is underspecified rather than bloated, so brevity here is not penalized heavily.

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?

An output schema exists so return values need not be explained, and the input schema is fully documented. But the description leaves the crucial ambiguity unresolved: how this differs from get_analytics_overall and what happens with no date range, which matters for a tool where every parameter is optional.

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

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

Schema description coverage is 100%, so all four parameters (to, from, timezone, workspace_id) are documented in the schema itself. The description adds no extra meaning about the timestamp format, timezone effect on day bucketing, or the workspace fallback, so it stays at the baseline for high schema coverage.

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 says it returns day-wise overall stats, which is slightly more specific than the title and hints at daily granularity. However, it never distinguishes itself from the many analytics siblings (get_analytics_overall, get_analytics_lead_stats, get_analytics_mailbox_stats), so an agent cannot tell which one to pick from the text alone.

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 get_analytics_overall or the other analytics tools, and no mention of defaults when from/to are omitted (all parameters are optional). The agent must infer usage from 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, destructiveHint=false, openWorldHint=false, so the safety profile is covered structurally. The description adds nothing beyond that — no mention of aggregation granularity, whether results are paginated, or how the date range interacts with lead scope.

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 text is short but that brevity comes from under-specification, not economy — it is two near-duplicate fragments separated by a dash. Nothing is front-loaded beyond the redundant name echo.

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?

An output schema exists, so return values need not be explained, but the description still fails to tell the agent what distinguishes this engagement-level analytics endpoint from its many siblings. For a zero-required-param analytics query in a crowded namespace, that leaves the agent without the context needed to select 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%, with all five parameters (from/to/skip/limit/workspace_id) documented in the schema. The description adds no meaning beyond that, so the baseline of 3 applies.

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

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

The description 'Get Lead-level Analytics - Lead-level stats' is a tautology that merely restates the tool name and title. It never says what a 'lead stat' contains (opens, clicks, replies, per-lead aggregates) or how it differs from the many sibling analytics tools such as get_analytics_overall, get_analytics_daily, get_analytics_mailbox_stats, or get_sequence_stats.

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

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

There is no when-to-use guidance, no exclusions, and no mention of the adjacent analytics siblings an agent must choose between. An agent has no basis from the description for preferring this tool over get_analytics_overall or get_sequence_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=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: no indication of what 'overall' aggregates, over what default period when from/to are omitted, or whether skip/limit meaningfully paginate an aggregate result.

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

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

It is short and front-loaded, but the two halves say the same thing, so the second clause does not earn its place. Brevity here reflects thin content rather than disciplined editing.

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?

An output schema exists, so return values need not be explained, and the schema fully documents the parameters. The remaining gap is disambiguation from the sibling analytics tools, which the description should supply but does not.

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% across all five parameters, so the schema carries parameter meaning and a baseline 3 applies. The description contributes no semantics of its own, notably nothing about the default time window when from/to are absent.

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 names a verb and a resource (mailbox analytics), so the basic purpose is intelligible, but the second clause ('Overall mailbox stats') merely restates the first. It gives no basis for choosing between this and the sibling analytics tools get_analytics_overall, get_analytics_daily, or get_analytics_lead_stats.

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

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

There is no when-to-use guidance, no mention of prerequisites, and no reference to any alternative. With three sibling analytics tools in the list, an agent is left to guess which one answers a given question.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds only that stats span all sequences; it says nothing about date-range defaults or aggregation behavior, so it adds limited value beyond the structured fields.

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?

Extremely short and front-loaded with the resource name, but it is so terse that the second half ('Overall stats across all sequences') mostly restates the title. It is concise but under-informative rather than efficient.

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 output schema exists, so return values need not be described, and annotations cover safety. What is missing is differentiation from the crowded analytics sibling set, which is the main thing an agent needs in order to choose this tool correctly.

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

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

Schema description coverage is 100% and all three parameters (from, to, workspace_id) are documented in the schema with formats. The description adds no parameter-level meaning beyond the schema, so baseline 3 applies.

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

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

Names a specific verb+resource ('Get Overall Analytics') and scopes it to 'across all sequences', which partly separates it from get_sequence_stats. However, 'Overall stats' is vague about what metrics are actually returned, and it does not clearly distinguish itself from the many other analytics 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?

No guidance on when to use this instead of get_analytics_daily, get_analytics_lead_stats, get_analytics_mailbox_stats, or get_sequence_stats. The 'all sequences' scope implies a difference but the agent must infer it.

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 establish readOnly, non-destructive, closed-world behavior, so the safety profile is covered. The description adds that the return value is a magic login link, which is useful behavioral context, but says nothing about link expiry, sensitivity, or whether requesting it has side effects.

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

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

A single sentence with the key information front-loaded and no filler. It only mildly wastes space by restating the tool title before the dash.

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?

An output schema exists, so return-value details need not be described, and annotations cover the safety profile. For a simple link-retrieval tool this is nearly complete, though a note on link lifetime or the distinction from the refresh-link sibling would close the remaining gap.

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

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

Schema description coverage is 100% and the sole workspace_id parameter is fully documented there, including the default-workspace fallback. The description adds no parameter guidance beyond what the schema already provides, so the baseline of 3 is appropriate.

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

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

States a specific artifact (a magic login link to the API keys page) and its intended use (so the user can create a new API key). It is distinguishable from get_api_keys and delete_api_key, though it never explicitly contrasts itself with the similarly named get_api_key_refresh_link.

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 'where the user can create a new API key', which gives the agent a reasonable trigger condition. It does not state when to prefer this over get_api_key_refresh_link or generate_login_link, nor any prerequisite or exclusion.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful context that the output is a 'magic login link', but omits whether the link is single-use, expiring, or requires auth, which matters for a credential-bearing URL.

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 no filler. It echoes the tool title at the start ('Get API Key Refresh Link -'), which is mild redundancy but not harmful.

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?

An output schema exists so return values needn't be explained, and the param is fully covered. The remaining gap is disambiguation from near-identical siblings (get_api_key_page_link, generate_login_link), which the description leaves entirely 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 the single workspace_id parameter is fully documented in the schema, including default-workspace behavior when omitted. The description adds nothing beyond that, 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?

A specific verb-plus-resource statement: it returns a magic login link to the API keys page for refreshing an existing API key. However, it never distinguishes itself from close siblings such as get_api_key_page_link, generate_login_link, or get_add_card_login_link, which sound interchangeable.

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

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

Usage is implied by the phrase 'where the user can refresh an existing API key', but there is no explicit when-to-use, when-not-to-use, or pointer to the obvious alternative get_api_key_page_link. The agent must guess which link tool applies.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description still adds substantive behavior: keys are masked to first/last three characters and full values are never returned. That is exactly the kind of constraint that prevents an agent from calling this tool expecting exportable credentials.

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?

Purpose is front-loaded and the masking warning follows immediately. The second sentence is long and carries a parenthetical cross-reference, but every clause (masking rule, example, no full keys, alternative path) 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?

An output schema exists, so return shape needn't be explained; the description instead covers the non-obvious part an agent cannot get from the schema — that returned keys are masked and where to obtain full values. Adequate for a zero-required-parameter read tool.

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

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

Schema description coverage is 100% and the single optional workspace_id is fully documented in the schema, so baseline 3 applies. The description adds no additional semantics about workspace scoping or what 'all keys' means per workspace.

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 ('Retrieve all API keys for the account') and immediately scopes the result set. An agent can distinguish it from delete_api_key or get_api_key_page_link 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?

Explicitly says when this tool is insufficient ('full key values are never exposed by this tool') and routes the agent to the correct alternative tools (get_api_key_page_link / get_api_key_refresh_link) plus the manual path. Nothing is left to inference.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered structurally. The description adds essentially nothing beyond that — no mention of pagination behavior, default page size, or what a returned entry looks like — so it contributes little new 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 short, front-loaded line with zero filler or repetition. It is not padded, though it is so terse that it borders on restating the title rather than informing.

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

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

Because an output schema exists and parameter coverage is complete, the description need not explain returns or fields. However, for a list tool sitting among several blocklist-related siblings, the missing disambiguation of when to call this versus check_blocklist leaves a real 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 description coverage is 100%: skip, type, limit, search, and workspace_id are all documented, including the skip/limit multiple rule and the 100 cap. The description adds no parameter meaning on top of the schema, so the baseline of 3 applies.

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

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

The description gives a specific verb (Get/List) and resource (blocklist) plus the entry types returned (blocked emails and domains). It does not explicitly distinguish itself from close siblings like check_blocklist, add_to_blocklist, or remove_from_blocklist, so the agent must infer that this is a read of the full list.

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

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

There is no when-to-use guidance, no exclusions, and no named alternative to check_blocklist (single-value lookup) or get_leads. The agent is left to infer usage purely from the tool name and the sibling list.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds genuinely useful context beyond that: the output is a 'magic login link', i.e. a sensitive credential-like artifact routed to an external UI page. It does not mention link expiry, one-time use, or auth requirements, which matter for a magic link.

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 that front-loads the returned artifact and its destination, with no filler. Minor redundancy in restating the tool title verbatim as a prefix, but the cost is small.

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?

An output schema exists, so return-shape explanation is not required, and the description nonetheless identifies the key returned artifact concept. For a zero-required-parameter link getter with full annotation coverage, the definition is complete enough to invoke 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?

Only one optional parameter (workspace_id) with 100% schema description coverage, so the schema already carries the meaning, including the default-workspace fallback. The description adds nothing further about parameter behavior, which matches the baseline for full coverage.

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 Bulk Senders Upload Link') and explains the outcome: a magic login link to the email-sender connection page for bulk CSV uploads. It is distinguishable from get_sender_connect_link by the 'bulk CSV upload' framing, though it never names that or any other sibling explicitly.

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

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

Usage is implied by the stated outcome (user wants to upload senders in bulk via CSV), which is enough to infer intent. There is no explicit guidance on when to prefer this over get_sender_connect_link, generate_login_link, or get_all_senders, and no prerequisites 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?

The annotations already fully define the tool as a read-only, non-destructive operation. The description adds no extra contextual behavioral traits beyond repeating the function name.

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?

It is extremely concise, but the structure is redundant ('Get Clicks Activity - Get list of link clicks'). It could be improved by front-loading the scope instead of repeating the name.

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?

Given the complexity of the API and the large number of 'get' activity tools in the sibling list, a single, brief sentence is insufficient. It provides almost no context on what the resulting list contains or how it differs from related endpoints.

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?

Since schema coverage is 100%, the baseline score of 3 applies. The description adds no semantic value or special constraints to the parameters that are not already defined 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?

The description states the tool fetches a list of link clicks, which is clear. However, it is highly generic and does not distinguish how this activity relates to other similar tools in the sibling list, such as those focused on 'opens' or 'sent' activity.

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 provides no guidance on when to use this tool versus alternatives. It simply defines the resource it handles without providing context on scope or use cases.

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

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

The annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds useful behavioral context by noting that unverified domains are included along with DNS setup instructions and status tags. However, it does not discuss pagination behavior, workspace access assumptions, or other operational details beyond what annotations and schema provide.

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 description is a single efficient sentence and front-loads the core retrieval purpose. The only minor waste is the redundant 'Get Custom Domains -' prefix, which largely restates the title.

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 complete schema descriptions, read-only annotations, and an output schema, the description supplies enough context about what is returned, including unverified domains and DNS setup details. Usage guidance remains the main gap, but the definition is otherwise complete for correct invocation.

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

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

Schema description coverage is 100%, so skip, limit, and workspace_id are already documented in the input schema. The description only indirectly reinforces the workspace scope and adds no new semantics for pagination or workspace selection. Baseline 3 is appropriate when the schema fully carries parameter meaning.

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

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

The description states a specific verb and resource: 'Retrieve custom tracking domains for the workspace.' It also clarifies that unverified domains and DNS setup/status details are included, which makes the scope more precise. It does not explicitly differentiate from any sibling, though none of the listed siblings appears to cover custom domains.

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 explains what the tool retrieves but gives no guidance on when to use it, when not to use it, or which alternatives to prefer. The implied use case is clear only because the tool name is self-explanatory, not because the description provides usage rules.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds only the 'deliverability tests' gloss and nothing about pagination behavior, workspace scoping, or which tests are returned (e.g. all workspaces vs current), so it contributes almost nothing 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?

A single front-loaded sentence with zero filler, and the distinguishing read-all scope comes first. It is efficient, though its brevity borders on under-specification rather than tight conciseness.

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

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

An output schema exists, all four parameters are documented in the schema, and annotations cover the safety profile, so the description does not need to explain return values. What is missing is any routing guidance among the four inbox-placement sibling tools, but for a simple read-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%, with skip, limit, owned_by, and workspace_id all documented in the schema, so the baseline of 3 applies. The description adds no additional parameter meaning, such as that owned_by requires admin/owner rights or how pagination should be driven.

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 ('Retrieve all') and resource ('Inbox Placement Tests'), and the gloss 'deliverability tests' tells an agent what these tests actually are. It distinguishes itself from siblings like create_inbox_placement_test and delete_inbox_placement_test by being the read-all operation, though it never names them 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 create_inbox_placement_test, pause_inbox_placement_test, or delete_inbox_placement_test, and no exclusions or prerequisites. An agent must infer usage purely from 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 establish this as a safe, non-destructive, closed-world read, so the bar is lower. The description adds a genuinely non-obvious behavioral fact outside the schema: only eight parameters are actually applied by the API, implicitly warning that workspace_id is silently ignored. It stops short of saying what happens if an unapplied parameter is supplied, or how the results are ordered/paginated.

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

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

Two short sentences, front-loaded with the action before the caveat, with no filler. The leading repetition of the tool name is slightly redundant but costs almost nothing.

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?

An output schema exists, so return values need no explanation, and the parameter surface is fully documented in the schema. The remaining gap is behavioral precision around the ineffective workspace_id parameter and no disambiguation from sibling message-retrieval 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%, so the baseline would be 3; the note earns an upgrade because it flags that a documented parameter (workspace_id) has no effect at the API layer, which the schema does not reveal. It still does not explain the accepted timestamp format for date or the semantics of sender IDs beyond what the schema says.

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 ('Retrieve inbox threads') plus a modifier ('with optional filtering'), so the action is unambiguous. It does not, however, distinguish this from close siblings such as get_thread_messages, get_lead_messages, or fetch_sender_messages, which an agent could easily confuse it with.

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

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

There is no when-to-use guidance and no named alternative, despite several plausibly overlapping siblings in the same inbox/message space. The only usage-adjacent signal is the note about which filters are honored, which is a constraint rather than a selection rule.

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, openWorldHint=false, and destructiveHint=false, so the safety profile is covered. The description adds no extra behavioral context such as pagination behavior, default result ordering, or what happens when the email matches no lead. Modest value given annotation coverage.

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 the key differentiation front-loaded. The title text is echoed at the start, which is slightly redundant but overall efficient and well-structured.

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?

An output schema exists, so return values needn't be explained, and the schema documents all 7 parameters. For a filtered read tool, the description plus structured fields cover what an agent needs, though it could note the email-vs-id resolution 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 coverage is 100% and every parameter (from, to, skip, limit, sequence_id, workspace_id, email) is documented in the schema itself. The description adds nothing beyond the schema, so the baseline of 3 is appropriate.

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

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

States a specific verb (retrieve) and resource (lead activity), and explicitly distinguishes itself from the sibling get_lead_activity_by_id by noting it keys off an email address instead of a lead ID. An agent can route correctly without opening either schema.

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

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

The phrase 'using an email address instead of a lead ID' tells the agent the key selection condition versus the id-based sibling. It stops short of explicit exclusions or prerequisite/handling advice but the selection context is clear.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds nothing beyond that: it does not say what 'activity' comprises (opens, clicks, replies, sends), whether results are paginated or time-bounded, or how the date range defaults behave.

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 single sentence is short and front-loaded, but the second clause merely repeats the first ('by ID' / 'via lead ID') rather than earning its place with new information. It is under-specified rather than efficiently concise.

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?

An output schema exists, so return values needn't be explained, but for a 7-parameter tool with date-range, pagination, sequence and workspace filters, the description says nothing about filtering or result scope. With a sibling that is one word away in name, the description leaves too much to inference.

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 7 parameters are documented in the schema, including Unix-ms timestamps, the 500 max limit, and workspace defaulting. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

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

The description states a verb (get) and resource (lead activity) keyed by lead ID, so the basic operation is inferable. However, it essentially restates the tool name and title, and it does not distinguish itself from the near-identical sibling get_lead_activity_by_email, which differs only in the lookup key.

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 tool versus get_lead_activity_by_email, get_leads, or get_lead_messages, all of which live in the same lead-data cluster. An agent must infer the choice purely from the tool 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, destructiveHint=false, and openWorldHint=false, so safety is covered. The description adds only the lead-and-sequence scope and says nothing about ordering, pagination, or which message types are included, making it nearly a restatement of the title.

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 description is very short and front-loaded, but 'Get Lead Message History - Message history' is redundant and the brevity comes at the cost of useful context. It is concise but under-specified.

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?

An output schema exists, so return-value details need not be repeated, and the annotations cover safety. Still, for a read tool with three parameters and many siblings, the description omits selection guidance and behavioral context that would make invocation reliable.

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 lead_id, sequence_id, and workspace_id are already documented. The description implies the lead and sequence are the lookup keys but adds no format or semantic 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?

The description names a specific verb and resource ('Get Lead Message History') and scopes it to 'a lead in a sequence,' so the core operation is clear. It does not, however, distinguish this tool from closely named siblings such as get_thread_messages or get_replies_activity.

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 tool versus alternatives, no prerequisites, and no exclusions. Given the many message- and lead-related siblings, the agent is left to infer selection from the name alone.

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