SyncSignature Email Signatures

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

Annotations already declare readOnlyHint=false and idempotentHint=true, so the mutation/idempotency profile is covered. The description adds value beyond structured data by disclosing the hidden side effect: a signature is generated per teammate from the group's template. It does not say what happens to an existing signature or whether template absence causes failure, keeping it below a 5.

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

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

Two short sentences, both informative, with the primary action stated first and the consequence 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?

For a simple two-parameter tool with annotations covering safety and no output schema, the description covers purpose, side effect and usage cue. The main remaining gap is precondition/error behavior (missing template, already-assigned teammate), which is minor given the annotation set.

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

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

Schema coverage is 100% and both parameters already point to list_groups and list_teammates as the source of ids. The description adds no further meaning about group_id or teammate_ids, so baseline 3 applies.

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

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

States a specific verb (assign) and resource (teammates to a group) and adds the resulting side effect: each teammate gets a signature built from the group's template. This makes it unmistakable versus the inverse sibling remove_teammates_from_group and versus update_teammate.

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?

"This is how a person gets a signature" gives an explicit context for reaching for this tool rather than get_teammate_signature or preview_signature. It stops short of stating preconditions (group must have a template) or naming the alternative explicitly, 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?

Annotations already declare this is a non-read-only, non-destructive create operation. The description adds useful behavioral context that template_id determines whether teammates can be assigned and that signatures are built from the group's template, though it omits permissions and duplicate-handling 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 the purpose first and the key template constraint second. There is no filler or repetition.

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

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

For a two-parameter create tool with no output schema and annotations covering the safety profile, the description supplies the essential purpose and the key template_id consequence. It leaves minor gaps around duplicate handling and permissions, but nothing critical for 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 coverage is 100%, so both parameters are already documented. The description adds meaningful semantics for template_id by explaining its downstream effect on assignment and signatures, but it says nothing additional about name.

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 precise verb and resource, "Create a group," so the operation is unambiguous. It does not explicitly contrast with siblings such as update_group or create_teammate, but the resource distinction is strong enough for clear 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?

It explains a downstream condition for template_id: teammates cannot be assigned without it. However, it does not state when to choose create_group over alternatives or list prerequisites for group creation, so usage is mostly implied by the name and the template dependency.

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

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

Annotations already cover the safety profile (not read-only, not destructive, not idempotent, closed world). The description adds real context beyond them: a newly created field does not render in signatures until it is placed into a template, which is a non-obvious consequence an agent would otherwise miss.

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

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

Two short sentences with zero waste. The core purpose is front-loaded and the non-obvious lifecycle caveat 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?

