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

Annotations already declare destructiveHint=false and readOnlyHint=false, but the description earns its place by explaining what archiving actually does to the data (hidden from history and analytics, not deleted) and naming the required scope. It does not address whether repeat calls are safe, which matters given idempotentHint=false, but nothing contradicts the annotations.

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

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

Two short sentences: the action and its effect come first, the precondition second. Zero filler and no restating 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 one-parameter mutation with no output schema, the description covers the important ground: the semantic effect, reversibility (not deleted), and the auth scope. The only real gap is identifying the `id` parameter, which the schema leaves bare.

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% for the single required `id` parameter, so the description must carry the load and it does not — it never says whether `id` is a call ID, nor what form it takes. Only the scope hint indirectly implies this is a write on an existing call.

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 ('Archive a call') and immediately defines the effect ('hidden from history and analytics, not deleted'), which rules out confusion with a hard delete. It does not name the obvious inverse sibling `unarchive_call`, so sibling differentiation is implied rather than stated.

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

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

The `calls:write` scope requirement gives a real precondition for use, which is more than most definitions offer. However, there is no explicit guidance on when to archive versus when to use `unarchive_call` or other call-mutating siblings, leaving the choice 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 cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false), and the description adds two things they do not convey: the required auth scope and the critical gotcha that omitted fields are cleared on update. That clearing behavior materially changes how an agent must construct payloads and is exactly the kind of context the annotations undersell.

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, both front-loaded with the highest-value information (the batch limit and the destructive update semantic) before the auth requirement. Nothing is redundant with the tool name or 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?

For a write tool with a deeply nested single-param schema and no output schema, the definition covers batch limit, upsert key, update-clearing semantics and auth scope. It leaves two gaps: nothing about what the call returns (no output schema to fall back on) and nothing about partial-failure behavior when some leads in the batch fail.

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

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

With only one parameter and 0% schema description coverage, the description must carry the semantic load, and it does: it names externalId as the upsert key and warns that unspecified fields are nulled on update. It stops short of describing the nested lead object's fields (value in cents, notes structure), though the schema documents several of those 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 verb (import), resource (leads), batch ceiling (up to 100) and the upsert key (externalId), which cleanly separates it from the single-record sibling upsert_lead. It never names that sibling explicitly, so the differentiation is inferred from 'batch/up to 100' rather than stated.

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

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

The scope requirement (`leads:write`) tells an agent the preconditions for calling it, and 'Import' implies bulk-loading use. However, there is no explicit when-to-use/when-not guidance and no named alternative (e.g. use upsert_lead for a single record), so routing between the two upsert tools 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?

The destructive nature is already fully declared by annotations (destructiveHint=true, idempotentHint=true, readOnlyHint=false), so the repeated "DESTRUCTIVE: this cannot be undone" lines add no information beyond structured data. The genuinely additive content is the `team:write` scope requirement, which is real behavioral context not present in annotations. Idempotency is asserted in annotations but never explained, and the description is silent on what happens if the invite is already accepted or expired.

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 intent is front-loaded, which is good, but the destructive warning is duplicated verbatim in two separate places, wasting a line on content the annotations already carry. Splitting the scope requirement into its own paragraph is fine, but the overall body is padded 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?

For a destructive single-parameter mutation with no output schema, an agent still lacks the id's provenance, the result of a successful call, and the error behavior for non-pending invites. The scope requirement partially offsets this, but the definition is not complete enough to invoke confidently without guessing.

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 `id` parameter has 0% schema description coverage and the description never mentions it at all — it does not say the id is an invite id, where to obtain one (e.g. from list_invites), or what format it takes. With coverage this low, the description is expected to compensate and does not.

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 first line states a specific verb and resource ("Cancel a pending invite") and the qualifier "pending" scopes it meaningfully. It does not name or distinguish itself from the relevant siblings (create_invite, list_invites, remove_member), so the agent must infer the boundary from the resource name 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?

"Only call it when the user explicitly asked for exactly this action" is an explicit negative usage condition, which is stronger than most tools provide. However, it never names the alternatives (create_invite to re-issue, list_invites to find the id) or explains handling of invites already accepted or expired.

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 non-read-only, non-destructive, non-idempotent, closed-world, so the safety bar is partly covered. The description adds genuinely non-obvious behavior: the secret is shown only once and must be surfaced to the user but not repeated elsewhere, plus the required `api_keys:write` scope. It does not mention that a repeated call creates a second distinct key (relevant given idempotentHint=false) or that the key can later be revoked.

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 one-shot secret warning, zero filler. Every sentence carries actionable information.

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

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

With no output schema, the description correctly explains that the response contains a one-time secret, which is the critical return-value fact. However, for a security-sensitive creation tool it leaves the two required parameters unexplained and gives no guidance on scope selection, so an agent could create an over- or under-privileged key.

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

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

Schema description coverage is only 33% — only expiresAt is documented (omit/null for no expiry). The description says nothing about `name` (uniqueness, max length) or `scopes` (whether scopes are fixed at creation, whether `admin` subsumes others, whether the creator can grant scopes they lack). With low coverage, the description should have compensated and does not.

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 an API key') and adds the key lifecycle fact that the secret is returned once. It is distinguishable from siblings like list_api_keys and revoke_api_key by name, but it never explicitly contrasts with rotate_api_key, the nearest ambiguous 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 the create semantics; there is no statement of when to use this versus rotate_api_key (existing key, new secret) or when not to create a new key. The scope requirement gives a precondition but not a decision 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=false, destructiveHint=false, idempotentHint=false and openWorldHint=false. The description adds genuinely useful context beyond that: the required `coaching:write` scope and the Premium/Enterprise plan gate, both of which gate whether the call is viable. It still doesn't say what happens on a name collision or what the response 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?

Two short sentences with the action first and the prerequisite second. No filler or repetition; every statement 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?

For a six-parameter write tool with zero schema coverage and no output schema, the description leaves the agent without any explanation of the inputs or what a successful creation returns. Only the scope and plan gate are covered; parameter meaning and failure modes are absent.

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

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

