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

With no annotations, the description carries the full burden and does disclose two valuable traits: nothing is deleted (non-destructive) and a new reply automatically un-archives the thread. It omits rate limits, permission requirements, and the 200-thread batch ceiling (only implied by the schema).

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

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

Three short sentences, front-loaded with the primary action, then the non-destructive guarantee, then the auto-restore behavior. No filler or redundancy.

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

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

For a two-parameter mutation with 100% schema coverage and no output schema, the description covers reversibility and side effects well. Minor gaps (batch size, partial-failure behavior) are handled by the schema, so it is close to complete.

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

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

Schema coverage is 100%, so both parameters are already documented (archived semantics and 'Thread ids from list_threads'). The description restates the archived toggle in prose but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb (Archive) and resource (threads) and explains the outcome ('get them out of the inbox'), plus the reversible variant via archived=false. It is readily distinguishable from siblings like mark_read and mark_spam, which affect different states.

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 condition for use ('to get them out of the inbox') and the inverse condition ('move them back with archived set to false'), so the agent knows both directions. It does not, however, name alternative tools (mark_read, mark_spam) for overlapping inbox-management needs.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the result shape (verdict, score, reasons per lead), which is genuinely useful, but says nothing about read-only safety, rate limits on polling, pagination behavior, or what 'progress' means for an in-flight 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?

Two short sentences with no filler, and the payload contents are stated up front. Efficient, though the brevity borders on under-specification rather than true 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?

There is no output schema, so the description must describe returns; it partially does by naming verdict, score, and reasons per lead. It omits polling/terminal-state semantics and pagination behavior for limit and offset, leaving an agent without enough to call it confidently in all cases.

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 0% and the description never mentions id, limit, or offset. The required id and the paging controls are left entirely to infer from bare types and constraints, so the description fails to compensate for the coverage gap.

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

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

States the resource (a batch) and what is returned (progress and results), which is a clear, specific read purpose. However, it does not differentiate itself from the sibling check_batch, so an agent cannot tell from the description alone which of the two to call.

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 check_batch, no indication of polling cadence, and no stated prerequisite such as needing a batch id from an earlier submission. Usage must be inferred entirely 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?

With no annotations, the description carries the full burden; it discloses genuinely useful behavior (asynchronous execution, batch id return, automatic retry of greylisted servers). However it omits cost/credit implications, auth requirements, and what 'greylisted' entails, so it only partially covers the behavioral surface.

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 concise sentences, front-loaded with the core action and scale, followed by the return/next-step and retry semantics. Zero filler.

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

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

For a tool with nested object params, an enum parameter, and no output schema or annotations, the description is too thin. It never explains tier semantics or the policy options, leaving the agent unable to reason about the majority of the input contract.

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 0% across three parameters including deeply nested lead objects. The description adds only the '10,000 leads' cap; it says nothing about tier (fast/deep), the policy block-* options, or the context fields expected per lead.

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 ('Queue ... leads') with a concrete scale cap and execution mode ('asynchronous review'). It clearly differentiates from check_lead (single) and batch_status (polling) by describing the queue-then-poll flow.

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 tells the agent to 'poll batch_status' after obtaining the batch id, which is real workflow guidance. It does not explicitly state when to prefer this over check_lead or the tier selection trade-offs, leaving some inference.

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

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

With no annotations, the description carries the full burden and does well: it discloses the return shape (verdict, 0-100 score, weighted reasons, policy pass/fail), the cost model (1 credit fast, 5 deep, unknowns free), and the semantic difference between tiers ('deep ... looks for extra evidence about the person'). It omits auth requirements and rate limits, so not a full 5.

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

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

Three tight sentences, front-loaded with purpose before output details, then tier pricing. No filler and every clause carries information the agent needs to choose a tier and interpret results.

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

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

There is no output schema, so the description correctly compensates by describing the return payload, and it covers costs and tier semantics. The nested context object ('Everything you know about the lead') is not explained as to whether or how it improves accuracy, which is the main remaining gap for a tool with two nested object parameters.

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

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