With annotations and full schema coverage plus no output schema, the description is nearly complete. The one gap is that it never says what comes back (e.g., the new field's identifier), which an agent likely needs to place the field into a template — the very follow-up step the description raises.

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

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

Schema description coverage is 100% and the enum descriptions for source and data_kind are unusually rich (including the UNMANAGED/MANUAL default behavior). The description adds nothing about parameters, so baseline 3 applies.

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

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

States a specific verb and resource: 'Add a custom field to the workspace registry.' The create verb clearly separates it from update_smart_field, delete_smart_field, and list_smart_fields, though it never names those siblings explicitly.

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

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

Usage is implied by 'Add a custom field to the workspace registry,' but there is no explicit when/when-not guidance, no mention of prerequisites, and no routing to update_smart_field for existing fields. The second sentence hints at lifecycle but not at tool selection.

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 the mutation profile (readOnly=false, idempotent=false, destructive=false), and the description adds meaningful context beyond them: it creates an account, a membership, and a signature, and that passing group_id installs a group template. That cascade of side effects is not derivable from the schema or annotations. It stops short of noting error behavior (e.g., duplicate email) or return values.

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 operation front-loaded and the group_id caveat immediately after. Every clause carries information; nothing 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 7-parameter creation tool with no output schema, the description covers the essential behavior and the non-obvious group template effect. Minor gaps remain — nothing about what is returned (e.g., the new teammate's id) or how conflicts like an existing email are handled.

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

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

Schema description coverage is 100%, so every parameter is already documented; the baseline is 3. The description's note about group_id installing a template mirrors the schema text rather than adding new semantics, so it does not exceed the schema's contribution.

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

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

States a specific verb and resource ('Add a teammate to the workspace') and clarifies the side effects — account, membership, starting signature — so the agent knows this is a full provisioning operation, not just a contact record. It does not name or differentiate from siblings like update_teammate or add_teammates_to_group, which keeps it below a 5.

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

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

The sentence about group_id implies a usage pattern (assign a group to get its template), and the schema points to list_groups, but the description never states when to use this versus update_teammate or add_teammates_to_group, nor any prerequisites. Usage is inferable but not spelled out.

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 (which only declare non-readonly, open-world, non-idempotent), the description discloses the destructive-safety mechanism (first call saves nothing), what is left as placeholders (teammate fields), and the blast radius (no teammate's signature changes until the template is assigned to a group). It also flags the auth requirement, which the annotations 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?

Front-loaded with purpose, then the workflow, then the caveats — a logical order with little filler. It is dense and runs long as a single block, and the trailing 'Owner only' is tacked on rather than integrated, but every sentence 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 an open-world, non-idempotent mutation with no output schema, the description covers the lookup inputs, the preview return, the confirmation gate, the default template layout, and the grouping caveat. Nothing an agent needs in order to call it correctly is missing.

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

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

Schema description coverage is 100%, so all five parameters are already documented, including dry_run's default and template_id's default of 56. The description's statements about dry_run largely restate the schema, though it does frame the parameter inside the confirmation workflow rather than in isolation.

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 (build a branded workspace template from a company domain) and enumerates exactly what gets looked up and filled in. An agent can distinguish it from list_workspace_templates, get_workspace_template, and create_group without opening any schema.

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

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

Gives an explicit two-step protocol: dry_run defaults true and saves nothing, show the preview, wait for a clear yes, then re-call with the same inputs and dry_run false. It also states the access precondition ('Owner only') and notes the template starts ungrouped so nothing changes until assignment.

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, yet the description still earns its keep by disclosing blast radius — signatures that received the banner are mutated too — and confirming irreversibility in plain language. It stops short of saying whether those signature edits are themselves recoverable or what permissions are required.

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

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

Two short sentences, zero filler. The destructive side effect leads and the irreversibility warning closes — exactly the front-loaded 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 one-parameter destructive tool with no output schema, the critical facts — what gets destroyed, that it cascades to signatures, that it cannot be undone — are all present, and annotations cover the safety profile. Only the recovery/alternative path is left unaddressed.

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

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

Only one parameter, and the schema already documents it fully ('Campaign id from list_campaigns') at 100% coverage. The description adds no id format, sourcing, or validation detail beyond that, so the baseline 3 applies.

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

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

States a specific verb (delete) and resource (campaign) plus the secondary effect: the banner is stripped from every signature it reached. That scope language makes it unmistakable against list_campaigns, update_campaign, pause_campaign, and resume_campaign without naming 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?

'Not reversible' signals a caution-worthy operation, implying an agent should prefer pause_campaign when it only wants to stop delivery, but that alternative is never named. No prerequisites (e.g., whether the campaign must be paused or who may delete) are given, so the guidance is inferred rather than stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, so the safety profile is partially covered. The description adds genuinely new behavior: the deletion cascades to signatures built from the group, all members lose signatures, and the action is irreversible — details not derivable from the annotations alone.

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, zero filler, and the most important information (cascade scope and irreversibility) is placed up front where the agent will act on it before invoking the 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 single-parameter destructive tool with full schema coverage and no output schema, the description covers the critical unknowns: what else gets destroyed, who is affected, and that the operation cannot be reversed. Nothing an agent needs before calling it 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?

There is a single required 'id' parameter and schema description coverage is 100%, with the schema itself pointing to list_groups as the source. The description adds no format, prefix, or sourcing guidance beyond what the schema already provides, so the baseline of 3 applies.

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

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

States a specific verb and resource ('Delete a group') plus the cascade scope ('AND the signatures built from it'), which clearly separates it from siblings like update_group or remove_teammates_from_group. The scope qualifier is front-loaded and 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?

Destructive intent is implied and the consequence ('Everyone in it loses their signature. Cannot be undone.') steers the agent toward caution, but there is no explicit when-to-use/when-not guidance or mention of alternatives such as update_group for reversible changes. Usage is inferred rather than stated.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the safety profile is covered structurally. The description adds genuinely new behavioral facts beyond that: two server-side guard conditions that cause refusal, which an agent cannot infer from the annotations. It stops short of saying what happens to the field's values or whether the refusal is an error versus a no-op.

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, no filler, with the core action first and the blocking conditions immediately after. Every clause carries information an agent needs before calling.

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 tool with full annotations and no output schema, the description covers the main surprise (refusal on in-use and built-in fields). Only a note on irreversibility or the effect on existing template references to the deleted field is missing.

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

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

Schema coverage is 100% and the single parameter is documented as "Smart field id from list_smart_fields." The description adds no further parameter meaning — no format, prefix, or validation detail — so the baseline of 3 applies with the schema doing all the work.

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?

"Remove a custom field from the registry" gives a specific verb (remove) plus resource (custom/smart field) scoped to the registry, which separates it in kind from create_smart_field, update_smart_field and list_smart_fields. It does not explicitly name any sibling or state that update_smart_field is the non-destructive alternative, so it falls short of the full sibling-differentiation bar.

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 supplies concrete usage conditions: the call is refused while any template still references the field, and built-in fields cannot be deleted. That tells an agent both when the call is valid and the two exclusion cases, though it never names what to use instead (e.g. update_smart_field to repurpose, or removing template references 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 destructiveHint=true and idempotentHint=true, so the safety profile is covered. The description adds genuinely useful context beyond the annotations: the irreversible nature and the side effect of deleting the teammate's signature, which the agent needs before calling.

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

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

Two short sentences with zero waste; the destructive scope is front-loaded and the irreversibility warning 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 one-parameter destructive tool with full annotation coverage and no output schema, the description supplies the two things that matter most: what gets deleted (teammate plus signature) and that it is permanent. Only the absence of explicit alternatives/preconditions keeps it from a 5.

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

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

Schema description coverage is 100%, and the single 'id' parameter is already documented as 'Teammate id from list_teammates.' The description adds no syntax, format, or sourcing detail beyond what the schema provides, so baseline 3 is appropriate.

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

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

The description names a specific verb and resource ('Remove a teammate from the workspace') and adds a non-obvious scope detail ('delete their signature'), so an agent can distinguish it from update_teammate or get_teammate. It doesn't name siblings explicitly, but the destructive framing makes the distinction 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?

There is no explicit when-to-use guidance or named alternative (e.g., update_teammate for reversible changes vs. this tool for permanent removal). The phrase 'Cannot be undone' implies this is a last-resort operation, but the agent must infer that.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the result includes signature detail values, which is useful since there is no output schema, but it says nothing about error behavior or access requirements.

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

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

A single, front-loaded sentence with no filler. Every part of it contributes to understanding what is returned.

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 read tool with full schema coverage and rich annotations, the description supplies the key missing piece: that signature detail values are part of the result. Only minor gaps remain, such as failure behavior for an invalid 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?

Schema coverage is 100% and the id parameter is documented as coming from list_teammates. The description only restates 'by id', adding no syntax or format detail beyond the schema, which is the appropriate baseline.

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

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

States a specific resource ('one teammate') retrieved by id, and adds that signature detail values are included. It distinguishes itself from list_teammates by being singular, though the overlap with get_teammate_signature is not explicitly addressed.

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

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

There is no explicit guidance on when to use this tool versus list_teammates or get_teammate_signature. Usage is only implied by the 'by id' phrasing and the schema note.

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

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

Annotations already cover the safety profile (readOnly, non-destructive, closed-world), and the description adds real behavioral value beyond them: 'Always a live count' discloses that results are uncached/real-time rather than a stored rollup, and it pre-announces that the response reports the effective date range and read timestamp. It does not mention permission requirements, but with full annotation coverage that is a minor gap.

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 what is counted and how it is broken down, followed by the behavioral note and the date rule. Every sentence carries information an agent needs; nothing is redundant with 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 no output schema, the description usefully compensates by naming the breakdown dimensions and the response's range/read-time metadata. It stops short of explaining the shape of the breakdown (e.g., whether dimensions are cross-tabulated or separate), which is the one thing an agent might still guess at.

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

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

Schema description coverage is 100%, so id, start_date and end_date are already documented with format and the all-time rule. The description reinforces the 'both dates or neither' semantics but adds no syntax or edge-case detail beyond the schema; baseline 3 applies.

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

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

States a specific verb and resource: click counts on a teammate's signature links, with the exact breakdown dimensions (country, browser, OS, device). That distinguishes it in practice from get_teammate_signature and list_signature_links, though it never names those siblings explicitly.

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

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

Gives clear guidance on the date parameters ('Leave out both dates to count all clicks ever'), which is genuine usage instruction. However, it offers no guidance on when to choose this tool over get_teammate_signature or list_signature_links, and no preconditions are stated.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds substantive behavior beyond that: it enumerates what the install record reveals (platform, success status, timing), which is genuinely useful given there is no output schema. It omits any note on what happens when no install record exists.

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

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

Two short sentences, return content front-loaded, then the usage hint. No filler and no repetition of the title or schema.

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

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

With no output schema, the description carries the return-value burden and does so reasonably well by naming the signature HTML and the install record fields. It could be stronger by noting the empty/no-record case, which is the exact scenario the usage hint points at.

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

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

Schema coverage is 100% and the single id parameter is documented in the schema as 'Teammate id from list_teammates.' The description adds nothing about the parameter beyond the schema, so the baseline 3 applies.

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

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

The description states the specific resource and its return content: 'The signature HTML this teammate has, plus the install record' with fields (platform, success, time). This is far more than restating the name, and the content focus distinguishes it from a generic get_teammate. It stops short of explicitly naming sibling tools like preview_signature.

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?

'Use this to answer "why does X have no signature"' gives a concrete triggering scenario an agent can pattern-match. There is no statement of when-not-to-use or which sibling to prefer for other cases, so it falls below the 5 bar.

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

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

Annotations already declare readOnlyHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is fully covered. The description adds only a field list, with no note on permissions, scoping to the signed-in user, or caching behavior.

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

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

A single short clause with no padding, and the identifying scope ('the signed-in workspace') comes first. It reads as a label rather than a sentence, 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?

For a zero-parameter read tool with no output schema, listing the returned fields (name, domain, seat usage, teammate count) is the main piece of information an agent needs and it is supplied here. Little else is required to call it correctly.

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

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

The tool takes zero parameters and the schema is empty, so there is nothing for the description to disambiguate. This meets the baseline for a no-parameter tool.

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 ('the signed-in workspace') and enumerates what it contains, which distinguishes it from get_workspace_template. However, it is a noun fragment with no verb, so the action (retrieve vs. describe) is only implied by the tool name 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?

There is no guidance on when to call this versus sibling tools such as get_workspace_template or list_teammates, and no stated preconditions. The agent must infer usage entirely from the name.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds that the response includes fields and design, which is useful return-shape signal given there is no output schema, but says nothing about error behavior for an unknown id.

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

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

A single short sentence with no wasted clauses; the return contents and the intended use are front-loaded. Slightly awkward phrasing ('One template including its fields and design') keeps it from a 5.

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

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

For a one-parameter read tool with full schema coverage and no output schema, this covers the gap that matters: what comes back (fields and design). Only the behavior for a missing id is unaddressed.

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

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

Schema coverage is 100% and the id parameter already documents that it comes from list_workspace_templates. The description adds nothing about the parameter, so the baseline of 3 applies.

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

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

States a specific verb (get) and resource (workspace template), and the phrase 'one template ... including its fields and design' distinguishes it from the sibling list_workspace_templates, which returns many. It stops short of naming that sibling explicitly, so it is clear but not maximally differentiated.

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

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

'For inspecting before editing' implies the use case (read a template prior to update_workspace_template), which is meaningful guidance. However, it never names the alternative tool or states when not to use this one, leaving the routing implicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful detail that each entry carries its schedule and an active flag, but says nothing about pagination limits, total counts, or result ordering — the remaining behavioral gap for a list tool.

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

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

One short clause, no waste, front-loaded with the resource. However it is a sentence fragment rather than a complete statement, and its brevity comes at the cost of the information 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?

The tool is simple — one optional param, read-only, annotations cover safety, schema covers paging input. The description usefully notes the returned fields in the absence of an output schema, but leaves the pagination contract (page size, termination) undocumented, which matters for a list endpoint.

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

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

There is a single optional 'page' parameter with 100% schema description coverage including default and minimum, so the schema does the work. The description adds nothing about paging (page size, how to detect the last page), so baseline 3 applies.

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

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

The description names the resource (banner campaigns) and the key attributes returned (schedule, active status), but is a noun phrase rather than a verb+resource statement — no 'list' or 'retrieve'. It is not confused with delete_campaign/update_campaign/pause_campaign, but the action itself is only inferable from the 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?

No guidance on when to use this versus siblings, no mention of pagination behavior or how to retrieve further pages. The agent must infer usage entirely from the name and schema.

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

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

The annotations already declare this is a read-only, non-destructive, closed-world operation. The description adds useful context about what the groups contain (member counts and template association), but it does not mention ordering, pagination, empty results, or access constraints. With annotations covering safety, this is a reasonable but not rich behavioral disclosure.

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

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

The description is two concise sentences and is front-loaded with the key information about what is listed. The second sentence adds domain context rather than call-critical detail, but it is brief and does not create clutter.

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 listing tool with no output schema, the description should clarify the shape of returned data. It states that each group includes teammate count and template, but it does not mention group identifiers or names, which an agent would need to follow up with update_group or delete_group. It is adequate but incomplete.

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 per the rubric. There are no parameter semantics to clarify in the description, and the schema is empty by design.

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

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

The description clearly identifies the resource (groups in the workspace) and what each entry includes (teammate count and associated template). It does not explicitly distinguish itself from related siblings such as list_teammates or get_workspace, which prevents a perfect score.

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

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

Usage is implied by the tool name and the description's focus on listing groups, but there is no explicit guidance on when to choose this over alternatives like get_workspace, list_teammates, or get_workspace_template. It is adequate but leaves the agent to infer the right context.

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

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

Annotations already declare readOnlyHint=true, non-destructive and closed-world, so safety is covered. The description adds genuinely useful context beyond that: the response includes credential expiry state, and it explains the operational significance (stalled syncs). It does not say whether the list is complete or paginated, which is the only notable gap for a zero-argument read.

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, no filler, and the substantive payload (expiry status) is stated first. The diagnostic hint follows as supporting context rather than burying the lead.

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

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

With no output schema, the description carries the burden of describing return values, and it does name the critical field (expired credentials) plus the practical interpretation. It omits other likely fields (provider name, connection date, last sync) and any ordering, so it is good but not exhaustive for a zero-parameter list tool.

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

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

The tool takes no parameters, so there is nothing to disambiguate; the baseline of 4 applies. The description correctly implies the call is unfiltered and returns all connected integrations.

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

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

States the resource (connected integrations) and the key attribute returned (credential expiry), which is specific enough that an agent knows exactly what this returns. It's a noun phrase rather than a verb+resource, so the action ('list') comes only from the name, but there is no ambiguity. No sibling tool covers integrations, so differentiation is automatic.

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 second sentence implies a diagnostic use case ('An expired token is usually the reason a sync has stopped'), which tells the agent when this is worth calling. However, it never explicitly says when to use this versus other tools, nor does it state prerequisites or exclusions.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered. The description adds that the result concerns tracked links and their destinations, but it does not disclose ordering, pagination, or return shape.

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

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

The description is a single short sentence with no wasted wording. It front-loads the resource, though it reads as a fragment and omits the explicit list action.

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

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

For a simple read-only list tool with one fully documented parameter and no output schema, the description conveys what is being listed and that each link includes a destination. It is adequate, though usage guidance would improve 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?

Schema description coverage is 100%, so the single parameter is fully documented in the schema. The description adds no additional syntax or constraints beyond what the schema already provides, making 3 the appropriate baseline.

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

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

The description states a specific resource, 'tracked links inside a signature,' and scope, 'where each one points,' which distinguishes it from signature-template and signature-preview tools. It does not include an explicit verb like 'list,' but the resource and scope are clear enough.

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

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

The description provides no when-to-use guidance, no exclusions, and no named alternatives. The schema parameter notes that the signature_id comes from get_teammate_signature, but that is only indirect usage context.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered. The description adds useful framing about what the response contains (template name plus numeric id), but says nothing about ordering, completeness, or whether the list is workspace-scoped.

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

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

A single short sentence with no waste, front-loading the catalog name before the field list. It is a noun phrase rather than a complete statement, which costs a little clarity but nothing in 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 no-parameter read tool with annotations covering safety, the description is close to sufficient, and the output field hint helps in the absence of an output schema. It still leaves the relationship to workspace templates unexplained, which is the main ambiguity an agent would face.

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 and there is nothing the description could clarify. The mention of the two returned fields is a small bonus rather than a requirement.

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 identifies the resource as a 'product template catalog' and names the returned fields (name, numeric id), so the agent can infer it is a listing tool. However, there is no verb and no differentiation from the sibling tools list_workspace_templates and get_workspace_template, leaving the exact scope of 'product' templates ambiguous.

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

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

No when-to-use guidance is given, and no alternative is mentioned despite a near-identical sibling (list_workspace_templates) in the catalog. The agent has to guess which catalog it needs.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine domain context — that fields bound to a source are populated by sync rather than manually — which helps interpret the results, but says nothing about pagination, ordering, or workspace scoping.

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 core identity of the resource is front-loaded and the sync note follows as supporting context.

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 must carry the return shape, and it does so only partially — it names the per-field attributes but not whether the result is paginated, complete, or ordered. Adequate to decide to call it, thin for interpreting the response.

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 to document; the schema and description are consistent on this. Baseline 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 defines the tool as a read of the workspace field registry and enumerates what each entry contains (field, binding, required flag). It is clear what the resource is, but it never explicitly says it returns ALL fields or how it differs from sibling get/create/update/delete_smart_field.

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 inspecting fields another way, and no prerequisites or exclusions. The closest thing to guidance is the note about sync-bound fields, which is a domain fact rather than usage routing.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds one piece of behavioral information — that signature values are present on each row — but says nothing about result volume, ordering, or pagination behavior beyond what the schema covers.

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 earning their place: the first establishes what is returned, the second establishes the use case. Front-loaded with the resource and no filler.

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

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

For a simple, read-only, zero-required-parameter list tool with annotations covering safety and a fully documented schema, the description is nearly sufficient. The only real gap is the absence of an output schema combined with only a partial account of what each row contains.

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% (page and per_page are fully documented with defaults and bounds), so the description is not required to compensate. It adds no further parameter meaning, which is the correct baseline for a 2-param fully-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 verb and resource ('List workspace teammates') and adds scope that matters: signature values are returned with each teammate. That differentiates it from get_teammate (single record) in substance, though the sibling is never named.

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

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

Gives one concrete usage scenario (coverage questions like 'who is missing a job title?'), which is genuinely useful context. However it never states when to prefer get_teammate or get_teammate_signature instead, so the routing guidance is implied rather than explicit.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered elsewhere. The description adds a small amount of behavioral value by disclosing that each template is returned together with its attached group, but it says nothing about ordering, pagination, or volume of results for a workspace with many templates.

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

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

One short sentence fragment with zero filler, and the key fact (templates plus their group) is front-loaded. It is slightly under-specified rather than verbose, but nothing in it 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-parameter read-only tool with full annotation coverage, very little is required, and the description covers the resource and one output attribute. With no output schema, however, it should say more about the returned shape (fields per template) and whether results are paginated or complete before an agent commits to it.

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

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

The tool takes zero parameters, so there is no parameter semantics to explain and the baseline of 4 applies. The description does not need to compensate for any schema gap here.

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

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

The description identifies the resource (templates built in this workspace) and notes that the attached group is returned, which lets an agent infer a listing operation. However, it is a noun phrase with no verb, and it never distinguishes itself from the sibling get_workspace_template, which retrieves a single template. The purpose is inferable but not stated with a specific verb or clear sibling boundary.

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

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

There is no when-to-use guidance, no exclusions, and no pointer to alternatives such as get_workspace_template for a single template. The only signal is the name prefix 'list', leaving the agent to infer that this is the enumeration counterpart to the getter.

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, idempotent, non-destructive, so the safety profile is covered. The description still adds real value beyond them: the banner is pulled from signatures (a downstream side effect outside this resource) and the failure mode CAMPAIGN_NOT_ACTIVE is named. It doesn't say what happens when pausing an already-paused campaign.

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: the action and its effect first, then the refusal condition. No filler and nothing that could be trimmed without losing information.

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

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

For a single-parameter state-change tool with annotations and no output schema, the description covers action, side effect, precondition and error. The only gap is the already-paused case and whether any return payload is produced.

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

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

Only one parameter and schema coverage is 100%, with the schema already stating it comes from list_campaigns. The description adds nothing about the id beyond what the schema provides, so baseline 3 applies.

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

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

States a specific verb ('Pause') and resource ('campaign') plus the downstream effect on banners in signatures. The RUNNING-only framing implicitly separates it from resume_campaign and delete_campaign, but no sibling is named explicitly.

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

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

Gives an explicit precondition (must be RUNNING) and an explicit exclusion (scheduled campaigns have nothing to pause) with the resulting error code. It does not name resume_campaign or delete_campaign as alternatives for other desired outcomes.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds useful behavioral context beyond annotations: it does not save anything or change installed signatures, and form 2 reports how many teammates the proposed edit would affect.

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 front-loads the core purpose and then presents the two forms compactly. Every sentence contributes either to safety context, mode selection, or expected preview output.

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 17-parameter tool with nested objects and no output schema, the description provides enough mode structure and safety/impact context to invoke it correctly. It does not detail the exact return shape beyond 'email-safe HTML' or validation edge cases, so it stops short of fully complete.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds meaning by grouping the 17 parameters into two mutually exclusive forms and explaining what each mode previews, which is valuable beyond the individual parameter descriptions.

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

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

The description states a specific verb and resource: 'Render email-safe HTML.' It clarifies that it only renders and does not save or change installations, and it outlines two distinct preview modes, which differentiates it from sibling update/get tools.

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

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

It explains the two usage modes clearly: form 1 uses template_id plus person fields, and form 2 uses workspace_template_id plus teammate_id with proposed fields/design. It gives strong context for when each form applies, but it does not explicitly name alternatives or when-not conditions.

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

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

Annotations already declare destructiveHint=true, idempotentHint=true and readOnlyHint=false, so the bar is lower. The description still adds real consequence context beyond them: the group's signature is deleted and the teammate is left unsigned until assigned elsewhere — exactly the side effect an agent needs to warn about.

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, no filler, and the consequence is front-loaded immediately after the action statement. 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?

A simple two-parameter mutation with full schema documentation and annotations covering safety and idempotency; the description closes the remaining gap by explaining the resulting state. Only the absence of a stated reversal path or permission requirement keeps it from a 5.

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

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

Schema coverage is 100% and both parameters document their own sources (list_groups, list_teammates). The description adds nothing about parameters, so the baseline 3 applies.

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

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

States a specific verb and resource ('Take teammates out of a group'), making the mutation unambiguous. It does not name the inverse sibling add_teammates_to_group or any adjacent tool, so differentiation relies on the agent inferring from the 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?

Usage is implied by the name and description, but there is no explicit when-to-use vs when-not guidance, nor a pointer to add_teammates_to_group as the reversal path. Adequate but with clear gaps.

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 as a non-read-only, idempotent, non-destructive mutation. The description adds meaningful behavior beyond the annotations: the PAUSED prerequisite, the banner restoration effect, and the specific CAMPAIGN_NOT_PAUSED error case.

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 main action and precondition front-loaded, followed by the error behavior. No wasted 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 one-parameter mutation with full schema coverage and annotations covering idempotency and safety, the description provides the essential extra context: state prerequisite, effect, and failure mode. Nothing important is missing.

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

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

Schema coverage is 100%, and the id parameter is already documented as coming from list_campaigns. The description adds no further parameter semantics, 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 (resume a campaign) plus the required state (PAUSED) and the side effect (banner restored). This clearly distinguishes it from pause_campaign and update_campaign in the sibling list.

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

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

Explicitly limits use to PAUSED campaigns and notes the CAMPAIGN_NOT_PAUSED failure when the campaign was never paused. It does not explicitly name pause_campaign as the inverse alternative, but the precondition is clear enough to select the tool correctly.

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

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

Annotations declare destructiveHint=true and idempotentHint=true, and the description does nothing to explain what is destroyed — notably that group_ids fully replaces targeting and that fields are overwritten. With no mention of overwrite semantics or irreversibility, the description leaves the highest-risk behavior to the annotation flag alone.

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

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

A single front-loaded sentence with no filler; every word maps to a facet of the operation. Brevity is the issue only in the sense of omission, not verbosity.

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

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

For an 8-parameter destructive mutation with no output schema, the description should say that only supplied fields change, that group_ids wipes existing targeting, and what a caller needs up front. None of that is present, so an agent could reasonably call it in a way that clobbers targeting.

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 field meanings (YYYY-MM-DD dates, group_ids replaces targeted groups, https image URL) are already carried by the schema. The description's phrase 'content, schedule or targeting' roughly groups the fields but adds no syntax or format detail.

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

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

States a specific verb (change) and resource (campaign) plus the three facets modified: content, schedule, targeting. This distinguishes it from delete_campaign/pause_campaign, though it never names those siblings, so an agent must infer the split from the 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?

There is no guidance on when to use this versus pause_campaign, resume_campaign, or delete_campaign, nor any stated prerequisites (e.g. needing an id from list_campaigns). The one sentence implies a general edit but gives no selection criteria.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true, but the description adds the crucial blast-radius detail that a template change re-renders and reinstalls the signature of everyone in the group, which is exactly the context an agent needs before mutating. It stops short of stating reversibility or permission requirements.

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

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

Two tight sentences with no filler; the primary action comes first and the consequential side effect second. Every clause carries information.

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

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

For a destructive, no-output-schema mutation, the description covers the action and its main side effect, with parameters fully documented in the schema. The remaining gap is the combination semantics of name and template_id (mutually exclusive vs. both applied), which the agent must guess.

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

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

Schema description coverage is 100%, so all three parameters are documented structurally, setting the baseline at 3. The description adds a bit of meaning to template_id by explaining its downstream re-render/reinstall effect, but says nothing about the id/name semantics beyond the schema.

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

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

States two specific operations on a specific resource: rename a group, or repoint it at a different template. Combined with the title and the sibling set (create_group, delete_group, update_teammate), an agent can immediately tell this is the group-mutation tool.

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 described operations imply when to call it, but there is no explicit guidance on prerequisites or alternatives, and no statement about whether name and template_id may be supplied together or whether one is required beyond id. Usage is inferable rather than stated.

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

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds critical operational context: rebinding decides future write permissions and binding to a sync source overwrites teammate values on the next sync. This explains the real consequence of a destructive update beyond what annotations provide.

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

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

Two compact sentences with no wasted words. The main update actions are front-loaded, followed immediately by the critical side effect of rebinding.

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 but idempotent mutation with a fully described schema and no output schema, the description covers the core actions and the most important risk: overwriting teammate values on sync. The remaining details are covered by the schema and annotations.

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

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

Schema description coverage is 100%, so the schema already defines every parameter, including the source enum and overwrite behavior. The description reinforces the key mutation but does not add parameter details beyond the schema, making the baseline score appropriate.

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

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

The description states specific update actions for a smart field: rename, mark required, or rebind its source. It is clear what the tool does, though it does not explicitly distinguish itself from sibling tools like create_smart_field or delete_smart_field beyond the update framing.

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

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

Usage is implied by the listed actions (rename, mark required, rebind source), but the description does not state when to choose this tool over alternatives or mention any prerequisites. It gives enough to infer the use case but no explicit routing guidance.

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

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

Annotations already flag destructiveHint=true and idempotentHint=true; the description goes beyond them by disclosing the refusal path for sync-sourced and owner-locked fields, that the error names the offending fields, and the two remedies (change at source, or rebind the smart field). It omits whether omitted parameters are left unchanged, which matters for a destructive 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?

Three compact sentences front-loaded with the action, then the failure mode, then the remedy. No filler, though the opening sentence is generic enough that it could have named the writable field set instead.

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, and the description covers the key failure mode and its recovery. It still leaves the partial-update question open (does specifying only name wipe email/phone?) and says nothing about what a successful response contains, which is a meaningful gap for a destructive mutation.

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

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

Schema description coverage is 100%, so the schema already explains all seven parameters, including that id comes from list_teammates. The description adds only a cross-cutting constraint on which fields are writable, not per-parameter meaning, so baseline 3 applies.

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

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

States a specific verb and resource ('Change a teammate's values'), which clearly separates it from create_teammate, delete_teammate and the other update_* siblings. It does not enumerate which values are changeable, but the schema covers that fully.

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

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

Usage is implied (edit an existing teammate rather than create/delete one) and the description identifies the prerequisite that a field must not be sync-bound or owner-locked. It never explicitly says when to reach for this versus get_teammate or update_smart_field, leaving routing to the naming.

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?

Goes well beyond the annotations: it discloses that changes go live immediately with no draft staging, that signatures are re-rendered and reinstalled for every teammate in affected groups, and that the response reports how many teammates were queued. That blast-radius and immediacy information is exactly what a destructive mutation tool needs and what destructiveHint=true alone cannot convey.

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

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

Two compact sentences, with the critical 'THIS GOES LIVE IMMEDIATELY' warning front-loaded before the explanation of consequences. No filler.

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

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

For a destructive, nested-object mutation with no output schema, the description covers the safety-critical facts (no staging, live re-render/reinstall across groups) and states what the tool returns (teammate count queued). Nothing essential for calling it correctly is missing.

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

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

Schema description coverage is 100% – each parameter (id, cta, name, design, fields) already documents its meaning and that object/array params replace wholesale. The description adds no further parameter guidance, 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 title and description establish the verb+resource (update a workspace template) and the description explains the concrete effect: re-render and reinstall signatures for every teammate in groups using the template. It doesn't explicitly contrast with siblings like get_workspace_template or create/list, but the mutation intent is unmistakable.

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 context is implied rather than stated: 'there is no draft staging through this API' warns the agent that changes are immediate, and the schema points to list_workspace_templates/get_workspace_template as the source of the id and full objects. There is no explicit when-to-use/when-not or named alternative in the description itself.

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