Schema description coverage is 0% across six parameters, including two required ones (name, personalityPrompt), so the schema provides no meaning at all. The description offers nothing about any parameter — not what personalityPrompt should contain, nor how objectionStyle, toneDescriptor, or closingPhilosophy differ. Only the phrase 'coaching style' hints at the parameter domain.

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 ('Create a custom coaching style') that is unambiguously distinct from the siblings list_coaching_styles and update_coaching_style. It doesn't explicitly name those siblings or clarify what makes one style differ from another, but the action is clear.

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

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

Adds entitlement and permission prerequisites ('Premium/Enterprise', scope `coaching:write`), which tell the agent whether the call can succeed. However, it gives no guidance on when to create a new style versus updating an existing one via update_coaching_style, and no behavior for duplicates.

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 and destructiveHint=false, so the safety profile is known. The description adds two pieces of context not in the annotations: the invite consumes a seat in the team limit and the call requires the `team:write` scope. It omits link expiry, whether the link is returned in the response, and any rate-limit or duplicate-invite behavior.

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

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

Two short sentences with no filler. The side effect (seat consumption) is front-loaded in parentheses and the auth requirement follows immediately, which is exactly the order an agent needs.

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

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

For a zero-parameter creation tool with no output schema, the description covers the action, its cost, and its auth requirement. The remaining gap is the return value: it does not say whether the created invite link itself comes back, or whether the agent must call list_invites to retrieve 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?

With zero parameters, there is nothing for the description to disambiguate, so the baseline of 4 applies. The description correctly implies the operation is parameterless and that the invite's attributes are server-determined rather than caller-supplied.

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 an invite link') and adds a material scope note (counts against the seat limit). It is clearly distinguishable from siblings like list_invites and cancel_invite by the verb alone, though it never names those siblings or contrasts itself 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?

Usage is only implied: an agent infers 'use this when you want a new invite link.' There is no explicit when-to-use/when-not guidance, no mention of prerequisites beyond the scope string, and no routing to alternatives such as list_invites to check existing invites first.

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 this is a non-read-only, non-destructive, non-idempotent write. The description adds genuinely valuable context beyond that: the signing secret is returned exactly once, is not retrievable later, and must be surfaced to the user once and not repeated. The one-time-secret behavior corroborates idempotentHint=false and is the kind of detail annotations cannot carry.

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

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

Three short, front-loaded lines with the operation first and the constraint second — efficient. Minor waste: the first line's parenthetical about the signing secret duplicates both the title and the second sentence.

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

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

With no output schema, the description correctly fills the gap by disclosing that the response contains a one-time secret and how to handle it. Required params and the auth scope are stated. The remaining gap is that the `events` selection — the core decision when creating a webhook — is left entirely to the bare enum.

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

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

Schema description coverage is only 33% — `events` and `description` carry no descriptions. The tool description adds nothing about either parameter: no note that `events` accepts a specific enum set and requires at least one unique value, and no meaning for `description` (label? internal note?). With coverage this low, the description needed to compensate and does not.

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

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

The description opens with a specific verb+resource ("Add a webhook endpoint"), which cleanly separates it from update/delete/list/rotate/test siblings whose names appear in the tool list. It stops short of explicitly naming those alternatives, but the operation is unambiguous.

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

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

It states the required scope `webhooks:write`, which is a useful prerequisite, but gives no when-to-use vs. when-not guidance. It never clarifies the relationship to `rotate_webhook_secret` (for an existing endpoint) or to `update_webhook_endpoint`, so the agent must infer where this fits.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the description's real contribution is the irreversibility warning, the cascade to delivery logs, and the required `webhooks:write` scope — all context not in the structured fields. It loses a point only because the DESTRUCTIVE warning is stated twice, which adds noise rather than new information.

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 opening line and scope requirement are well front-loaded, but 'DESTRUCTIVE: this cannot be undone' appears verbatim twice (opening and closing), so roughly a third of the text is redundant 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?

For a single-parameter mutation with rich annotations and no output schema, the description covers safety, scope, and the side effect on delivery logs. Only the identity of the `id` argument is left 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?

There is one parameter with 0% schema description coverage, so the description should clarify what `id` refers to (endpoint vs. delivery identifier). It never mentions the parameter, leaving its meaning to be inferred from the tool name alone.

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 ('Delete a webhook endpoint') and adds the important consequence that the delivery log goes with it. That scope detail plus the sibling set (update_webhook_endpoint, rotate_webhook_secret, list_webhook_endpoints) makes the operation 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?

Explicitly constrains invocation to cases where 'the user explicitly asked for exactly this action,' which is a meaningful gate for a destructive tool. It does not name an alternative for softer intents (e.g., disabling via update_webhook_endpoint), so it falls short of a full when/when-not routing.

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

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds the genuinely non-annotated detail that scope `calls:read` is required, but omits the 10,000-record cap, whether the export is synchronous, and how large results are returned.

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

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

Two short sentences, capability front-loaded, with the access requirement second. No filler or redundant restatement of 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?

With six parameters, no output schema, and low schema coverage, the description should explain the filter semantics and the result-size ceiling. As written, an agent knows what the tool does but not how to filter correctly or what a bounded export looks like.

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%: `to` and `from` are documented, but `limit`, `outcome`, and `call_type` have no schema description. The description adds only the format choice ('CSV or JSON'), doing nothing to explain the outcome or call_type filters or the default/exclusivity semantics of the date range.

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 ('Export calls') plus the output formats, which is clearer than a generic list. It does not distinguish itself from siblings like list_calls or get_call, leaving the agent to infer that this is the bulk-download path.

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 guidance is the required scope `calls:read`; there is no statement of when to use this over list_calls for paginated browsing or get_call for a single record. No exclusions, limits context, or prerequisites beyond the scope string.

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, idempotentHint, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful piece of information not in the structured fields: it requires the `analytics:read` scope. It says nothing about aggregation window, granularity behavior, or emptiness handling.

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

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