Schema description coverage is 100%, so the baseline is 3, but the description earns extra credit by adding meaning the schema lacks: that 'fast' is the default and costs 1 credit while 'deep' costs 5, and that deep searches for additional person-level evidence. The policy object's override behavior is only stated in the schema, not the description.

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: 'Review one email address for deliverability.' The word 'one' frames it as a single-address check, distinguishing it from batch-oriented siblings like check_batch and batch_status. It also enumerates the verdict vocabulary, so the agent knows exactly what kind of result to expect.

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 the fast-vs-deep tier tradeoff and their credit costs, which is real usage guidance for parameter selection. However, it never states when to reach for this tool versus check_batch/batch_status or other lead tools, and gives no exclusions or prerequisites. Usage is implied rather than directed.

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

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

With no annotations, the description carries the full burden and does so well: it explains delayHours semantics, reply routing to the sender, the requirement that links stay on the sender's own domain, and what the response returns. It omits permission/auth requirements and any rate-limit behavior, keeping it short of a 5.

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

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

The description is three tightly packed sentences that lead with the core action before layering in step semantics and constraints. No filler, though the density of rules makes it slightly list-like.

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

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

For a 3-parameter mutation tool with no annotations and no output schema, the description covers parameter intent, key constraints, and return values adequately. It could say more about validation limits (max 10 steps) or auth, but an agent has enough to invoke it correctly.

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

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

Schema description coverage is only 33%, so the description must compensate, and it does: it clarifies delayHours (first from enrollment, later from previous step), the sender format expectation, and that text/html support {{variable}} placeholders. This adds real meaning beyond the bare schema, though not every parameter is touched.

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 multi-step email sequence'), so the agent immediately knows the operation. It doesn't explicitly contrast itself with siblings like sequence_status, enroll_leads, or stop_enrollment, so it falls just short of the top score.

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

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

There is no explicit when-to-use guidance and no named alternative among the sibling tools (e.g., enroll_leads or sequence_status). Some prerequisite context is implied by 'from a sender on your Resend domains,' but the agent must infer when this tool is the right choice.

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?

No annotations are provided, so the description carries the full burden. It does disclose meaningful behavior about the result scope (a 30-day window, grouped by verdict, plus tier-level pricing), but it never states that this is a read-only, zero-side-effect operation, nor anything about authorization requirements or result freshness.

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 ten-word fragment with no filler, front-loading the primary datum (credit balance) before the secondary breakdowns. Nothing could be removed without losing information.

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

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

With no output schema available, the description usefully enumerates what the caller will receive, which is the key completeness concern for a zero-parameter tool. It stops short of explaining units, formatting, or the exact meaning of 'verdict' categories, but it is adequate for a simple read.

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

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

The tool takes zero parameters, so schema-based parameter semantics are not applicable and the baseline is 4. The description correctly implies a parameterless, global query rather than a per-account filter.

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 the specific resource (credits) and the exact data returned: credit balance, per-tier pricing, and 30-day usage broken out by verdict. It is a noun phrase rather than a verb+resource, and it does not reference any sibling, but no sibling overlaps this resource so differentiation is not needed.

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 stated prerequisites, and no mention of alternatives among the 22 siblings. An agent can infer it is a status lookup, but the description never says under what circumstances to call it (e.g. before sending email, before creating a batch).

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?

No annotations are provided, so the description carries the full disclosure burden. It usefully enumerates the returned signals (warm-up step, capacity, bounce/complaint rates, pause reason), which implies a read-only diagnostic, but it never states that this is non-mutating, nor mentions auth scope, freshness/lag of the 7-day window, or rate limits.

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

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

A single dense sentence that front-loads the tool's purpose and then lists the payload. No filler, no restatement of the title or name, and every clause carries information.

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

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

With no output schema and no annotations, the description must convey what comes back — and it does, naming all four metric groups. It is therefore sufficient for an agent to decide and call. It would be a 5 with a brief note on read-only behavior or when to reach for it over list_domains.

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

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