Two short sentences with no filler, and both the purpose and the scope prerequisite are front-loaded. The failure here is under-specification rather than verbosity, so structure itself is fine.

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 carries the burden of explaining what comes back — 15-minute buckets for a single day (per the schema) versus some other aggregation for `period` values — and it is silent. For an analytics read tool with three loosely-related filtering params and six sibling analytics/member tools, this leaves an agent guessing.

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 67% (tz and date documented, `period` enum undocumented) and the description adds zero parameter semantics. It does not explain the interaction between `date` and `period` (are they mutually exclusive? does one override the other?), nor how `tz` shifts bucketing — arguably the most consequential ambiguity.

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 is essentially a restatement of the tool name ("get_analytics_by_member" → "Per-member call stats"), which matches the tautology band. It conveys the resource but no verb, no scope, and no differentiation from siblings like get_analytics_overview or list_member_usage that an agent must choose between.

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 versus get_analytics_overview or list_member_usage, both of which appear in the sibling list and overlap conceptually. The only context is an auth scope requirement, which is a precondition, not 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, idempotentHint, and non-destructive behavior, so the safety profile is covered. The description adds the required OAuth scope, which is real context not in annotations, but says nothing about what the overview aggregates, default time window, or result shape.

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

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

Two very short sentences with nothing extraneous, and the purpose is front-loaded. However, the brevity reflects under-specification rather than disciplined concision.

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?

Four optional parameters, no output schema, and no explanation of what metrics or dimensions the overview returns or how date (15-minute buckets) relates to period (7d/30d/90d). An agent cannot predict the response or pick the correct time parameter from this description.

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 75%, with tz, date, and user_id documented in the schema and period only an enum. The description contributes no parameter meaning beyond the schema, so the baseline 3 applies.

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

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

The description is a noun phrase, 'Team call analytics,' with no verb and no statement of what the tool actually returns (an aggregated overview of team call metrics). It nearly repeats the annotation title 'Team call analytics,' and does nothing to distinguish it from the sibling get_analytics_by_member.

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

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

The only guidance is an auth prerequisite ('Requires scope analytics:read'), which is useful but not usage guidance. There is no indication of when to call this versus get_analytics_by_member or how date and period interact.

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, idempotentHint, and destructiveHint=false, so the safety profile is fully covered without the description. The description's real contribution is naming the required `billing:read` scope, which is genuine auth context an agent needs before calling. It stops there, adding nothing about what the response contains for a tool with no output schema.

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

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

Two short sentences with no filler, and the purpose statement is front-loaded ahead of the scope requirement. The brevity is honest rather than padded, though it edges toward under-specification rather than efficiency.

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

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

With no parameters and full annotation coverage, the description covers the invocation prerequisites (scope) but not the payload: an agent cannot tell whether this returns a plan tier, seat counts, renewal date, or payment state, and there is no output schema to fall back on. It is minimally sufficient to call, not sufficient to use the result.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate and the schema-object baseline of 4 applies. No parameter-level gaps exist.

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 phrase 'Plan and subscription status' is essentially a restatement of the tool's own title and name, with no verb to anchor the action. It does narrow 'billing status' to plan/subscription data, which is slightly more concrete than the identifier alone, but it does not distinguish this from billing-adjacent siblings like get_usage or get_referral_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 statement of when to call this versus get_usage, list_member_usage, or get_referral_stats, all of which sit in the same billing/account space. The only implied guidance is the scope requirement, which is a precondition rather than a usage 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 establish read-only, idempotent, non-destructive behavior, so the bar is lower. The description adds meaningful context by naming the required scope and disclosing that the response includes the transcript and coaching log, though it omits not-found or missing-transcript 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?

The definition is two short sentences with no wasted language, and the core action is front-loaded before the scope requirement.

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 getter with annotations and no output schema, the description gives the essential context: it retrieves one call and includes transcript and coaching log. The main remaining gaps are error behavior and parameter format details.

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?

There is one required `id` parameter, and schema description coverage is 0%, so the description must compensate. It only implies that the parameter identifies "a call" and does not explain the ID format, expected source, or any constraints.

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 ("Get a call") and adds the returned artifacts: transcript and coaching log. It is clear, but it does not explicitly distinguish itself from siblings such as list_calls or summarize_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?

It states the required scope `calls:read`, which is useful authorization context. However, it does not say when to use this tool versus alternatives like list_calls or summarize_call, nor when not to use 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?

The annotations already disclose that this is a read-only, idempotent, non-destructive operation. The description adds useful authorization context by naming the required scope `leads:read`, but it does not describe what happens if the lead is not found or what data is returned.

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

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

The description is brief and front-loads the action, with the scope requirement immediately following. There is no wasted text, though the brevity contributes to the gaps elsewhere.

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 tool this is still incomplete: the only parameter is undocumented, there is no output schema, and the description does not describe the returned lead or error behavior. The scope statement is helpful but insufficient to fully guide 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 0%, and the single `id` parameter is only typed as a string with no description. The description does not clarify whether this is a lead ID, its expected format, or where to obtain it, so it fails to compensate for the undocumented 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 'Get a lead' essentially restates the tool name and title, making it a tautology rather than an informative purpose statement. It does not distinguish this tool from siblings such as list_leads or update_lead beyond the obvious singular retrieval implication.

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 guidance is the required scope `leads:read`, which is a prerequisite rather than a usage guideline. There is no explicit statement about when to use this tool versus list_leads, update_lead, or upsert_lead.

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, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description adds nothing beyond repeating the annotation title — no note on auth requirements, what 'the request' means, or that it returns the caller's own identity.

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 padding, but it is under-specified rather than concise — the sentence fragment omits the action entirely, so brevity comes at the cost of clarity.

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

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

A zero-param read tool with complete annotations needs only a short clarifying line, but the description never states that it returns the authenticated team and API key identity of the current caller, which is the one fact an agent needs 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?

Zero parameters with an empty schema, so there is nothing for the description to compensate for. Baseline 4 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 text is a noun phrase restating the title, describing the returned resource rather than what the tool does. There is no verb (e.g., 'get', 'return') and no signal that this retrieves the calling identity, so it reads as a tautology of the name get_me.

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 call this versus siblings like get_team_config, list_api_keys, or get_billing_status, all of which could plausibly be confused with 'team and API key'. 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?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered structurally. The description's one addition is the required OAuth scope, which is genuinely useful auth context, but it says nothing about what the response contains or whether a link is minted on first call.

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

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

Two short sentences with no filler, and the resource statement is front-loaded ahead of the scope requirement. It is efficient, though the efficiency comes partly from under-specification rather than tight 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?

No output schema exists, so the description could reasonably say what the return looks like, but it leaves the payload shape (link URL vs. counters vs. both) unspecified. For a no-param read tool the bar is low and the scope note helps, but the ambiguity about returned content is 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?

The tool takes zero parameters, so the baseline is 4. There is nothing for the description to compensate for on this dimension.

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 phrase "Referral link and stats" names the resource but is a noun fragment rather than a specific verb+resource statement, leaving ambiguous whether the tool returns the referral link, aggregated stats, or both. There are no sibling referral tools to disambiguate against, which softens the cost, but an agent still cannot tell precisely what payload 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 only guidance is the auth prerequisite "Requires scope `referrals:read`". There is no statement of when to call this versus get_analytics_overview, get_usage, or list_leads, and no exclusions or preconditions beyond the scope.

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, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description's genuine contribution is the `team:read` scope requirement, which annotations do not express; however it says nothing about what the returned configuration comprises or whether it is cached/eventually consistent.

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 no filler. The first sentence largely restates the title, which is minor redundancy rather than bloat.

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

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

No output schema exists, so the description carries the burden of describing the return value, and it only gestures at it ("team settings and coaching context") without listing the kinds of fields returned. For a simple zero-parameter read this is tolerable but 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?

The tool takes zero parameters, which is the baseline-4 case. There is nothing for the description to disambiguate, and it correctly signals there are no filtering or selection options.

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 phrase "Team settings and coaching context" is a noun phrase identical to the annotation title, so it identifies the resource but does not state a verb (get/retrieve) or describe what the returned settings actually contain. The tool name supplies the verb, and the pairing with the sibling `update_team_config` implicitly frames this as the read counterpart, but the description itself does no differentiating work.

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 statement of when to call this versus `get_me`, `get_billing_status`, or `update_team_config`. The only contextual signal is the required scope, which is an authorization prerequisite 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=true, idempotentHint=true, destructiveHint=false, so safety is covered; the description adds the non-obvious `billing:read` scope requirement, which is exactly the kind of auth context that saves a failed call. It does not describe freshness/latency of the 'current period' figures, 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?

Two short sentences, the resource statement front-loaded and the auth prerequisite second. Every sentence carries information the agent needs; nothing is 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?

For a zero-argument, read-only reporting call with no output schema, the definition covers what is measured and what access is needed. A brief hint at the shape of the returned usage figures (per-seat vs per-token, period boundaries) would close the remaining gap, but 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?

The tool takes zero parameters, so there is nothing for the description to disambiguate; the baseline for a parameterless tool applies. The description correctly avoids inventing filtering options that the schema forbids (additionalProperties: false).

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 (token and seat usage) and a specific time scope (current period), which is far more than a restatement of the name. It does not differentiate itself from overlapping siblings like get_billing_status or list_member_usage, so the agent must infer the boundary from the 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?

The description gives no when-to-use guidance and never mentions the adjacent billing/usage tools it could be confused with. The only actionable context is the required scope, which is a prerequisite rather than a routing 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 readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely useful context by stating the required scope `webhooks:read`, but says nothing about behavior when the ID doesn't exist or what a successful call yields.

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 with zero filler. Brevity is close to under-specification, but nothing stated is wasted.

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

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

There is no output schema, so the description would ideally hint at what a webhook endpoint object contains or at least confirm it returns the endpoint record; it doesn't. For a one-parameter read-only getter with strong annotations, it is minimally adequate but leaves the return value and failure mode unstated.

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

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

Schema description coverage is 0% for the single `id` parameter, so the description must compensate and it does not — it never says what form the webhook endpoint ID takes or where to obtain it (e.g., from list_webhook_endpoints).

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 a webhook endpoint'), which is unambiguous against most siblings. It does not differentiate from list_webhook_endpoints or make explicit that this is a single-resource fetch by ID, so an agent must infer the distinction from 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?

No guidance on when to use this versus list_webhook_endpoints or update_webhook_endpoint, and no mention of prerequisites beyond the scope. The only signal is the tool name plus a required id 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?

Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description is freed from carrying the safety profile. It still adds value the annotations don't: revoked keys are included in results, pagination is cursor-based and iterative, and a specific OAuth-style scope is required. Return shape/ordering is left unspecified, keeping it off a 5.

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

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

Three short lines, no filler; the resource identity comes first, then the mechanics an agent actually needs mid-call (pagination), then the precondition. Every sentence earns its place.

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

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

For a two-param, zero-required read tool with no output schema, the description covers inclusion scope, pagination loop, and auth scope — enough to call it correctly and interpret results. What a key record contains (fields, whether secrets are masked) is not described, a minor gap given no output schema exists.

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

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

Schema description coverage is 100%, with both `limit` (bounds and default) and `cursor` fully documented in-schema. The description's cursor sentence largely restates the schema wording, adding no new syntax or format detail, 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 ('List API keys') and adds a scope qualifier ('including revoked') that meaningfully sharpens what will come back. Against siblings create_api_key, rotate_api_key, and revoke_api_key, the read-only listing intent is unambiguous from the lead verb 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?

Gives concrete operational guidance: how to paginate ('pass `cursor` = `next_cursor` from the previous result') and the prerequisite scope `api_keys:read`. It does not explicitly name when to prefer a sibling, but the listing-versus-mutating split is self-evident from the sibling names.

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, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: results are newest-first, responses are paginated with a next_cursor loop, and the caller needs the `calls:read` scope. Return field shape and rate limits remain undisclosed.

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, front-loaded statements: what it returns and in what order, how to paginate, what scope is needed. No filler, and the most operationally important facts come first.

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

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

With seven parameters, no output schema, and no nested objects, the description covers ordering, pagination, and auth but never describes the response shape beyond implying a `next_cursor` field, nor does it explain filters like `member_id` or `archived`. Adequate to call correctly, thin for interpreting results.

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 86%, so the schema already explains `to`, `from`, `limit`, `cursor`, `archived`, and `member_id`. The description's cursor sentence largely restates the schema's own '`next_cursor` from the previous page' wording, adding no syntax, format, or interaction detail (e.g., how `from`/`to` interact with `period`). Baseline 3 is appropriate.

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

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