Schema coverage is 100% and the single parameter is documented as 'Domain id from list_domains', so the schema already handles semantics. The description adds nothing about the id format or where to obtain it, 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 resource (one sending domain) and enumerates the exact metrics returned: warm-up step, remaining capacity, 7-day bounce/complaint rates, and pause reason. That is enough to distinguish it from list_domains (which enumerates domains) and email_status. It stops short of explicitly naming those siblings, so it falls just below a 5.

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

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

Usage is only implied: 'for one sending domain' signals single-domain scope, and the 'from list_domains' note in the schema hints at a prerequisite lookup. There is no explicit when-to-use statement, no when-not-to-use, and no stated alternative when the agent needs health across many domains.

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?

No annotations are provided, so the description carries the full burden. It does disclose the enumerated return states (queued/sent/failed, pending/delivered/bounced/complained), which is genuine behavioral context, but it says nothing about auth requirements, read-only nature, polling expectations, or how quickly status transitions.

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 sentence, front-loaded with the returned value sets, no filler. Every clause carries information about what the agent will get back.

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

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

With no output schema and no annotations, the description takes on the return-value burden and does enumerate the possible status and delivery values, which is the key thing an agent needs. It stops short of describing error/not-found behavior or timing, so it is nearly but not fully complete.

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

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

Schema coverage is 100% with a single required param, so the baseline is 3. The description's 'sent with send_email' merely restates the schema's own 'Email id from send_email' description, 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?

The description names a specific resource (an email sent with send_email) and states exactly what it returns: status and delivery values. It is clear what the tool does, though it doesn't explicitly contrast itself with the sibling batch_status, which an agent could 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?

The phrase 'of an email sent with send_email' implies the tool is used after sending, which is useful implied context, but there is no explicit when-to-use guidance, no exclusions, and no mention of the batch_status alternative for multi-email lookups.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavior: the 1,000-lead cap, rejection of invalid emails / missing variables / suppressed addresses, idempotency ('re-enrolling a lead is a no-op'), and credit reporting. It does not say whether a batch with some invalid leads is partially enrolled or fully rejected, nor does it mention auth or rate limits.

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

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

Three dense sentences, front-loaded with the core action and scope, followed by validation/idempotency behavior and the credit note. No filler.

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

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

With no annotations and no output schema, the description needs to stand alone, and it partially does. The key gap is partial-failure semantics for a batch of up to 1,000 leads, plus no indication of auth/permission requirements.

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 0% across 2 parameters, so the description must compensate. It clarifies that 'variables' are per-lead template variables, but sequenceId is never explained and the email variable shape is left entirely to the schema.

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

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

The description gives a specific verb+resource with scope: 'Enroll up to 1,000 leads with their template variables.' It is unambiguous about what the tool does, though it never names the inverse sibling stop_enrollment or otherwise differentiates itself from the surrounding enrollment tools.

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

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

Usage is implied by the purpose (enroll leads into a sequence) but there is no explicit when-to-use, when-not-to-use, or alternative tool guidance. Given siblings like stop_enrollment and check_lead, a routing hint would have been cheap and valuable.

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?

No annotations exist, so the description carries the full burden, and it delivers: it explains what the tool does (reads the site, searches the web), what it returns (email, name, title, company, source page, plus a short answer), the cost model (1 credit per new lead with an email, free when nobody is found), and the latency (a minute or two).

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

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

Front-loaded with the core action and inputs, then returns, then cost, then latency, then the workflow caveat. Every sentence adds distinct information with no filler.

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

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

With no output schema, the description compensates by enumerating the returned fields and the accompanying short answer. Combined with cost and latency disclosure, nothing essential for correctly invoking 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 both parameters are already documented in the schema. The description restates that request accepts a URL or ideal-customer description but adds no syntax, formatting, or constraint detail beyond the schema. Baseline 3 applies.

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

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

States a specific verb (find) plus resource (people to email / leads) and the two accepted input forms (website URL or ideal-customer description). An agent can tell this is a lead-prospecting tool distinct from list_radar_leads, check_lead, or qualify_radar_leads without opening the schema.

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

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

Provides clear workflow context with 'Qualify the leads before sending' and the schema note that chatId refines an earlier search. It does not explicitly name an alternative sibling (e.g., qualify_radar_leads) or state when-not-to-use, so it falls short of a 5.

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

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

With no annotations, the description carries the full burden. It does disclose the behavioral output — per-folder counts plus unread counts across four named folders — which tells the agent what kind of result to expect from a side-effect-free read. It says nothing about permissions, scoping to the authenticated user, or anything beyond the returned figures, so meaningful gaps remain.

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 well-formed sentence that front-loads the two things being counted and enumerates the folders. No filler, no restatement of 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?

For a zero-parameter, no-output-schema counter, the description supplies essentially everything an agent needs: the four folders covered and the two metrics returned. It doesn't specify the result shape (e.g., a map of folder to counts), but that gap is minor for a tool this simple.

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

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

The tool takes zero parameters, so per the rubric the baseline is 4. There is nothing for the description to clarify beyond the empty 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 a specific verb+resource: counting threads per folder (inbox, sent, archived, spam) and counting unread ones. That clearly separates it from siblings like list_threads or read_thread, which return content rather than aggregates. It lacks an explicit naming of those siblings, so it's clear but not fully differentiated.

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

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

There is no when-to-use guidance, no statement of prerequisites, and no reference to alternatives such as list_threads for the actual messages. The use case (getting an overview of folder volume) is only implied by the content of the description.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the returned fields (verification status, warm-up step, daily cap, paused), which signals a read-only listing, but it says nothing about auth requirements, ordering, or pagination behavior.

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

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

A single compact sentence with no filler, and the key content (domains plus their status/warm-up fields) is front-loaded. It is efficient, though slightly terse.

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

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

For a no-parameter, no-output-schema read tool the description covers the essentials by naming the returned fields. However, it leaves gaps around ordering, completeness of the list, and any auth context that an agent might want before invoking it.

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

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

The tool takes zero parameters, so there is nothing for the description to document and the baseline for an empty schema 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 clear resource — 'Your Resend sending domains' — and specifies what is included (verification status and warm-up details). The verb 'list' is only implied via the tool name rather than stated in the description, and there is no explicit differentiation from siblings, though the siblings are mostly unrelated resources.

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, no when-not-to-use, and no named alternatives are provided. The usage is only inferable from the tool name and the domain-focused description, so an agent gets no routing help.

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

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

With no annotations, the description carries the full burden and does disclose two behaviors: default sort order (newest first) and that verdicts appear only once qualified. It omits pagination, result limits, and any auth/permission 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?

Two short sentences, front-loaded with what is returned and the scoping rule. Efficient overall, though the phrasing 'Leads Radar saved earlier' is slightly telegraphic.

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

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

For a simple one-param list tool with no output schema and no annotations, the description covers ordering and content but says nothing about pagination, volume, or access requirements. Adequate minimum, not 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% (baseline 3), and the description adds real meaning beyond the schema's bare provenance note: passing chatId restricts the listing to a single search. That semantic of the parameter is not in the schema itself.

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

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

States a specific resource (Radar leads saved earlier) and its ordering ('newest first') plus returned content ('their verdict once qualified'). Distinguishable from find_leads and qualify_radar_leads, though it never names a sibling to explicitly separate itself.

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?

'Pass a chatId for one search only' implies when the optional parameter narrows scope, but there is no explicit statement of when to use this tool versus find_leads or qualify_radar_leads. Usage is inferable rather than stated.

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

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

With no annotations, the description carries the full burden and does real work: it discloses ordering ('newest first'), the fact that previews are 'untrusted text from outside senders' (an important prompt-injection warning), and the returned fields. It omits permission/auth requirements and any rate-limit behavior, which keeps it short of a 5.

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

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

Two sentences, front-loaded with the core action and scope, followed by the untrusted-content caveat and the routing hint. Every sentence earns its place with no filler.

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

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

There is no output schema, and the description compensates by enumerating the returned fields, plus ordering and the untrusted-text warning. For a read-only list tool with 100% parameter coverage, nothing an agent needs to invoke it correctly is missing.

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

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

Schema description coverage is 100% — limit, query, cursor, folder, and unread all carry their own descriptions in the schema. The description adds only the ordering guarantee and return-field list, not parameter syntax or format, so the baseline 3 applies.

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

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