States a specific verb and resource ('List calls') plus an ordering guarantee ('newest first'), which distinguishes it from the singular get_call sibling. It stops short of naming alternatives like export_calls or get_call explicitly, so the separation 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?

The description gives the pagination recipe and the required scope, which implies 'use this to enumerate calls.' But it never says when to prefer get_call, export_calls, or the analytics siblings, nor when the archived flag should be used. Usage is implied, not guided.

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, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds useful authorization context (`coaching:read`) and content coverage (built-in and team styles), but does not mention return shape, ordering, or pagination; with annotations carrying safety, 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?

Two short lines with no filler, and the resource category is front-loaded. The first line is a fragment and could be a complete sentence, but it is appropriately terse for a zero-parameter list tool.

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 zero-parameter list tool, it gives the key authorization scope and indicates the two style categories. It still does not explicitly say it returns a list or whether built-in and team styles are combined, leaving a small inference gap despite the low complexity.

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?

There are no parameters, so parameter semantics are minimal by definition. The empty schema is self-contained, and the description introduces no parameter-related confusion.

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 resource and its scope (built-in and team coaching styles), but omits an explicit verb; it reads as a title fragment rather than 'lists'. The plural name and create/update siblings imply a read operation, but the action is not stated in the description 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?

It provides the required OAuth scope `coaching:read`, but gives no guidance on when to choose this tool over `create_coaching_style` or `update_coaching_style`, nor when not to use it. A prerequisite scope is useful but is not a when-to-use guideline.

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, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds a useful non-annotation detail — the required `team:read` scope — which helps an agent predict auth failures, but says nothing about return shape or pagination.

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 operation stated first and the auth requirement second; nothing is wasted.

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

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

For a zero-param read-only list tool with full annotation coverage, the description plus scope note is nearly sufficient. It could mention what a pending invite contains, but the gap is minor since there is no output schema to defer to.

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 clarify; baseline 4 applies.

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

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

States a specific verb and resource ('List pending invites'), which is clearly distinct from siblings like create_invite and cancel_invite. It doesn't explicitly name those siblings, but the resource disambiguation is implicit enough for selection.

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 versus related invite tools (create_invite, cancel_invite) or any prerequisites beyond the scope requirement. 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 readOnly, idempotent and non-destructive, so the description correctly focuses on what they don't cover: the newest-first ordering, the exact pagination contract for cursor/next_cursor, and the required `leads:read` scope. That is meaningful added context for an agent planning calls, though rate limits or total-count behavior are unmentioned.

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 lines, each earning its place: identity and ordering first, then pagination mechanics, then the auth requirement. Fully front-loaded with 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 five-parameter list tool with no output schema, the description should at minimum hint at what a lead record contains or what `stage` and `source` accept. Pagination and auth are well covered, but the filter parameters and the return shape remain 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 60%; the description explains `cursor` but that is already documented in the schema description, so it adds little. The undocumented `stage` and `source` filter parameters are covered by neither schema nor description, though `limit` and `search` are explained in the schema.

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

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

States a specific verb and resource ('List leads') plus the ordering guarantee ('newest first'), which is useful scoping information an agent can't get from the name alone. Siblings such as get_lead, update_lead and upsert_lead are clearly different operations, so no explicit differentiation is 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?

Usage is only implied by the verb 'List' – the description never states when to reach for this versus get_lead or upsert_lead, nor any preconditions beyond the scope. Adequate for an obvious list operation but no explicit guidance is given.

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

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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the safety profile is covered. The description's one contribution is the required OAuth scope, which is genuinely additive and not expressible in the schema. However it says nothing about pagination, ordering, or what a member entry contains, so it does not rise above adequate.

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, with the resource statement front-loaded and the auth requirement following. Every sentence earns its place.

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

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

For a no-parameter read tool with full annotation coverage, the description plus annotations give an agent enough to call it correctly. The remaining gap is that no output schema exists and the description does not hint at what a returned member record or list shape looks like, including whether the list is paginated.

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

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

The tool takes zero parameters and the schema is fully closed (additionalProperties: false), so there is nothing for the description to clarify. A 4 is the baseline for a parameterless tool, and the description correctly avoids inventing parameter talk.

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

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

States a specific verb and resource ("List team members") that an agent can immediately distinguish from the nearest sibling, list_member_usage, which is about per-member usage data rather than roster membership. It falls short of a 5 because it never names that sibling or any boundary 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 description gives a prerequisite (scope `team:read`) but no guidance on when to choose this versus alternatives such as list_member_usage or list_invites. The use case is implied by the name and is fairly self-evident, which fits a 3.

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

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

Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds two pieces of context beyond that: the required `billing:read` scope and the fact that results are bounded to the current billing period, both of which materially affect a call.

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

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

Two short sentences with nothing wasted, and the scope requirement is called out separately so it is easy to check. It is slightly under-specified rather than bloated; a verb-led opening would have made it sharper.

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

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

With no parameters and no output schema, the description is the only source of information about the result, and it never says what metrics per member are included (calls, minutes, cost) or whether historical periods are reachable. That is a meaningful gap for a reporting endpoint, though the core intent is legible.

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 no parameters, so there is nothing the description could clarify; the baseline for zero-param tools applies. The 'current period' phrasing does implicitly confirm there is no date-range parameter.

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 resource and scope (per-member usage, current period), so an agent can roughly infer the output. However, it is a noun phrase with no verb and gives no hint how it differs from lookalike siblings such as get_usage or get_analytics_by_member.

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

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

There is no statement of when to call this versus get_usage, get_analytics_by_member, or get_billing_status. The only usage signal is the scope requirement, which is an access precondition rather than a routing 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, idempotentHint, and destructiveHint=false, so the description isn't burdened with safety disclosure. It adds genuinely useful non-annotation detail: result ordering (newest first), the exact pagination loop (pass `next_cursor` back as `cursor`), and the required `webhooks:read` scope. It stops short of describing what a delivery record contains or how far back the log goes.

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 lines: purpose first, then the pagination mechanic, then the auth requirement. No filler, and the most decision-relevant fact is front-loaded.

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

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