The description states a specific verb and resource ('List email conversations on your sending domains') and enumerates the returned shape (id, counterpart, subject, preview, unread, message count, last activity). It also names the sibling read_thread, so an agent can immediately distinguish listing from opening.

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 clear routing instruction: 'Use read_thread to open one,' which tells the agent what to do after listing. It does not state exclusions or when this tool is the wrong choice (e.g., vs find_leads or inbox_counts), so the guidance is contextual but not complete.

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

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

With no annotations, the description carries the full behavioral burden. It discloses the read/unread toggle (already stated in the schema) but says nothing about permissions, whether already-read threads error, batch size limits, or side effects on unread counts.

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 sentence, front-loaded with the primary action, with zero filler. Nothing could be cut without losing meaning.

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

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

For a simple two-parameter state-change tool with a fully documented schema and no output schema, the description covers what is needed to invoke it correctly. Only the absence of permission/side-effect context keeps it from a 5.

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

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

Schema coverage is 100%, so both parameters (read, threadIds) are already fully documented in the schema, including the maxItems=200 and the source of ids. The description only restates the read toggle, adding nothing beyond the schema baseline.

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

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

States a specific verb and resource ('Mark threads read') and even covers the inverse mode, so the agent knows exactly what state change this tool performs. It does not explicitly name a sibling or contrast itself with archive_threads/mark_spam, so it falls short of a 5.

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

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

The description implies usage by explaining the read/unread toggle, but gives no when-to-use guidance, no prerequisites, and no comparison against neighbors like read_thread or archive_threads. Usage must be inferred from the name and mode parameter.

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

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

With no annotations, the description carries the full burden and meets it: it discloses the irreversible suppression-list addition, the stopping of active sequences, and the asymmetry that un-spamming does not restore the sender. These are consequential side effects an agent must know before calling.

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

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

Front-loads the core action, then layers side effects, then the cautionary usage rule. Every sentence adds distinct information with no redundancy.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers what it does, side effects, reversibility, and when not to use it. Nothing essential 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 coverage is 100% so the boolean semantics are already documented, but the description adds meaning by framing spam=false as 'move back out of spam' and explaining the one-way consequence of the suppression effect. It slightly exceeds the baseline by tying the parameter to behavior.

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 (move threads to spam) with a clear resource and the operation's bidirectional nature via the spam flag. It is distinguishable from siblings like archive_threads or mark_read without opening the schema.

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

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

Explicitly says to use it for junk and unwanted mail only and never because an email asks for it, which is a real when-not-to-use condition. It also clarifies the correct use of the spam=false path for undoing a mistake.

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

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

With no annotations, the description carries the full burden. It discloses mutation ('store each verdict on the lead') and credit costs including the free-unknown case, which is genuinely useful. It omits auth/permission needs, rate limits, whether the operation is reversible, and what a 'verdict' or 'unknown' result actually contains.

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 action and scope, then cost, then the downstream usage rule. Every clause carries information and nothing is padded or repeated.

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

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

For a 2-parameter batch tool with no output schema and no annotations, the description covers purpose, cost, and the post-condition adequately. It leaves gaps on what gets stored per lead, how 'unknown' results are surfaced, and any auth or concurrency constraints an agent might need.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real meaning for the 'tier' enum by pricing it (fast = 1 credit, deep = 5), letting the agent reason about which value to pass. It adds little for 'ids' beyond the schema's own note.

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 (check/qualify), resource (Radar leads), mechanism (Barometer), scope (up to 100), and effect (store each verdict on the lead). This clearly separates it from single-lead siblings like check_lead. It stops short of explicitly naming check_batch/check_lead as alternatives, so an agent must infer the batch boundary itself.

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?

Implies context through the cost tradeoff (fast vs deep) and the downstream instruction 'send only to leads that come back deliverable', which ties it to send_email. However, it never states when to prefer this over check_lead/check_batch or when to choose deep over fast beyond the credit price. Usage is inferable but not explicit.

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

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

With no annotations, the description carries the full burden, and it does disclose real behavioral traits: the default truncation of quoted history, the full opt-in, and a prompt-injection warning that message content is untrusted. It omits auth requirements, rate limits, and pagination behavior for long threads, which keeps it below 5.

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

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

Three sentences, front-loaded with what the tool returns, then the default/override behavior, then the safety note. Every sentence earns its place and nothing is padded.

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

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

With no output schema, the description compensates by enumerating the returned fields and explaining the default-vs-full content difference. For a read tool of this shape it is nearly complete, though pagination or size limits for very long threads are 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%, so both parameters are already documented in the schema. The description's 'set full to get the whole text' largely restates the schema's own wording for full, adding little beyond the baseline.

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

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

States a specific verb and resource ('Read one conversation') and enumerates exactly what comes back: sender, recipients, time, direction, verification status, and attachment names/sizes. The singular 'one conversation' cleanly separates it from the sibling list_threads.

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

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

It gives clear operational context for the main choice an agent faces here — default (new text only) vs setting full — and the schema ties threadId to list_threads as the source. It does not name exclusions or alternatives (e.g., reply, mark_read) explicitly, so it stops short of a 5.

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

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

With no annotations, the description carries the full behavioral burden and does well: it discloses the 1-credit cost, that it sends a real email, that it only reaches the thread's participant from the conversation's mailbox, cannot add recipients, and that idempotencyKey guards retries. It stops short of stating auth requirements or what a successful call returns, so it falls just short of the top bar.

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

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

Four tightly packed sentences with zero waste. The core action and its constraints are front-loaded, and each subsequent sentence adds a distinct constraint (routing, cost, idempotency).

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

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

For a 3-parameter mutation with no annotations and no output schema, the description covers the essential behavioral facts an agent needs (scope, cost, retry safety). It could say more about the response or irreversibility, but it is largely complete.

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

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

Schema coverage is 100%, so the schema already documents all three parameters including idempotencyKey's retry semantics and threadId's source. The description's mention of idempotencyKey largely restates the schema field rather than adding new meaning, so the baseline 3 is appropriate.

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

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

States a specific verb and resource (send a real email answering an existing thread) and immediately scopes it against siblings by noting it cannot start new conversations. An agent can distinguish it from send_email and create_sequence 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 names the when-not condition and the alternatives: 'use send_email or a sequence for new outreach.' The routing decision between reply versus new outreach is fully spelled out, leaving nothing to inference.

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

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

With no annotations, the description carries the full burden. It does disclose one meaningful side effect — a bounce marks the address undeliverable for future checks — which is genuine behavioral value. However, it omits whether reports are idempotent, whether they override prior events, and any auth/permission requirements for a mutation tool.

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

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

Two tight sentences with the action front-loaded and the consequence immediately after. Slight waste in re-listing enum values the schema already declares.

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 with no annotations and no output schema, the description covers what to report and one downstream effect. It still leaves duplicate-report behavior, permission needs, and whether reporting triggers other workflows (e.g., sequence suppression) 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 only 33%, but the description restates the `kind` values already defined by the schema enum and says nothing about the required `email` field or the optional `detail` field. It adds little beyond the schema and does not compensate for the coverage gap.

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 concrete verb (report) and resource (outcome of a sent email), and enumerates the accepted outcome kinds. An agent can tell this is a write-back of delivery events, though it does not explicitly distinguish itself from sibling readers like email_status or check_lead.

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?

"what happened after sending" implies the usage window, but no alternatives are named and no exclusions or prerequisites are given. It is adequate context without routing guidance.

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

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

With no annotations, the description carries the full burden and delivers: warm-up pacing per domain, suppression skipping, automatic unsubscribe line, forced Reply-To, link-domain restriction with the cross_domain_link error, credit cost, and refund on failure. This is unusually rich behavioral 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?

Five dense sentences, front-loaded with scope and constraints, then behavior, then return shape and cost. Every sentence earns its place, though the credit/refund detail could be trimmed slightly.

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

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

No output schema exists, yet the description explains the return shape (accepted with ids, rejected with reasons), and it covers pacing, suppression, cost, and failure handling. Nothing essential for a correct call is missing.

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

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