For a read-only, paginated list tool with no output schema, the description covers ordering, pagination, and required scope, which is most of what an agent needs to call it correctly. The gap is the undocumented `status` filter, which could cause an agent to fetch and filter client-side instead of using the parameter.

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?

At 50% schema coverage, the description reinforces the cursor pagination contract but adds nothing about the `status` filter (a pending/succeeded/failed enum with no explanation anywhere) or what `id` refers to beyond 'an endpoint'. The pagination mechanics are the most valuable part and are already partly in the schema's cursor 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+resource+scope: a delivery log for a single endpoint, ordered newest first. This clearly separates it from list_webhook_endpoints (endpoints vs. deliveries) among its siblings, though it never names the alternative tools 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 phrase 'Delivery log for an endpoint' implies you call this to inspect past delivery attempts, but there is no explicit when-to-use guidance, no mention of related siblings like replay_webhook_delivery or get_webhook_endpoint, and no stated prerequisites beyond the scope. Usage is inferable 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?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds value with the auth scope requirement and the pagination behavior, which annotations cannot express; only the total/count semantics of the result set are left unstated.

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 lines with the purpose front-loaded and no filler. The pagination sentence partially duplicates the schema's cursor description, a small redundancy, but nothing is wasteful.

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 only two optional parameters and no output schema, the description covers purpose, auth, and pagination — the essentials for correct invocation. It omits any indication of what an endpoint record contains, which would help an agent decide whether this tool answers its question, but the gap is minor.

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

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

Schema description coverage is 100%, so both `limit` and `cursor` are already documented, including the `next_cursor` convention. The description's cursor line largely restates the schema, adding no new syntax or constraint beyond 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?

States a specific verb and resource ('List webhook endpoints'), which is immediately distinguishable from the singular get_webhook_endpoint and from list_webhook_deliveries by the object named. It does not explicitly name a sibling or clarify the boundary, 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?

Gives the operational context needed to use it: the required `webhooks:read` scope and the exact pagination loop (pass `next_cursor` as `cursor`). It offers no explicit when-not guidance or alternatives (e.g., use list_webhook_deliveries for delivery history), so it is clear context without exclusions.

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

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

Adds substantial context beyond the annotations: required scope `team:write`, the fact that the member retains their account and call history, and the limitation that managers cannot be removed via the API. The annotations declare destructiveHint/idempotentHint, but the description supplies the auth, side-effect, and eligibility details they do not.

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 points are front-loaded, but "DESTRUCTIVE: this cannot be undone" and "DESTRUCTIVE: cannot be undone" appear as two separate lines, duplicating a warning the annotations already carry once. That repetition costs space 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?

For a single-parameter destructive mutation with no output schema, the description covers safety, permissions, eligibility, and data-retention effects. The only meaningful omission is the meaning/format of `id`.

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 `id` parameter has 0% schema description coverage, and the description says nothing about it — not whether it is a member ID, user ID, or email, nor how to obtain it. With one undocumented parameter, the description needed to compensate and does not.

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

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

Specific verb+resource ("Remove a member from the team") stated up front, so the operation is unambiguous. It does not name a sibling (e.g., list_members) to contrast with, but no sibling is plausibly confusable with a removal operation.

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?

"Only call it when the user explicitly asked for exactly this action" is an explicit, actionable gating condition, and "managers can't be removed via the API" defines a real exclusion. No alternative tool is named, so it stops short of full when/when-not routing.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=false, and destructiveHint=false. The description adds real value the annotations lack: the required scope `webhooks:write` and the fact that replay creates a *new* delivery record rather than reusing the old one. It stops short of saying what happens to the original delivery or how failures are reported.

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 core action front-loaded and the auth prerequisite second. Nothing is wasted, though given the parameter gaps the brevity is somewhat at the expense of necessary 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?

Covering a mutation with 2 params and no output schema, the description conveys the essential action and auth scope but omits replay-specific behavior: whether the original delivery is affected, delivery ordering, and what happens for already-succeeded deliveries. Adequate to invoke, incomplete to call confidently.

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% for both required parameters (id, deliveryId), so the description must carry the burden. It hints that `id` is the webhook id and that a delivery is selected, but never explicitly maps `id`/`deliveryId` to their roles or clarifies whether `id` is a webhook or delivery identifier.

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 action — re-queuing the same message as a new delivery record — with the key mechanism (same webhook-id, new delivery). It does not, however, distinguish this from sibling tools like test_webhook_endpoint, which is the most likely point of confusion for an 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?

There is no explicit when-to-use, when-not-to-use, or named alternative. An agent can infer this replays an existing delivery in contrast to test_webhook_endpoint, but the description never says so, leaving the critical distinction unstated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is partly covered; the description still earns credit by adding the irreversibility statement and the required `api_keys:write` scope, which annotations do not convey. It loses polish by repeating the same DESTRUCTIVE/cannot-be-undone warning twice and never saying what actually happens to the key (immediate invalidation? retained record?).

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 lead sentence and the explicit-use warning are front-loaded and useful. But the DESTRUCTIVE warning is duplicated verbatim, wasting a full line and diluting the warning's force.

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

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

For a one-parameter destructive mutation with annotations covering the danger flag, the description gives the essentials: irreversibility and required scope. It leaves out the undocumented parameter's meaning and the post-call effect, which are the two things an agent still needs before invoking.

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 `id` parameter has 0% schema description coverage, so the description carries the full burden — and it says nothing about what `id` is. An agent cannot tell from either source whether this is the key's opaque ID, its prefix, or the secret value.

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 ("Revoke an API key"), which is instantly understandable. However, it does not differentiate from the close sibling rotate_api_key (or list_api_keys/create_api_key), so an agent scanning the toolset must infer the 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?

Gives a clear gating condition: "Only call it when the user explicitly asked for exactly this action," which is strong guidance for a destructive tool. It stops short of naming alternatives — it never says to prefer rotate_api_key when the intent is replacement rather than removal.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety bar is lower, yet the description adds real value: the old secret stops working immediately and the call requires scope `api_keys:write`. The duplicated "DESTRUCTIVE: cannot be undone" lines restate what annotations already say, adding no new information.

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 sentence and scope requirement are front-loaded and efficient, but the destructive warning is stated twice in near-identical wording, which wastes space 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?

Risk, scope requirement, and the effect on the old secret are all covered, which is solid for a destructive mutation. However, there is no output schema and the description does not say whether the new secret is returned in the response — critical for a rotation tool the agent may need to surface to the user — nor does it clarify the `id` parameter.

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 single parameter `id` is never mentioned in the description. The agent is told what the tool does but not that it must supply the API key's identifier, leaving a real gap for a one-parameter mutation.

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 ("Replace the key's secret") plus the immediate consequence, so the agent can distinguish it from create_api_key and revoke_api_key. It does not explicitly contrast with the near-identical sibling rotate_webhook_secret, which would have made the differentiation airtight.

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?

"Only call it when the user explicitly asked for exactly this action" is an explicit when-to-use guardrail, and the destructive framing makes the exclusion clear. It stops short of 5 because it never names the alternative paths (revoke_api_key, create_api_key) an agent might confuse it with.

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

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description adds materially new behavior: the old secret is replaced immediately, the new secret is displayed only once, it must be surfaced to the user and not echoed elsewhere, and a specific auth scope is required. These are operational constraints the agent cannot infer from the annotations.

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

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

Front-loaded and mostly tight, but the DESTRUCTIVE warning is repeated verbatim-twice ("DESTRUCTIVE: this cannot be undone") in a five-line description, wasting space in an otherwise compact text.

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 single-parameter mutation with no output schema, the description covers safety, auth, and post-call handling well. The only meaningful gap is the unexplained `id` parameter, which is a moderate omission rather than a blocking one.

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?

There is one required parameter, `id`, with 0% schema description coverage, and the description never mentions it. The agent must infer that `id` is the webhook endpoint identifier from the tool name and sibling list rather than from the definition.

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 ("Replace the signing secret") and adds the two facts that define the operation's scope: the new secret is returned once and takes effect immediately. Clearly distinguishable from siblings like rotate_api_key or update_webhook_endpoint.

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 an explicit gating condition: "Only call it when the user explicitly asked for exactly this action," plus the prerequisite scope `webhooks:write`. That is a clear when-to-use and when-not-to-use rule rather than implied usage.

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 annotations, the description discloses three real behaviors: an existing summary is returned rather than regenerated, generation consumes the team's token quota, and the `calls:write` scope is required. The quota/scope disclosure is exactly the kind of cost-and-auth context annotations cannot express, though there is mild tension with idempotentHint=false since reuse implies repeated calls may be free.

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, front-loaded lines: what it does, what it costs, what it requires. Every sentence carries distinct information with no waste.

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

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

For a one-parameter mutation with no output schema, the cost and auth prerequisites are covered, but the description says nothing about what the returned summary looks like or what happens when a summary cannot be generated (too-short call, unsupported language).

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 single parameter `id` is never mentioned in the description — it is not stated whether this is a call ID, and no format or error behavior (e.g., invalid/nonexistent call) is given. The agent must infer the target object entirely from the tool name and sibling get_call.

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+resource ('Generate ... AI summary') and clarifies the reuse behavior with '(or return the existing)', which meaningfully distinguishes it from read-only siblings like get_call. It never states that the summary is of a call, leaving the object implicit in the tool name.

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

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

The quota warning implies 'call only when you actually need a summary', which is useful implied guidance, but there is no explicit when-to-use statement and no named alternative (e.g., get_call returning an already-summarized call).

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 this is non-read-only, non-idempotent, non-destructive, and not open-world. The description adds useful behavioral context beyond those annotations: the event is signed, it is sent immediately, and the tool returns the delivery result. It could say more about delivery side effects, but with annotations present this is a solid addition.

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 wasted words. The primary action is front-loaded, and the authorization requirement follows 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?

For a simple one-parameter tool, the description covers the action, authorization requirement, and return intent. However, it omits any explanation of the required `id` and gives only a minimal phrase for the delivery result, which matters because there is no output 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?

The schema has one required `id` parameter with 0% description coverage, and the tool description never explains what the `id` refers to. The tool name hints that it is a webhook endpoint ID, but that meaning is not stated in the description, so parameter semantics are left largely to inference.

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: sending a signed `webhook.test` event and returning the delivery result. It is clear enough to distinguish from most webhook CRUD siblings, but it does not explicitly contrast with `replay_webhook_delivery` or explain that this is for endpoint testing rather than replaying stored deliveries.

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 prerequisite (`webhooks:write`) and the implied use case of testing a webhook endpoint, but it does not state when to use this instead of `replay_webhook_delivery` or how it relates to listing deliveries. The guidance is adequate but not explicit about 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 this is a non-read-only, non-destructive, non-idempotent, closed-world operation. The description adds the required `calls:write` scope, which is useful auth context, but it does not explain behavior if the call is already unarchived or what side effects occur.

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 two short sentences with the action front-loaded and the auth requirement clearly separated. Every sentence earns its place.

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

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

For a simple one-parameter mutation, the description covers the action and required scope, and annotations carry the safety profile. However, it leaves the `id` parameter undocumented and does not describe the state transition if the call is already active.

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 sole parameter is `id`, and the schema provides 0% description coverage. The description does not explain what `id` refers to or its expected format, though 'Restore an archived call' weakly implies it is the call identifier.

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 precise action and target: 'Restore an archived call.' This is specific enough to distinguish it from the inverse sibling archive_call without ambiguity.

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 does not say when to use this tool versus archive_call, nor does it describe prerequisites beyond the OAuth scope. Usage is only inferable from the name and 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?

Annotations already declare non-destructive, idempotent, closed-world mutation semantics, so the bar is lower; the description usefully adds the required auth scope. What it omits is critical: whether omitted optional fields are left unchanged or cleared, and what a successful response looks like — a real ambiguity for a 7-param update.

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 scope gate — no filler. It is tight but arguably too sparse given the parameter surface it leaves unexplained.

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

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