Schema coverage is 0% and the nested message fields are only partly described in the schema, so the description adds real value: the 100-item cap, verified-domain requirement for 'from', Reply-To derivation, and the cross-domain link rule. It does not explain idempotencyKey or html/text interplay, but covers most 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 and resource ('Queue up to 100 emails from your verified Resend domains') with concrete scope and the domain constraint, so it is unmistakable against siblings like reply or create_sequence.

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?

Implies the use case (sending outbound email) and states operational constraints, but never says when to prefer this over reply, create_sequence, or enroll_leads, and gives no exclusions or prerequisites beyond domain verification.

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?

No annotations exist, so the description carries the full burden. It does disclose the returned content in each mode (counts, steps, recent enrollments, status and stop reason), but says nothing about permissions, pagination/limits on 'recent enrollments', or whether the operation is purely read-only.

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

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

Two tightly parallel sentences, front-loaded with the no-id case and zero filler. Every clause conveys distinct behavior.

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

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

For a single-optional-parameter read tool with no output schema or annotations, both call modes and their returns are covered. Minor gaps remain around pagination hints for the enrollment list and any auth requirements.

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 0%, so the description must compensate, and it does: it explains that 'id' is optional and that its presence fundamentally changes the response shape. That is the key semantic fact about the parameter, though format/type details are left implicit.

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 concrete verbs (list/show) and the resource (sequences), and splits behavior by whether an id is supplied. It is easily separable from siblings like batch_status or create_sequence, though it never names a sibling to contrast against.

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

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

'Without an id... With an id...' gives explicit mode-selection guidance, so an agent knows which call shape produces which view. It stops short of naming alternatives or exclusions (e.g., when to prefer batch_status or check_batch instead).

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

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

With no annotations, the description carries the full burden. It does disclose a meaningful side effect beyond the schema – pending steps are both cancelled and refunded – which is genuinely useful. However, it is silent on permissions required, whether the stop is reversible or re-enrollable, and what happens to already-sent steps.

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 with zero filler. The action comes first and the behavioral consequence follows immediately, which is a well front-loaded structure.

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

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

For a two-parameter mutation tool with no annotations and no output schema, the description covers the core effect but omits permissions, reversibility, and the undocumented sequenceId. It is adequate but leaves clear gaps an agent might hit at call time.

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

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

Schema coverage is only 50%: enrollmentId is documented as coming from enroll_leads or sequence_status, but sequenceId is undocumented in both schema and description. The description adds no parameter meaning at all, so it fails to compensate for the coverage gap.

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 pairs a specific verb ("Stop") with a specific resource ("one lead's sequence"), and the word "one" implicitly scopes this to a single enrollment against the batch-oriented sibling names. It is clear what the tool does, though it never explicitly names a sibling to distinguish itself from.

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

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

There is no guidance on when to use this versus alternatives, nor any prerequisite, permission, or pre-condition stated. The reader gets no routing signal beyond the purpose statement.

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

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

No annotations exist, so the description carries the full burden. It usefully discloses the return contents (email, credit balance, target API) and implicitly conveys a read-only identity probe, but never states that it is read-only, requires no permissions, or has any side effects. Adequate but incomplete for an unannotated tool.

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

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

A single compact sentence with the key payload (account identity) front-loaded and the three returned fields listed efficiently. No filler, though the phrasing is slightly clipped.

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

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

With no output schema and no parameters, the description does the necessary work by naming the three return fields returned. Nothing critical is missing for invoking a zero-argument tool, though it could state that no arguments are needed and that it is a safe read.

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

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

The tool takes zero parameters, so the baseline of 4 applies. The description's enumeration of returned fields is not parameter documentation but does orient the caller to what the (empty) input implies.

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 precisely what the tool returns: the signed-in account's email, credit balance, and backend API. That is specific and distinguishable from siblings like credits or email_status. It is phrased as a noun phrase rather than a verb+resource, but the purpose 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?

There is no when-to-use guidance, no indication of when this is preferable to the sibling credits tool, and no prerequisites. Usage is only inferable from the name and the described output. For a zero-param identity probe this is tolerable but still a gap.

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