For a 7-parameter mutation tool with no output schema and zero schema description coverage, the definition should say how fields combine and what changes persist. Instead the agent is left to guess at patch-vs-replace semantics and field meanings.

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 7 parameters, so the description carries the full burden and delivers nothing: `id` (the only required param), `objectionStyle`, `toneDescriptor`, `closingPhilosophy` and `personalityPrompt` are never explained. The agent must infer all field semantics from bare property names.

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 ("Update a custom coaching style"), which clearly separates it from create_coaching_style and list_coaching_styles in the sibling set. It doesn't explicitly name those siblings as alternatives, so it falls just short of a 5.

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

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

The `coaching:write` scope requirement is a concrete prerequisite that tells the agent when this tool is callable. However, there is no guidance on when to update versus create a style, or what happens if the id doesn't exist — usage is only implied.

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

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

Annotations already declare readOnly=false, idempotent=true, destructive=false, so the safety profile is covered structurally. The description adds the meaningful patch semantics ("only provided fields change") plus the auth scope, but stays silent on what happens with an unknown `id`, and critically on whether the `notes` array is replaced or appended.

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

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

Two tight sentences with zero filler, and the partial-update behavior is front-loaded before the permission requirement. It is efficient, though the extreme brevity is partly the cause of the gaps flagged elsewhere.

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

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

For an 12-parameter mutation with nested objects, no output schema, and a sibling `upsert_lead` that overlaps functionally, the description is too thin. An agent still cannot tell how `notes` entries merge, how to clear a nullable field, or what the call returns.

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

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

With 12 parameters and only 17% schema description coverage (only `value` and `externalId` are annotated), the description carries the compensation burden and supplies nothing — no field-level meaning, no note on null-clearing versus omission, and no explanation of the nested `notes`/`metadata` structures.

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

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

Specific verb+resource ("Update a lead") with a parenthetical that defines the semantics as a partial/patch update, which is genuinely useful. It does not distinguish the tool from the closely related `upsert_lead` sibling, so the agent must infer when PATCH-update is preferable to upsert.

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 scope requirement `leads:write` is a real prerequisite an agent must satisfy before calling. Beyond that there is no guidance on when to use this versus `upsert_lead` (which the schema itself says POST-upserts on `externalId`), leaving the main routing decision unaddressed.

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

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

Annotations already declare readOnlyHint=false, idempotentHint=true, and destructiveHint=false, so the description's scope requirement (`team:write`) is the main added value. It says nothing about the partial-update merge semantics, what happens to fields omitted from the payload, or how null values clear settings — meaningful gaps for a config mutation, but not contradictions.

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 mutation verb is front-loaded. It is efficient but under-specified rather than wasteful — the terseness is the problem, not the length.

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 19-parameter, all-optional mutation with no output schema, the description should cover partial-update semantics, null-clearing, and write-only secret handling. None of that is present, leaving an agent unable to call it confidently without guessing at merge behavior.

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

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

Schema description coverage is only 11% across 19 parameters, and the description adds no parameter meaning whatsoever — it does not explain name, industry, setGoals, the *Locked booleans, or the null-to-clear behavior of coachingStyleId. The schema itself only annotates the two write-only secrets, 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 a specific verb+resource ("Update team settings"), which is clearly distinguishable from read siblings like get_team_config. However, it does not name the alternative or clarify the relationship to get_team_config, and "settings" is left broad relative to the 19 specific fields in the schema.

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

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

The only guidance is the required scope `team:write`. There is no statement of when to use this versus get_team_config, whether partial updates are supported, or whether omitted fields are preserved or cleared — the single most important usage question for a 19-parameter mutation with zero required fields.

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 non-readonly, idempotent, non-destructive and closed-world, so the safety profile is covered structurally. The description adds the concrete authorization requirement (`webhooks:write`), which is real value, but says nothing about whether updates are partial or full replacement, or what disabling implies for in-flight deliveries.

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 no filler, and the capability statement is front-loaded before the scope requirement. It is perhaps too terse rather than padded, but nothing is wasted.

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

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

A mutation tool with five entirely undocumented parameters and no output schema needs more: which fields are optional, whether omitted fields are preserved, and what happens to `events` when supplied. Only the permission requirement is filled in.

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 five parameters, so the description carries the burden and largely fails: only `active` is obliquely referenced via 'disable or re-enable'. `url`, `events`, `description` and the required `id` receive no explanation of semantics or constraints.

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 (update) and resource (webhook endpoint) plus the two special modes (disable, re-enable). It is clear against create/delete/list siblings, though it does not name 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?

No guidance on when to choose this over delete_webhook_endpoint, rotate_webhook_secret, or test_webhook_endpoint, nor any prerequisites beyond the scope note. The agent must infer that disabling is the alternative to deletion.

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

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

Adds real value beyond annotations by disclosing the required scope `leads:write`. However, it omits the critical upsert behaviors: whether omitted fields are nulled or preserved on update, and whether `name` is required even when updating an existing lead. There is also an unresolved tension with idempotentHint=false, since keying updates on externalId reads as 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?

Two short sentences, the upsert condition is front-loaded, and the scope requirement is stated tersely. Zero wasted words for the amount of text present.

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

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

For an 11-parameter mutation with a nested notes array, no output schema, and thin schema descriptions, the description is far too thin. An agent cannot tell what the call returns, how partial updates are handled, or what happens to notes arrays on a repeat call.

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 18% across 11 parameters, with nested objects (notes) and enums-free nullable fields that need explanation. The description explains none of them — fields like stage, value (cents), and metadata semantics, plus merge behavior on update, are left entirely to an under-documented schema.

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

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

States a specific action and resource with the key insight that it is an upsert keyed on externalId ('Create a lead, or update the one with the same externalId'), which lets an agent distinguish it from a plain create. It does not explicitly contrast with siblings update_lead / batch_upsert_leads, 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 externalId keying implies when this tool is appropriate (records that have a CRM id), but there is no explicit when-to-use vs update_lead, and no guidance on behavior when externalId is omitted or null. Usage must be inferred from the upsert semantics.

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